«10 уроков» оптимизации для ArcGIS for Desktop и ArcGIS for Server

«10 уроков» оптимизации для ArcGIS for Desktop и ArcGIS for Server

 

Стрельцов И.В., компания Esri CIS, e-mail: istreltsov@esri-cis.ru

 

Optimization tips for ArcGIS for Desktop & ArcGIS for Server

Описаны общие принципы и главные правила оптимизации данных и их оформления для ArcGIS for Desktop и ArcGIS for Server. В качестве источников информации для статьи использованы документация ArcGIS и эксперименты автора.

Лирическое вступление. Вопросы оптимизации встают перед каждым человеком практически постоянно. Самая простая задача оптимизации: что, где и как купить, чтобы получить максимальную отдачу за минимальные деньги и с минимальными усилиями. Конечно, вы можете возразить: а как же знаменитая фраза «у вас есть точно такой же, но с перламутровыми пуговицами?». Какая тут оптимизация? Да прямая! Вы всё так же хотите получить от вещи максимальную отдачу, только в данном случае эта отдача не выражается в количестве, а представляет собой качество или степень удовлетворения, а именно – «супер модно» или «супер красиво», «удобно и комфортно» или просто «веселенько».

От лирики к «физике». Оптимизация ГИС дает вам возможность не использовать большое количество физических серверов для быстрого и качественного обслуживания пользователей, не наращивать мощности настольных компьютеров, но добиваться быстрого отображения карт в настольных приложениях.

Для того чтобы успешно решать свои задачи, необходимо учитывать несколько главных правил любой оптимизации.

Не существует «лучшего» решения, существует только «нехудшее». Это будет решение, которое, возможно, лучше чем то, что уже есть, и лучше, чем многие другие. Но вы не можете утверждать, что оно лучше всех возможных, потому что про ВСЁ остальное вы не знаете. Данное решение может быть лучше по одним параметрам, но хуже по другим, или оно будет лучше в конкретно взятой ситуации. Вопросы выбора нехудшего решения подробно изучаются в ВУЗах в темах, посвященных задачам многокритериального выбора.

Чем больше критериев работы системы и внешних факторов, воздействующих на систему, вы будете учитывать, тем более качественно вы сможете произвести анализ и оптимизировать систему. Если брать во внимание только малую часть таких критериев и факторов, то это может вылиться в явный перекос при проектировании системы, и, выигрывая в одном, вы неизбежно проиграете в другом.

Чем больше объем данных, используемых системой, тем большего прироста производительности (в процентном виде) вы сможете добиться. Системы, использующие небольшие фрагменты данных, как правило, и без особой настройки работают быстро и не нуждаются в серьезной оптимизации.

ГИС довольно часто оптимизируется по трём параметрам:

  • Система должна работать быстро, то есть так, чтобы время реакции не превышало ожидаемое. Для веб-систем это время составляет первые единицы секунд. Для настольных приложений в большинстве случаев это время довольно значительно и сильно зависит от задачи, поставленной системе. Как правило, пользователь настольной системы будет мириться с тем, что сложная карта перерисовывается не один десяток секунд, а интернет-пользователь в такой же ситуации подумает, что случились неполадки с сайтом или со связью.
  • Пользовательсистемыдолженполучить всю необходимую информацию сразу, без использования дополнительных инструментов интерфейса, но при этом экран не должен быть перегружен лишней и сложно читаемой информацией. В данном случае пользователь настольной системы тоже более лоялен, поскольку очень часто бывает, что всё, что отображается на экране – результат его работы. А интернет-пользователь и здесь более требователен, он не хочет делать лишних телодвижений, ему нужно всё и сразу, но при этом всё это должно быть разборчиво.
  • Работа с системой должна оставлять приятное впечатление, система должна быть удобной в использовании, в том числе, должны быть соблюдены и законы красоты (пропорции, цвета, упорядоченность и т.п.) как в оформлении интерфейса, так и в оформлении данных. Только в этом случае пользователь захочет, а не будет вынужден использовать систему снова.

Разберем некоторые способы оптимизации настольных и серверных ГИС и место этих способов во множестве упомянутых выше критериев, факторов, правил.

