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

Тестирование было проведено с целью убедиться, что проект будет работать должным образом и поддерживать рабочие процессы, пользователей и предполагаемую нагрузку. Системные тесты дают возможность обнаружить и устранить проблемы во время развертывания системы в средах более низкого уровня сложности, в идеале до того, как они проявятся в рабочей среде. В данном тестовом исследовании основное внимание в подходе к тестированию уделялось проверке того, что система будет поддерживать рабочие процессы, а также пониманию того, как нагрузка будет влиять на систему, её компоненты и взаимодействие с конечными пользователями.

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

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

Подробнее см. в разделе о том, как разработать эффективную стратегию тестирования.

Темп рабочего процесса

В этом тестовом исследовании к протестированным рабочим процессам применялась модель темпа. Модель темпа показывает, как тестирование имитирует темп работы в организации, управляющей земельными участками, где рабочие процессы выполняются в виде определённого количества операций в час командой сотрудников. Этот подход был основан на данных, полученных от клиентов Esri, и был направлен на соответствие сценарию организации среднего размера, управляющей земельными участками, на котором основывались данные.

В течение одного часа тестирования рабочие процессы распределялись и запускались с интервалами, чтобы избежать одновременного начала, но при этом допускалось их перекрытие, что имитирует выполнение задач в реальных условиях. В приведённой ниже модели темпа показано, как были заданы темп выполнения каждого рабочего процесса и количество операций в час, определяющие «проектную нагрузку» системы.

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

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

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

Дополнительные сведения см. в разделе инструменты для тестирования производительности.

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

Эта архитектура была проверена с помощью автоматических нагрузочных тестов и пользователями вручную в трех сценариях, результаты каждого из которых приведены ниже. На высоком уровне результаты тестирования показывают, что в реализованном виде система обладает достаточными ресурсами для поддержки нагрузок от проектной нагрузки до 8-кратной проектной нагрузки. Испытания также подтвердили важность правильной настройки приложений и системы для обеспечения производительности.

Сценарий тестирования: Проектная нагрузка

Observations:

• Система поддерживала нагрузку
• Хост‑серверы (рабочие процессы просмотра) в среднем показывали загрузку процессора менее 30 % (оранжевые линии)
• Серверы участков (рабочие процессы редактирования) в среднем показывали загрузку процессора менее 40 %
• SQL Server демонстрировал очень низкую загрузку процессора, обычно оставаясь ниже 15 %
• Всплеск использования диска на экземпляре SQL Server можно объяснить фоновым процессом Windows (золотые линии)
• Параллельные запросы показывают, что система поддерживала примерно 3 одновременных запроса на просмотр (красные) и 1 одновременный запрос на редактирование (синие) в любой момент времени в течение тестового периода.

Сценарий тестирования: 4-кратная проектная нагрузка

Observations:

• Система выдержала нагрузку, при этом наблюдалось лишь незначительное увеличение использования ресурсов по компонентам.
• Хост‑серверы в среднем показывали загрузку процессора менее 40 %
• Серверы участков в среднем показывали загрузку процессора менее 50 %
• SQL Server в целом оставался ниже 40 % загрузки процессора
• Периодические всплески использования диска можно объяснить запуском рабочих процессов или выполнением отдельных шагов рабочего процесса. В частности, всплеск между 15:10 и 15:20 связан с рабочим процессом Суммирование участков, при котором одновременно открывается несколько панелей мониторинга.
• Параллельные запросы показывают, что система поддерживала в среднем от 10 до 15 одновременных запросов на просмотр и редактирование в течение тестового периода, с более крупными пиками запросов на просмотр, которые быстро завершались.

Тестовый сценарий: 8-кратная проектная нагрузка

Observations:

