Результаты тестов по влиянию конфигурации ArcSOC

Помимо оценки ресурсов базы данных, второй набор тестов был сосредоточен на определении оптимальной конфигурации ArcSOC для поддержки 8-кратной нагрузки на нашу систему и её рабочие процессы при условии достаточного количества ресурсов базы данных.

Методы и результаты тестирования

Было выполнено три теста с разными соотношениями ArcSOC : vCPU:

• 2:1, or two ArcSOCs per vCPU on the ArcGIS Server instances
• 3:1, or three ArcSOCs per vCPU on the ArcGIS Server instances
• 4:1, or four ArcSOCs per vCPU on the ArcGIS Server instances

Мы также провели этот тест с соотношением ArcSOC к vCPU 1:1, что можно увидеть в тесте большого экземпляра базы данных, описанном в разделе Оценка воздействия ресурсов базы данных.

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

Для оценки каждой конфигурации отслеживались метрики производительности, такие как использование и доступность ArcSOC, время ожидания сервиса, использование системных ресурсов и частота error .

Тесты проводились при нагрузке в 8 раз выше, чем в первоначальном тестовом исследовании, а ресурсы сервера ArcGIS Enterprise были сокращены вдвое, чтобы обеспечить достаточную нагрузку для влияния на систему. JMeter использовался для моделирования рабочих процессов пользователя и измерения производительности системы при различных нагрузках.

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

2:1 ArcSOCs : vCPU ratio

В этом запуске мы настроили два ArcSOC на один vCPU на экземплярах ArcGIS Server. В данном случае 16 работающих ArcSOC на 8 vCPU. Как и на предыдущих графиках, загрузка CPU показана оранжевым, диска — золотым, а памяти — фиолетовым.

На графике ниже загрузка CPU для всех машин обычно менее 60%. Однако можно увидеть, что использование памяти на UN GIS Server превышает 80%. Это связано с увеличением количества работающих ArcSOC по сравнению с соотношением 1:1. Сервисы на UN GIS Server поддерживают версионное редактирование базы данных. Хотя система работает стабильно, необходимо внимательно следить за использованием памяти, чтобы избежать проблем. Диаграмма параллельных запросов показывает, что запросы на одновременный просмотр (красный) стабильно открываются и закрываются, в среднем 35.

График ниже показывает использование ArcSOC на хостинг-сервере, где работает 16 ArcSOC (синяя линия закрыта зелёной линией), максимальное использование (занято) — 14. Сервер UN GIS Server (не показан) имел максимум 7 занятых ArcSOC, поэтому он не использовал дополнительные экземпляры сервисов, где работало 16 ArcSOC, но в основном они были в режиме простоя. Поскольку этот сервер показывал использование памяти более 80%, снижение количества экземпляров сервисов до минимум/максимум 8 на UN GIS Server могло бы снизить часть нагрузки на память и сделать систему оптимальной для этих рабочих процессов и загрузок. Любые изменения в рабочих процессах или нагрузках могут повлиять на баланс.

3:1 ArcSOCs to vCPU ratio

В этом запуске мы настроили три ArcSOC на один vCPU. В данном случае 24 работающих ArcSOC на 8 vCPU. Как и ранее, загрузка CPU (оранжевый) обычно ниже 60% на всех машинах. К сожалению, загрузка памяти (фиолетовая) на UN GIS Server достигла максимума, с падениями до 95% в процессе очистки. Запросы на одновременный просмотр (красный) показывают, что они стабильно открываются и закрываются, в среднем 36. Эта система, похоже, справляется с нагрузкой, но из-за нехватки памяти это неустойчиво.

Кроме того, посмотрев на график ArcSOC ниже, можно увидеть, что при соотношении 3:1 на UN GIS Server работает 24 ArcSOC (синяя линия закрыта зелёной линией). Однако максимальная нагрузка — всего 18, при этом остальные продолжают потреблять память. Это пример неудачной конфигурации. Наша рабочая нагрузка не требует всех доступных ArcSOC. Шесть ненужных (24 работающих минус 18 занятых) расходуют ресурсы (память) без необходимости. Увеличение памяти на UN GIS Server может улучшить эту ситуацию, но также может перенести проблему на CPU или базу данных. Для принятия правильных решений по конфигурации и архитектуре системы требуется тестирование и наблюдение.

4:1 ArcSOCs to vCPU ratio

В этом запуске на каждый vCPU было настроено четыре ArcSOC. В данном случае 32 работающих ArcSOC на 8 vCPU на UN GIS Server. Загрузка CPU (оранжевая) растёт, с двумя пиками выше 80% на UN GIS Server. Однако самая большая проблема — почти 100% использование памяти (синий) на этом экземпляре, когда даже процесс очистки с трудом справляется.

Запросы на совместный просмотр (красный) внизу показывают, что они всё ещё стабильно открываются и закрываются, с тем же средним показателем 36, как и в соотношении 3:1. Это показывает, что дополнительные ArcSOC не приносят никакой пользы производительности системы или опыту конечного пользователя. Скорее, они просто потребляют ресурсы ГИС-сервера.

Это дополнительно подтверждается диаграммой ArcSOC ниже, где максимум 16 занятых ArcSOCs. Здесь ясно видно, что добавление дополнительных экземпляров сервисов лишь потребляло ненужные ресурсы сервера, не давая при этом повышения производительности или пользовательского опыта. Увеличение CPU и памяти UN GIS Server может улучшить результаты, но это может перенести проблему на CPU сервера базы данных. Тестирование и наблюдение — ключ к успеху.