Начнем с производительности. Основной способ повышения производительности работы любой базы данных (а ГИС всегда содержит БД) – это уменьшение количества информации, получаемой клиентами с помощью запросов. Объясняется это тем, что оптимизация системы с помощью оптимизации запросов дает выигрыш в разы, десятки, сотни, тысячи раз, а настройка параметров работы сервера, как правило, дает прирост в проценты, десятки процентов. Так что же и как ограничивать? Посмотрим на скриншот (рис. 1). Нечто, напоминающее карту плотности или распределения чего-либо с границами России, на самом деле представляет собой один слой линейных объектов гидрографии на территорию нашей страны с детальностью карты масштаба 1:1 млн. Данный слой отображается в обзорном масштабе 1:100 млн., и при таком масштабе практически полностью заливает линиями всю территорию. Можно ли понять или разобрать что-то на такой карте? Понять можно, что рек много, а что-то разобрать – нет. Самое простое решение состоит в использовании для такого масштаба определяющего запроса по длине реки (SHAPE_Lenght > 100000) и отображении только самых длинных рек, например, более 100км. Можно также взять для такого масштаба более грубые данные, например с карты масштаба 1:8млн. (рис. 2). На такой карте уже что-то можно разобрать.

 


Рис. 1. Что бы это значило?
Рис. 2. Карта с используемым определяющим запросом.

 

Следующим шагом будет предотвращение потерь информации на крупных (детальных) масштабах. Для этого один и тот же класс объектов можно добавить в карту несколько раз, затем для каждого слоя установить свои собственные ограничения на отображаемые объекты и для каждого такого слоя установить свои собственные пределы масштабов отображения. Для упрощения оформления карты можно сделать групповые слои, установить для них пределы масштабов отображения, и в эти групповые слои уже добавлять слои с настроенной детальностью отображения объектов. Пример такого использования групповых слоев представлен на рис. 3.


Рис. 3. Групповые слои с зависимостью отображения от масштаба.

