Много слоев в одном или нескольких сервисах? (и почему)

У меня есть загадка, что я получаю смешанный совет о том, как поступить. Поэтому я хотел бы поставить его в ГИС-SE для некоторых обоснованных ответов.

Сценарий:

• Клиент имеет веб-картографическое приложение. Не хочет разбиваться на несколько небольших приложений. Хотя это идет вразрез с современным подходом к картам в Интернете (т. Е. Множеству сфокусированных приложений веб-карт на одной главной веб-карте), я твердо убежден, что для некоторых пользователей попытка реплицировать ГИС-приложение в Интернете хорошо ( иногда )

• Клиент кэшировал столько своих слоев базовой карты в отдельные сервисы.

• Клиенту все еще требуются дополнительные 600-700 слоев в сервисе динамических карт ...
• Сервис будет опубликован с отключением всех этих слоев .
• Не ожидается, что пользователи будут включать более 10-40 слоев одновременно.

Я полагаю, ваша первоначальная реакция на это похожа на мою (600+ ?! WTF ?!)

Однако - требование установлено в камне, и почему нет? Их предыдущее приложение ArcIMS имело аналогичную функциональность, так почему этот новый продукт ArcGIS Server не может сделать то же самое? Потенциально пользователи должны иметь возможность перекрестного сравнения и выполнения анализа по всему диапазону уровней, даже если уровни принадлежат другим отделам.

Прежде чем делать выводы, клиент является администратором ArcGIS Server.
Они установили 600 уровней по всем правилам передовой практики: например, диапазоны шкалы в сочетании с запросами определения; аннотация над маркировкой; обобщающие сложные слои в небольших масштабах; публиковать как MSDs; и т.д

Проблема :

Какой подход лучше?

1. Опубликовать все 600 слоев в одном сервисе динамических карт

2. Разделите слои на логические группы (гидрология, планирование, экология, коммунальные услуги и т. Д.)

Если вы идете с # 1, и у вас включено несколько сложных слоев. Если вы хотите включить слой простых точек, то ArcGIS Server все равно придется визуализировать все слои, отображаемые заново.

Если вы переходите к # 2, то каждый раз, когда вы делаете запрос, возможно, веб-приложению может потребоваться выполнить несколько запросов GET для ExportMaps от отдельных картографических сервисов (это плохо, или это создает дополнительную нагрузку на ArcGIS Server через # 1 ?)

А затем это приводит к настройке и настройке, чтобы все было как можно быстрее. Мы можем масштабировать серверную часть ArcGIS Server до нескольких хостов и иметь хорошее оборудование для его установки.

Если вы идете с # 1, вы можете выбросить максимальное количество экземпляров, которые AGS может обработать.

Если вы перейдете к # 2, я предполагаю, что вы оцените производительность картографических сервисов (нагрузочное тестирование и посмотрите на время ожидания) и соответственно рассмотрите экземпляры min / max, чтобы убедиться, что нет ни одного сервиса, который является «слабым звеном».

В настоящее время я склоняюсь к подходу № 2, так как моя голова все еще говорит мне, что наличие 600 слоев в одном сервисе - это безумие, но если они все отключены по умолчанию, на самом деле проблем нет.

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

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

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

Это может быть неправильный ответ, и инструмент планирования емкости не учитывает все факторы (например, рабочие процессы пользователей) - сообщите мне через комментарии, что вы думаете.

1 сверхтяжелый картографический сервис:
загрузка ЦП сервера приложений = 49,4%
загрузка ЦП сервера базы данных = 7,6%
нагрузка на сеть = 16 Мбит / с
Время отклика дисплея = 0,88 с

(Изображения можно увидеть в большом масштабе по RC и открыть в новой вкладке)

4 облегченных картографических сервиса:
загрузка ЦП сервера приложений = 55,4%
загрузка ЦП сервера базы данных = 7,6%
нагрузка на сеть = 64 Мбит / с
Время отклика дисплея = 0,32 с каждый, поэтому от 0,32 до 1,28 с, в зависимости от накладных расходов веб-браузера

Больше логики для поддержки подхода с одним картографическим сервисом:

1. Поэтому все слои находятся в одном картографическом сервисе;
   а. один запрос отправляется на сервер
   b. один процесс SOC рисует карту
   c. одно изображение возвращается по сети

2. Таким образом, 40 слоев распределены по 4 картографическим сервисам (по 10 слоев в каждом);
   а. 4 запроса отправлено на сервер
   b. 4 процесса SOC рисуют карту
   c. 4 изображения возвращаются по сети

1a и 1c будут быстрее и будут загружать сеть меньше, чем 2a и 2c.

2b может использовать параллельную обработку для возврата карты быстрее, чем 1b для одного пользователя, но это не будет иметь место для многих пользователей. Фактически, накладные расходы на дополнительные транзакции, обрабатываемые сервером в 2b (плюс дополнительная нагрузка на сеть 2c), будут значительно лучше масштабироваться по мере увеличения количества пользователей.

Хотя использование нескольких служб, масштабирование слоев / меток, кэширование и использование нединамических меток - все это помогает улучшить работу веб-приложения, конечный пользователь заметит начальный удар по загрузке всех 600+ слоев в одно приложение. Особенно время, необходимое для заполнения ТОС. Если вам нужно создать приложение с более чем 600 слоями, я бы определенно выбрал вариант №2. Возможно, вы захотите смоделировать свою структуру данных в соответствии с моделью данных (такой как модель данных местного правительства).

В приведенном ниже техническом документе приведены некоторые интересные рекомендации и статистические данные о производительности для конфигураций веб-приложений ArcGIS Server.

http://www.esri.com/library/whitepapers/pdfs/creating-arcgisserver-web-mapping.pdf