В нашем первом наборе тестов мы изучали влияние ресурсов базы данных на способность системы справляться с нагрузкой даже при наличии достаточных ресурсов ГИС-сервера. Это позволяет показать, насколько велика роль базы данных для всей системы. Другими словами, если ваши пользователи сталкиваются с долгим ожиданием, проблема может быть не только в уровне ArcGIS Server.
Эти тесты проводились с оптимизированной конфигурацией базы данных, чтобы подчеркнуть критическую роль правильно настроенной и обеспеченной ресурсами базы данных в общей производительности системы ArcGIS. Однако в ваших системах стоит сосредоточиться на оптимизации и настройке базы данных перед масштабированием оборудования. Улучшение производительности базы данных за счёт настройки часто более экономично и может решить проблемы с плохой производительностью без необходимости дополнительных инвестиций в инфраструктуру.
Мы провели два теста, чтобы сравнить, как ресурсы базы данных влияют на производительность системы даже при наличии достаточного количества ресурсов сервера:
Все остальные параметры системы оставались неизменными, с конфигурацией ArcSOC 1:1. Другими словами, на каждый vCPU экземпляра ArcGIS Server был настроен один ArcSOC, и количество ArcSOC и vCPU совпадало. Мы фиксировали и отслеживали метрики производительности, такие как использование и доступность ArcSOC, время ожидания сервиса, использование системных ресурсов и частоту error для оценки каждой конфигурации. Тесты проводились при нагрузке в 8 раз выше, чем в первоначальном тестовом исследовании, а ресурсы сервера ArcGIS Enterprise были сокращены вдвое (по сравнению с предыдущими тестовыми исследованиями), чтобы обеспечить достаточную нагрузку для влияния на систему.
Поскольку ArcGIS является многоуровневой системой, тесты производительности проводились на уровнях клиента, сервиса и хранилища данных, а также на самой инфраструктуре. В этом тестовом исследовании JMeter использовался для моделирования рабочих процессов пользователя и измерения производительности системы при различных нагрузках.
Этот запуск выполнялся с 8 виртуальными процессорами, доступными на экземпляре PostgreSQL для наблюдения за воздействием системы на уменьшенный сервер базы данных. ArcGIS GIS Server (UN Server) также был настроен с 8 vCPU. Ниже приведены шесть диаграмм ресурсов экземпляров, показывающих использование ресурсов по системе, и одна диаграмма, показывающая параллельные запросы. В каждой из таблиц ресурсов оранжевые линии обозначают % загрузки процессора, золотые — % использования диска, а фиолетовая — % использования памяти.
На диаграмме ниже видно, что CPU базы данных PostgreSQL загружен на 100%, а CPU хост-сервера часто достигает 100%. Это связано с большим количеством запросов на просмотр, связанных с рабочими процессами при нагрузке, превышающей расчетную в 8 раз.
Нижний график показывает параллельные запросы, измеренные по логам JMeter. Обратите внимание, что красная линия, обозначающая запросы на одновременный просмотр, движется до 538 по мере запуска теста. Это означает, что запросы не закрываются. На следующих графиках вы увидите, как эта линия стабильно движется вверх и вниз, что указывает на то, что система реагирует, а запросы закрываются достаточно быстро, чтобы справиться с нагрузкой.

Эта конфигурация не выдержала нагрузку, потому что сервер базы данных был недостаточно обеспечен ресурсами, что видно по высокой загрузке CPU PostgreSQL (оранжевый цвет), пикам CPU хост-сервера и числу параллельных запросов.
Для дополнительного подтверждения этого ниже показана диаграмма использования ArcSOC на хост-сервере, зафиксированная утилитой Soccer (ArcSOC Monitoring), которая работает на удалённой машине. Красная линия показывает загруженные ArcSOC на 100% (8), вероятно, из-за перегруженной базы данных. ArcSOC остаются занятыми, пока ждут ответа базы данных. На самом деле, ArcSOC были настолько загружены, что Soccer не мог отслеживать их состояние, что видно по прерывистой красной линии и резким падениям максимума (зелёной линии).

Во втором тесте мы увеличили экземпляр базы данных PostgreSQL до 16 vCPU, чтобы оценить возможные отличия от первого теста. ГИС-серверы ArcGIS по-прежнему были настроены с 8 vCPU каждый. Как и на предыдущей диаграмме, загрузка CPU показана оранжевым, диска — золотым, а памяти — фиолетовым. Обратите внимание, что, за исключением нескольких скачков, все серверы обычно работают ниже 60% загрузки CPU, диска и памяти.
Диаграмма параллельных запросов показывает в среднем 36 запросов на одновременные просмотры с некоторыми скачками. Количество открытых запросов не растет, как на предыдущем графике, что указывает на то, что система справляется с нагрузкой.

График ArcSOC ниже показывает, что ArcSOC на хостинг-сервере заняты, но общий отклик системы хороший. Хотя 99% (p99) использования составляет 8 socs или меньше, средний результат составляет 4.81. Позже мы рассмотрим пользовательский опыт, чтобы узнать, позволяет ли система людям работать эффективно.

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

На графике выше видно, как увеличенное насыщение системных ресурсов в тесте с небольшой базой данных приводит к увеличению времени выполнения рабочих процессов, что в целом приводит к ухудшению пользовательского опыта. Общее время выполнения всех рабочих процессов значительно увеличилось при недостаточно обеспеченной базе данных по сравнению с правильно настроенной, даже если ArcGIS Server был хорошо обеспечен. В частности, рабочий процесс View Assets показал значительное сокращение времени выполнения при правильно настроенной корпоративной базе геоданных.
Помимо общего времени выполнения рабочего процесса, мы можем глубже изучить, как ресурсы базы данных влияют на продолжительность отдельных этапов редактирования. Однако видна существенная разница в продолжительности открытия проекта и поиска ресурса в рабочем процессе Update Assets. Аналогично, процесс Electric Tracing показал значительный рост на всех этапах рабочего процесса. Эта закономерность сохранялась во всех анализируемых рабочих процессах.