После каждого шага оптимизации желательно проверять и записывать результаты оптимизации. Конечно, вы и сами увидите, что после введения масштабных ограничений «стало быстрее», но понять, насколько быстрее можно только с помощью количественных измерений. Для этой цели очень хорошо подойдет утилита MXDPERFSTAT, разработанная специалистами компании Esri. Анализируя указанный MXD-файл, MXDPERFSTAT подсчитывает время отображения карты в указанных масштабах и экстентах. Если никаких дополнительных параметров не указано, анализируется визуализация случайно выбранного экстента на масштабах, заданных по умолчанию. Подробное описание работы программы приведено в документации к данной утилите. В результате своей работы MXDPERFSTAT выдает таблицу отчета со временами визуализации каждого слоя на каждом масштабе, где цветом выделяются проблемные слои, описывается, в чем состоит возможная проблема и что можно сделать для ее решения (рис. 4). Отчет содержит время выборки данных из базы (файла) и время графической фазы вывода. Таким образом, можно увидеть, какой этап вносит наибольшие задержки в процесс работы с данными. С помощью указанной утилиты вы сможете сравнить время визуализации слоев исходной карты и модифицированной, и понять, насколько ваши усилия увенчались успехом. Эта утилита бесплатная, ее можно скачать с сайта Esri (поиск по слову MXDPERFSTAT на http://resources.arcgis.com/).


Рис. 4. Пример отчета утилиты MXDPERFSTAT.

Быстро проверить результат оптимизации можно и другим способом, через фиктивную публикацию карты в виде сервиса. Даже если у вас нет ArcGIS for Server, вы можете сделать подобную проверку. В ArcMap воспользуйтесь меню «Файл»/ «Опубликовать как»/ «Сервис»/ «Сохранить файл определения сервиса»/ «Нет доступного подключения». В открывшемся окне публикации нажмите «Предварительный просмотр», откроется окно предварительного просмотра с указанным временем отображения (рис. 5). У данного способа контроля есть одна некорректность. В данном случае для рисования карты используется рендер (визуализатор) ArcGIS for Server, работающий значительно быстрее, чем рендер Windows (Windows GDI), который используется в ArcGIS for Desktop 10.x. Поэтому полученное значение времени не будет реальным временем визуализации в ArcGIS for Desktop, но для сравнения скорости отображения разных вариантов карты такой способ применять можно.


Рис. 5. Окно предварительного просмотра при публикации сервиса.

Очень часто, когда разговор заходит об оптимизации, встает вопрос: «Где лучше хранить данные – в файловой БГД, в ArcSDE БГД или, может быть, в шейп-файлах? А если в ArcSDE БГД, то какую СУБД использовать?» На вторую часть вопроса ответить легче всего. Выясните, в какой СУБД у вашего администратора БД есть наибольший опыт и наивысшая компетенция, ее и используйте. Если администратор не умеет администрировать ни одну из СУБД, вам придется сначала найти хорошего администратора. Если вы сами являетесь администратором СУБД, но задаете этот вопрос, используйте MS SQL Server. MS SQL Server будет вполне нормально работать без каких-либо специальных настроек со стороны администратора, помимо этого данный сервер имеет одну из самых удобных сред управления и его система учетных записей легко интегрируется с ОС Windows.

Так что же лучше, файловая БГД, ArcSDE БГД или шейп-файлы? Шейп-файлы всё чаще используются как обменный формат, хотя в некоторых случаях они показывают отличную производительность. Но из-за многочисленных функциональных ограничений мы не советуем использовать шейп-файлы. Какой вариант БГД стоит предпочесть, однозначно сказать сложно, и в каждом случае многое зависит от правильности использования и от настроек СУБД. Если ничего не настраивать, и рассматривать вариант, когда файловая БГД будет храниться на том же сервере, где располагается СУБД, то файловая база покажет бОльшую производительность. Проигрыш ArcSDE БГД может составлять до двух раз. Если настраивать СУБД, где хранятся данные ArcSDE БГД, если оптимизировать хранение данных в СУБД, то СУБД покажет бОльшую производительность. То есть, опять все зависит от администратора СУБД. Разберем две сущности, которые могут ускорять и замедлять работу с данными СУБД: индексы и статистика.

Итак, индексы. В ArcGIS они существуют в виде атрибутивных и пространственных индексов. Пространственные индексы используются при пространственных выборках и для ускорения обыкновенного отображения картографических данных в ваших приложениях. Как правило, ArcGIS for Desktop сама корректно строит пространственные индексы, и этому вопросу можно не уделять пристального внимания.

Атрибутивные индексы используются базами данных для ускорения поиска нужных данных. С атрибутивными индексами могут случаться две неприятности: их может не быть вовсе и они могут быть фрагментированными. ArcGIS for Desktop автоматически строит атрибутивный индекс для каждой таблицы и класса объектов по полю OBJECTID, которое активно используется в служебных целях самой базой геоданных. Также ArcGIS for Desktop автоматически строит атрибутивные индексы по тем полям, по которым осуществляется связь в созданных классах отношений. Но вы самостоятельно должны строить индексы по тем полям, которые:

  • используются для присвоения различных условных знаков при наличии классификации;
  • участвуют в определяющем запросе;
  • часто используются для атрибутивных выборок и запросов к данным.

Построение индексов осуществляется через «Свойства/Индексы» таблицы или класса объектов, а также инструментом ArcToolbox. Наличие индексов до двух раз увеличивает производительность работы с данными, хранящимися в СУБД. Если данные хранятся в файловой СУБД, скорость работы с ними не зависит от наличия или отсутствия индексов (проверено в версии 10.2.1).

Фрагментация индексов появляется при активном редактировании данных и приводит к уменьшению скорости обработки данных. Дефрагментировать индексы проще всего инструментом ArcToolbox «Администрирование базы геоданных/Перестроить индексы».

Статистика данных позволяет СУБД выбирать правильный план выполнения запроса, который должен либо использовать индекс, либо использовать полное сканирование таблицы. По сути, статистика представляет собой информацию о частоте встречаемости каждого конкретного значения в таблице или классе объектов. Как и индексы, статистика «портится» при активном редактировании данных, а также при дозагрузке данных. СУБД может быть настроена на автоматическое обновление статистики, а может и не использовать эту возможность. В случае отсутствия автоматического обновления статистики необходимо регулярно обновлять статистику данных либо через ниспадающее меню для класса объектов или таблицы «Управление/Анализировать», либо с помощью инструмента ArcToolbox «Администрирование базы геоданных/ Анализировать наборы данных». Устаревшая статистика может непредсказуемо уменьшать производительность работы с данными в СУБД. Для данных в файловой БГД статистика не строится и не обновляется.

Возвращаясь к вопросу «что же лучше: файловая БГД или ArcSDE БГД?» в качестве первичного критерия, следует принимать во внимание не производительность работы, а функциональность, которую вы хотите получить от системы хранения. Если вам необходимо получить хотя бы одну функцию из нижеприведенного списка, то вам необходимо использовать ArcSDE БГД. Только многопользовательские БГД под управлением технологии ArcSDE могут обеспечить:

  • редактирование одного и того же класса объектов или таблицы разными пользователями;
  • редактирование данных через веб-приложения ArcGIS for Server;
  • использование репликации и синхронизации данных по технологии ArcGIS.

Если вы выбрали хранение БГД в СУБД, то перед вами стоит задача выбора формата хранения пространственных данных. Различные СУБД позволяют хранить данные в различных форматах. Это и бинарный тип хранения пространственных данных (Oracle, MS SQL Server), и пространственный тип ST_GEOMETRY (Oracle, Postgre SQL), и пространственный тип SDO_GEOMETRY (Oracle), и пространственный тип GEOMETRY или GEOGRAPHY (MS SQL Server) и т.д. Если ориентироваться только на производительность, можно сказать однозначно: используйте тип хранения по умолчанию. Если же стоит задача связи ArcGIS с другими ИС или ГИС, то выбор будет определяться необходимостью и возможностью использования пространственных данных, хранящихся в общей СУБД, другими ИС или ГИС. Конечно, это приведет к некоторому падению производительности, но в вопросах интеграции первична именно интеграция, производительностью иногда приходится жертвовать.

Следующим способом увеличения производительности работы с данными является использование подтипов. Подтип, по сути, является классификатором, основанным на целочисленных значениях. Увеличение скорости обработки данных с подтипами происходит из-за двух обстоятельств:

  • обработка целых чисел в любой базе происходит значительно быстрее, чем текстовой информации;
  • работа с выборками из больших таблиц происходит быстрее, чем работа с большим количеством мелких таблиц.

Если есть возможность, используйте для подтипов поле с целыми короткими значениями. Выигрыш по времени при использовании подтипов вместо отдельных классов может достигать десятков или даже сотен раз. По рисункам 6 и 7 вы можете понять разницу в отображении одной и той же информации, а именно дорожной сети на территорию РФ масштаба 1:1 млн, при использовании подтипов и при использовании отдельных классов объектов.

 


Рис. 6. Таблица содержания карты с одним слоем (класс с подтипами). Визуализация карты в масштабе 1:50 млн. занимает 1,5 сек., в масштабе 1:2,5 млн. – 0,01 сек.
Рис. 7. Таблица содержания карты с 14 слоями. При использовании данных из 14 отдельных классов визуализация карты в масштабе 1:50 млн. занимает 1 сек., в масштабе 1:2,5 млн. – 0,5 сек. При использовании данных из одного класса с подтипами визуализация карты в масштабе 1:50 млн. занимает 1 сек., в масштабе 1:2,5 млн – 0,05 сек.

 

Следующий путь оптимизации также связан с отображением. Как уже было сказано, ArcGIS for Desktop для отображения карт на экране использует рендер Windows (Windows GDI), а ArcGIS for Server – рендер Esri. Кстати, рендер Esri использует и новое приложение ArcGIS Pro, которое будет включено в версию 10.3. Windows GDI довольно тяжело справляется с отображением сложных условных знаков. Например, если в качестве примера взять проект с гидрографией на территорию РФ и отображать его в нормальных масштабах (1: 1-2 млн), то после замены условного знака линий с «Простая линия» на «Простая картографическая линия» (меняется только название, внешний вид условного знака остается тем же) вы получите проигрыш на 20-25%, а если будете использовать «Сложную картографическую линию» (то есть, пунктиры или штрих-пунктиры), то проигрыш в скорости отображения составит до двух раз. То есть, ArcGIS for Desktop «чувствителен» к «сложности» условных знаков. Если таким же образом проверить падение производительности сервисов ArcGIS for Server, то, в худшем случае, при использовании «Сложной картографической линии» проигрыш в производительности составит всего 20%. Мы видим, что программисты Esri не зря трудились над собственном рендером.

К плюсам рендера Esri также относится возможность быстрой работы ArcGIS for Server при включенном сглаживании. Сглаживание надписей на карте включено уже по умолчанию, сглаживание линий можно легко включить для сервиса, и это не приведет к существенному падению производительности.

Тем не менее, повторюсь, что интернет-пользователи являются самыми требовательными к производительности, и карты, предназначенные для публикации на сервере, должны быть оптимизированы (суть – упрощены) по максимуму. Для упрощения отображения условных знаков разработан стиль Esri Optimized, который настоятельно рекомендуется использовать для оформления карт, которые будут публиковаться на сервере. Старайтесь избегать использования различных «красивостей», если они не являются функционально необходимыми. Пример: условный знак государственной границы (рис. 8). Нужен ли такой знак на электронной карте в интернете? Если же такие «красивости» являются крайне необходимыми, то имеет смысл рассмотреть вопрос о вынесении их в отдельные кэшированные сервисы, которые обсудим далее. И еще раз повторю, что следует избегать отображения лишних слоев, объектов, а также надписей.


Рис. 8. Пример сложного условного знака.

При подготовке данного материала был проведен ряд экспериментов по исследованию влияния различных факторов на производительность системы, и было выяснено, что отображение простых надписей занимает столько же времени, что и отображение аннотаций. И этот факт справедлив и для Desktop, и для Server. Если использовать расстановку надписей средствами Maplex, то падение производительности слоя надписей составит от 2 до 10 раз. Если указать опцию «качественной» расстановки надписей в Maplex, то дополнительное падение производительности составит еще от 1,5 до 2 раз. Для тестирования производительности отображения надписей и аннотаций нами использовалась топокарта масштаба 1:1 млн. (рис. 9).


Рис. 9. Пример для тестирования производительности работы с надписями и аннотациями.

Следующим фактором, которой может испортить производительность всей системы, является перепроецирование «на лету». Приведение всех данных в единую проекцию для их совместного отображения, изменение проекции данных для корректного измерения длин, площадей или просто для просмотра данных в привычной форме являются основными причинами, которые приводят к необходимости использования этой функции ПО. Перепроецирование «на лету» является одной из ключевых функций любой ГИС, но задумывались ли вы, «сколько это стоит»? Падение производительности при перепроецировании «на лету» составляет от 2 до 50 раз. Таким образом, можно «уронить» быстродействие любой, даже отлично оптимизированной системы.

В довольно длинном предыдущем тексте озвучивается мысль «это приводит или может привести к падению производительности». Конечно, понятно, что указанных действий следует избегать, но каким же образом можно поднять производительность в уже оптимизированной системе? Способ, разумеется, есть, и называется он «кэширование». Причем этот способ применяется и для серверных, и для настольных решений. Кэширование представляет собой предварительное построение изображений в указанных масштабах для последующей выдачи этих готовых изображений пользователю. Кэшированные сервисы ArcGISforServer не только выдают нужные фрагменты карты практически мгновенно, они еще и практически не загружают процессор. В кэшированные сервисы имеет смысл выносить все слои электронной карты, геометрия и условные знаки которых изменяются довольно редко. Такие сервисы с успехом можно применять для объектов, у которых изменяется атрибутивная информация, не влияющая на отображение. Поиск объектов по атрибутам, идентификация объектов будут выполняться абсолютно корректно, поскольку при запросе к атрибутам происходит запрос к реальным данным. У кэша есть один серьезный недостаток – длительное время построения, причем каждый следующий масштаб кэша строится столько же, сколько все предыдущие масштабы вместе взятые. Построение кэша на большое количество масштабов может занимать несколько суток или недель. В качестве ускорителя построения кэша может быть использована опция «построения кэша по запросу». При использовании этой опции кэш будет строиться при первом просмотре каждого фрагмента карт-сервиса в определенном масштабе. При необходимости внесения изменений в геометрию данных кэшированного сервиса можно перестроить кэш на часть данных, ограниченную указанным экстентом или полигоном.

В среде ArcGIS for Desktop также есть возможность использования кэша с помощью «слоёв базовых карт» (рис. 10). Эта функциональность появилась в ArcGIS 10. Поскольку это кэшированные слои, то они предназначены только для чтения. При первом отображении ArcMap строит кэшированные изображения «слоёв базовых карт» на локальном диске в каталоге C:Users<login_name>AppDataLocalESRILocal CachesBmLCacheV1 (Desktop 10.2.1), и при последующих перерисовках обращение идет к созданному кэшу, а не к исходным данным. Этот механизм аналогичен «кэшированию по запросу» ArcGIS for Server. При использовании слоев базовой карты уменьшение времени отображения составляет до десятка раз для разумно составленных карт. Выигрыш зависит от объема и сложности данных, сложности условных знаков, наличия надписей. Если карта составлена неразумно (например, как на рис. 1), то за счет кэширования ускорение отображения составит сотни и даже тысячи раз. Подобным образом работает и «Кэш объекта» (рис. 11), но при этом данные из базы кэшируются в память компьютера, и при перерисовке карты ArcMap не обращается к базе данных.


Рис. 10. Создание «слоя базовой карты».


Рис. 11. Использование кэша объектов.

Кэшированные сервисы обладают максимальной производительностью, но такие сервисы невозможно или неудобно использовать для отображения данных, у которых регулярно меняется геометрия и/или условные знаки. Какие сервисы следует использовать для оперативных данных, ведь ArcGIS позволяет выпускать разные варианты карт-сервисов? Прежде всего, при ответе на этот вопрос необходимо руководствоваться требуемой функциональностью, а уже потом производительностью. Если требуется редактирование данных, то должен использоваться сервис объектов. Если предполагается использование ArcGIS сервисов в не-ArcGIS системах, то, возможно, KML или WMS. Но если всего этого не требуется, то картографические REST-сервисы и кэшированные сервисы будут лучшим выбором. На рисунке 12 приведено сравнение производительности различных типов картографических сервисов. За единицу измерения взята производительность картографического REST-сервиса.


Рис. 12. Количество запросов в единицу времени для разных типов сервисов.

Помимо задач оптимизации данных и сервисов, практически всегда при проектировании веб-ГИС возникает вопрос о том, на основе какого API разрабатывать веб-приложение, которое будет лицом системы. При выборе API следует учитывать следующие параметры:

  • скорость работы приложения, время отклика на действия пользователя;
  • удобство веб-приложения для пользователя (поддержка различных платформ, необходимость установки соответствующего плагина, возможность построения удобного интерфейса);
  • удобство программирования на конкретном API, наличие примеров;
  • наличие визуальных конструкторов веб-приложений;
  • перспективы развития и поддержки каждого API.

В настоящее время для построения ГИС-веб-приложений в системе ArcGIS доступно три API: Flex, JavaScript, Silverligth. При выборе по первому из перечисленных выше параметров необходимо учитывать браузер и даже версию браузера. По этому вопросу есть достаточно много статей в интернете. По второму параметру наиболее подходящими являются приложения на основе JavaScript. Приложения на JavaScript являются самыми мультиплатформенными, не требуют установки плагина. Примеры для всех трех API есть на сайте Esri (resources.arcgis.com), а удобство программирования зависит более от личного опыта программиста, чем от реального положения дел. С конструкторами также все обстоит хорошо, для всех трех API есть визуальные конструкторы, так называемые Viewer’ы. Все конструкторы доступны на resources.arcgis.com. Для JavaScript разработано два варианта конструкторов: один визуальный от Esri, другой настраиваемый через конфигурационный файл от ЭСРИ СНГ (https://github.com/ESRI-CIS/jsviewer). В настоящее время мы видим активное развитие HTML5, поддержка которого включена в JavaScript. Развитие HTML5 расширяет функциональность HTML и приводит к ненужности дополнительных плагинов. Таким образом, в качестве более перспективного API следует ориентироваться на JavaScript API.

Вернемся к средствам тестирования производительности. Инструмент MXDPERFSTAT для настройки документов карт уже был рассмотрен. Для оценки производительности сервисов ArcGIS Server хорошо подходит приложение System Test от компании Esri. Данное приложение позволяет создать план нагрузочного тестирования, провести такое тестирование и наглядно представить его результаты. Интерфейс System Test и примеры результатов тестирования приведены на рис. 13. Это приложение бесплатно, его можно скачать с сайта Esri (поиск по «System Test arcgis» на google.com).


Рис. 13. Интерфейс приложения System Test и примеры результатов тестирования.

При оптимизации системы в целом не следует забывать и про скорость передачи данных по сети. Причем, здесь играет роль не только скорость, как таковая, но и задержки при передаче. Например, именно из-за задержек между запросом и ответом так неудобен в работе спутниковый интернет, который, тем не менее, дает возможность закачки больших файлов. Если вам не довелось использовать спутниковые каналы связи, то вы счастливый человек. Но подумайте о тех людях, которые его используют и которые, возможно, будут использовать ваши веб-приложения и сервисы. Если предполагается использовать довольно «узкий» канал связи, то веб-приложение должно быть как можно более простым, должно использовать минимальное количество ресурсов. Например, прекрасно работающее в пределах локальной сети веб-приложение с пятью кэшированными сервисами, двумя картографическими REST-сервисами и одним сервисом объектов при работе по «узкому» каналу связи покажет недопустимо низкую производительность, а приложение с двумя-тремя сервисами будет работать значительно быстрее. Понятно, что следует уменьшать количество сервисов, одновременно усложняя каждый из оставшихся, но дать какие-либо конкретные рекомендации в данном случае трудно. На помощь могут прийти различные приложения по проверке пропускной способности сети. Например, ранее на сайте Esri была доступна утилита Network Speed Test, сейчас ее можно получить по запросу в ЭСРИ СНГ.

В вопросах оптимизации важное место занимают как средства контроля производительности, так и средства контроля работоспособности. В данном случае вы оптимизируете не работу ГИС, а свой собственный рабочий процесс. Контроль за работой ArcGIS for Server можно осуществлять с помощью журналов ArcGIS for Server, располагающихся в каталогах C:arcgisserverlogsservices и C:Program FilesArcGISServerframeworketcservicelog. По умолчанию журналы регистрируют информацию о работе сервера в минимальном объеме, но 7 вариантов детализации позволяют выставить нужный уровень содержательности журналов. Просматривать журналы можно как в веб-приложении ArcGIS Server Manager, так и с помощью текстовых редакторов, либо с помощью приложения Log Parser 2.2 от Microsoft (http://technet.microsoft.com/en-us/scriptcenter/dd919274.aspx) с дополнением AsLog от Esri (доступно на странице http://resources.arcgis.com/gallery/file/enterprise-gis).

К сожалению, сам ArcGIS for Server не сообщит вам о том, что с ним что-то не в порядке. Но с помощью бесплатного приложения System Monitor от Esri (поиск по «System Monitor arcgis» на google.com) вы можете настроить отправку сообщений ГИС-администратору в случае превышения каких-либо критических значений. Помимо этого, System Monitor позволяет строить графики загрузки аппаратных ресурсов сервера конкретными сервисами ArcGIS for Server. Для оценки загруженности ресурсов сервера удобно использовать и стандартный Монитор ресурсов Windows (рис. 14).


Рис. 14. Отображение загрузки ресурсов компьютера в Мониторе ресурсов Windows.

Резюмируя всё вышеизложенное, хочется сказать следующее:

  • Не впадайте в крайности, далеко уходя по одному избранному пути оптимизации, не забывайте о комплексном подходе к решению задачи оптимизации, помните о наличии множества путей решения каждой проблемы или задачи.
  • Помните о множестве последствий, вызываемых каждым действием, старайтесь не упускать из вида значимые последствия и предугадывать будущие последствия при появлении новых ограничивающих факторов.
  • Помните, что чем проще система, тем она надежнее и быстрее работает. Можно даже перефразировать известное изречение: простота спасет ГИС.
  • Никакие рекомендации не заменят ваших собственных тестов на ваших данных и в ваших условиях, хотя общие вышеперечисленные рекомендации необходимо учитывать и прислушиваться к ним.

Терпения вам и красивых идей !


Tweet
Like
Share

Также может быть интересно