Багато шарів в одній чи кількох службах? (і чому)

У мене є загадка про те, що я отримую неоднозначні поради щодо того, як діяти. Тому я люблю ставити його на GIS-SE для деяких обґрунтованих відповідей.

Сценарій:

• Клієнт має програму веб-картографування. Не хоче розділятись на кілька менших додатків. Хоча це суперечить тому, що сучасний підхід для карт в Інтернеті (тобто багато сфокусованих додатків для веб-карт на одній головній веб-карті), я твердо вірю, що для деяких користувачів намагаються повторити GIS-додаток у мережі. ок ( іноді ).

• Клієнт кешував стільки своїх шарів базової карти в окремі сервіси.

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

Я думаю, ваша початкова реакція на це схожа на мою (600+ ?! WTF ?!)

Однак - вимога встановлена ​​в камені, а чому ні? Їх попереднє додаток ArcIMS мало аналогічну функціональність, тож чому цей новий продукт ArcGIS Server не може зробити те саме? Користувачі, можливо, повинні мати можливість перехрещувати порівняння та проводити аналіз у всьому діапазоні шарів, навіть якщо шари належать до інших відділів.

Перш ніж перейти до висновків, клієнт - це адміністратор ArcGIS Server.
Вони ввели 600 шарів за всіма правилами найкращої практики: наприклад, діапазони масштабів у поєднанні із запитами визначення; анотація над маркуванням; узагальнення складних шарів у малих масштабах; публікувати як MSD; тощо

Проблема :

Який тут кращий підхід?

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

2. Розбийте шари на логічні групи (гідрологія, планування, екологія, комунальні послуги тощо)

Якщо ви переходите з №1, у вас увімкнено кілька складних шарів. Якщо ви хочете ввімкнути простий шар точок, то ArcGIS серверу все одно доведеться повторно відображати всі шари.

Якщо ви переходите з номером №2, кожен раз, коли ви робите запит, потенційно, веб-додаток може зробити кілька запитів GET для ExportMaps з окремих служб карти (це погано, чи це створює додаткове навантаження на сервер ArcGIS протягом №1 ?)

І тоді це призводить до налаштування та налаштування, щоб забезпечити все якомога швидше. Ми можемо масштабувати задній кінець ArcGIS Server на декількох хостах і мати гарне обладнання для його роботи.

Якщо ви перейдете з номером №1, ви можете викинути максимум # екземплярів, з якими ви можете працювати з AGS.

Якщо ви переходите з номером №2, я вважаю, що ви оцінюєте ефективність служби карт (тестування навантажень і переглядаєте терміни очікування) і відповідно звертаєтесь до випадків min / max, щоб переконатися, що немає жодної служби, яка є "слабкою ланкою".

Наразі я схиляюся до підходу №2, оскільки моя голова все ще говорить мені, що мати 600 шарів в одній службі - це божевілля, але якщо всі вони відключені за замовчуванням, насправді немає жодної проблеми.

Хотів би почути ваші думки. Повідомте мене, якщо вам потрібна додаткова інформація через коментарі, але не шукайте відповідей, як-от "використовувати настільний додаток" або "навчити їх робити щось інакше"

З обговорень у коментарях я не міг згадати ще один розгляд. Додаток, яким буде користуватися послуга, має можливість захисту рівня шарів (на рівні програми). Тому група користувачів (що є досить великою) відведена певній ролі, і ця роль матиме доступ до повних 600 шарів. Інші ролі будуть обмежені.

Використовували Інструмент планування ємності, щоб допомогти порівняти одну надзвичайно важку карту сервісу та 4 прості сервіси карт, а результати свідчать про те, що послуга важких карт - це шлях.

Це може бути не правильною відповіддю, і інструмент планування потенціалу не враховує кожен фактор (наприклад, робочі процеси користувачів) - повідомте мені через коментарі, що ви думаєте.

1 надзвичайно важка послуга карт:
використання CPU-сервера додатків = 49,4%
використання CPU сервера баз даних = 7,6%
завантаження мережі = 16 Мбіт / с
Час реакції на дисплей = 0,88 сек

(Зображення можна побачити великим рівнем РК та відкрити в новій вкладці)

4 Lite служби карт:
використання CPU-сервера додатків = 55,4%
використання CPU сервера баз даних = 7,6%
завантаження мережі = 64 Мбіт / с
Час реакції на дисплей = 0,32 сек кожна, тобто від 0,32 до 1,28 сек в залежності від накладних витрат веб-браузера

Більше логіки для підтримки єдиного підходу до обслуговування карт:

1. Тому всі шари знаходяться в одній картковій службі;
   а. один запит надсилається на сервер
   b. один процес SOC малює карту
   c. одне зображення повертається по мережі

2. Отже, 40 шарів розкинуті на 4 сервіси карт (по 10 шарів у кожному);
   а. 4 запити надсилаються на сервер
   b. 4 Процеси СОЦ складають карту
   c. 4 зображення повертаються по мережі

1a та 1c будуть швидшими та поставлять менше навантаження на мережу, ніж 2a та 2c.

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

Хоча використання декількох сервісів, масштабування шарів / міток, кешування та використання нединамічних міток допомагають покращити роботу веб-додатків, кінцевий користувач помітить початкове звернення до завантаження всіх 600+ шарів в один додаток. Особливо час, який потрібен для заселення TOC. Якщо вам доведеться створити додаток на рівні 600+, я б неодмінно перейшов із варіантом №2. Можливо, ви захочете моделювати структуру даних на основі моделі даних (наприклад, моделі даних органів місцевого самоврядування).

У нижній статті нижче висвітлено деякі цікаві рекомендації щодо найкращої практики та статистичні показники для конфігурацій веб-додатків ArcGIS Server.

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