Предварительное тестирование

Предварительное тестирование — это шаг в нашем процессе, направленный на улучшение результатов наших формальных тестов. Предварительное тестирование дает возможность:

• Выявления узких мест системы, которые могут снизить производительность и удобство ее использования под нагрузкой
• Экспериментирования с различными настройками и конфигурациями в итеративном режиме
• Оптимизации более формального процесса нагрузочного тестирования

Первоначальная физическая архитектура была почти идентична ранее протестированной базовой системе управления сетевой информацией, настроенной на основе SAP HANA, с добавлением только клиентской точки VPN AWS для подключения мобильных устройств. Во время предварительного тестирования мы определили, что система не будет поддерживать запланированную нагрузку с дополнительными рабочими нагрузками, показанными ниже. Затем архитектура была соответствующим образом скорректирована, как описано в физической архитектуре. Окончательные результаты тестирования после внесения этих изменений можно увидеть в разделе результаты тестирования.

Предварительные испытания при 4-кратной проектной нагрузке

Сначала система была протестирована с основными рабочими процессами управления сетевой информацией, работающими без мобильных рабочих процессов, как показано в левой части рисунка ниже. За исключением скачка в ArcGIS Web Adaptor 02 в начале теста, связанного с установкой обновлений Windows Defender, использование ресурсов относительно низкое.

Сравните это с правой частью рисунка, где показано, как добавление мобильных рабочих процессов в дополнение к 4-кратной нагрузке приводит к значительной загрузке процессора в экземплярах ArcGIS Web Adaptors и Portal for ArcGIS. Веб-адаптеры ArcGIS перегружены, что приводит к замедлению обработки запросов или превышению времени ожидания. Все четыре ГИС-сервера и база данных также демонстрируют более высокую загрузку процессора (оранжевый) и дискового пространства (золотой). Это связано с этапом загрузки в автономных рабочих процессах, где автономная область размером 2,66 ГБ загружается большим количеством мобильных сотрудников.

Открытые запросы только для базовой нагрузки, показанные ниже (слева), иллюстрируют, как система справляется с нагрузкой. В начале теста наблюдается небольшое наращивание открытых запросов, которое стабилизируется максимум с 19 редакторами и 11 вьюерами. Однако когда добавляется дополнительная мобильная нагрузка (справа), число запросов увеличивается до 42 настольных (вьюеров и редакторов) и 127 одновременных мобильных запросов, прежде чем загрузка завершится и нагрузка спадет. Эта закономерность указывает на замедление на этапе тестовой загрузки, когда пользователи ждут завершения загрузки автономной области.

Размеры экземпляров

Во время предварительного тестирования мы наблюдали длительное время загрузки для автономных областей (размером 2,66 ГБ), которое составляло более 30 минут (см. рисунок ниже). После частичного устранения неполадок мы определили, что проблема возникает из-за очень высокой загрузки CPU в экземплярах ArcGIS Web Adaptor and Portal for ArcGIS, что ограничивало пропускную способность и приводило к задержке загрузки. Чтобы решить эту проблему, количество экземпляров ArcGIS Web Adaptor было увеличено с 2 до 8 vCPU, а количество экземпляров Portal for ArcGIS было увеличено с 4 до 8 vCPU.

В частности, этап загрузки автономных рабочих процессов выиграл от увеличения размера экземпляров ArcGIS Web Adaptor и Portal for ArcGIS, при этом время загрузки сократилось на 41%. Однако это избыточная емкость, когда большое количество загрузок не выполняется. В производственной среде мы ищем способ масштабирования этих компонентов в периоды пиковой нагрузки и уменьшения размеров экземпляров, когда в этом нет необходимости, чтобы снизить затраты. Поэтому оптимизация ресурсов при балансировке размера офлайн-карт (уменьшение их размера при сохранении покрытия необходимой области) имеет решающее значение для получения правильного соотношения производительности и затрат.

• Узнайте больше о рекомендациях по переводу ваших карт в автономный режим.

Конфигурация экземпляра сервиса

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

Поскольку на двух хост-серверах было доступно 16 vCPU, первоначальные настройки экземпляра мобильного сервиса инженерной сети и сервиса газовой коммунальной сети, доступной только для чтения, были установлены следующим образом:

• Минимум: 8
• Максимум: 8

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

Количество экземпляров сервиса для мобильного сервиса инженерной сети было уменьшено с минимума и максимума равного 8 до минимума и максимума равного 6. Количество экземпляров сервиса для сервиса газовой сети было увеличено с минимума и максимума равного 8 до минимума и максимума равного 10. После внесения изменений диаграммы показывают более равномерное распределение между обоими сервисами, а время ожидания пользователей заметно сократилось.

• Узнайте больше о настройке и конфигурировании сервисов
• Подробнее о настройке параметров экземпляра сервиса

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

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

• Размер экземпляров ArcGIS Web Adaptor был увеличен с 2 до 8 vCPU.
• Размер экземпляров Portal for ArcGIS был увеличен с 4 до 8 vCPU.
• Размер автономных зон был оптимизирован так, чтобы сделать их как можно меньше и при этом охватить необходимую область.
• Конфигурация ArcSOC была скорректирована для обеспечения более равномерного распределения использования и сокращения времени ожидания как в мобильном сервисе инженерной сети, так и в сервисе газовой инженерной сети.