• Система выдерживает нагрузку, при этом наблюдается ожидаемое увеличение использования ресурсов по компонентам.
• Хост‑серверы в целом показывают загрузку процессора ниже 50 %.
• Серверы участков в целом показывают загрузку процессора ниже 50 %.
• SQL Server демонстрирует значительное увеличение использования ресурсов, стабильно достигая примерно 60 % загрузки процессора.
• Параллельные запросы показывают, что система стабильно поддерживала пики до 35 одновременных запросов на просмотр и в среднем два одновременных запроса на редактирование в течение тестового периода.
• Всплеск запросов на чтение в 20:20 связан с запуском рабочего процесса Суммировать участки.

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

Помимо использования ресурсов виртуальных компьютеров, мы также отслеживали использование ArcSOC‑процессов в каждом тестовом прогоне, чтобы понять, насколько корректно настроены наши сервисы. Во всех запусках до 8‑кратной проектной нагрузки число занятых ArcSOC‑процессов было значительно ниже максимума (16), что указывает на то, что мы настроили больше экземпляров карт, чем требовалось для этих нагрузок. В рабочей среде с нагрузками ниже 8‑кратной проектной нагрузки возможно уменьшение размеров хост‑серверов и серверов GIS для сокращения затрат. При этом предполагается мониторинг использования ArcSOC‑процессов совместно с загрузкой процессора и памяти серверов для определения момента, когда требуется масштабирование. Важно избегать перегрузки компьютеров, поскольку каждый ArcSOC использует часть памяти, а каждый занятый ArcSOC использует виртуальный процессор.

На диаграмме ниже видно, что на хост‑сервере при 8‑кратной проектной нагрузке все 16 ArcSOC‑процессов бывают заняты в определённые моменты. При полной занятости всех ArcSOC‑процессов ожидается увеличение времени ожидания сервиса, что и наблюдалось. Сервер участков (справа) показывает более низкое использование ArcSOC‑процессов — максимум 9 из 16 настроенных.

Первоначальный всплеск на хост‑сервере (слева) вызван запуском панелей мониторинга в начале тестирования. Темп выполнения рабочих процессов был скорректирован для будущих прогонов: запуск панелей мониторинга распределён на несколько минут для более реалистичного поведения.

• Дополнительные сведения приведены в блоге, посвящённом искусству и науке оптимизации ArcSOC.

Взаимодействие с пользователем — время выполнения рабочих процессов вручную

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

Как видно на диаграмме ниже, время выполнения рабочих процессов остаётся в целом стабильным, с незначительными отклонениями во всех сценариях тестирования. Это указывает на то, что система способна выдерживать повышенную нагрузку без негативного влияния на воспринимаемую отзывчивость для конечных пользователей.

Взаимодействие с пользователем — время выполнения шагов рабочего процесса вручную

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

Выводы и основные заключения

Тестирование проводилось в тестовой среде, а не в рабочей системе. Система в конкретной организации, вероятно, будет отличаться по рабочим процессам, конфигурации или архитектуре. Например, в Azure Web Adaptor обычно не используется (при использовании SAML), а AppGateway распределяет нагрузку напрямую на серверы. Тем не менее данные подходы и результаты тестирования могут быть полезны для применения в собственной среде:

• Проектирование системы с учётом наблюдаемости обеспечивает ценную информацию для корректной настройки производительности относительно затрат на инфраструктуру, а также поддерживает другие критически важные задачи, такие как устранение неполадок.
• Следует отслеживать ресурсы серверов, использование ArcSOC‑процессов и время выполнения рабочих процессов — как в тестовой среде, так и в рабочей.
• Необходимо выявлять несоответствия между выделенными ресурсами и их фактическим использованием. Например:
  • При восьмикратной проектной нагрузке сайт размещения серверов, по‑видимому, имеет подходящий размер для такого объёма запросов. Однако серверы GIS (сервер участков) всё ещё имеют значительный запас неиспользуемых ресурсов.
  • Существует несколько возможностей уменьшить масштаб инфраструктуры, чтобы снизить затраты при сохранении той же производительности и качества взаимодействия с пользователями.
  • Также имеются потенциальные возможности переконфигурировать ArcSOC‑процессы для более оптимального распределения в поддержку наших рабочих процессов.