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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Система выдерживала нагрузку при низком общем потреблении ресурсов

• ArcGIS Data Store (реляционный) не использовался - доступ к базовой карте осуществлялся как сервис векторных листов

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

• Система поддерживала нагрузку
• Загрузка ЦП на хостинговых серверах обычно составляла менее 10%.
• Серверы ГИС обычно работали с загрузкой ЦП менее 20%
• Загрузка процессора PostgreSQL оставалась ниже 20%

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

• Система поддерживала нагрузку
• Загрузка ЦП на хостинговых серверах обычно составляла менее 20%.
• Серверы ГИС обычно работали с загрузкой ЦП ниже 35%
• Загрузка процессора PostgreSQL оставалась ниже 40% с парой скачков около 65%

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

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

Удобство для пользователя - время выполнения этапов рабочего процесса

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