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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Система поддерживала эту нагрузку
• Хост-серверы обычно работали с загрузкой процессора ниже 20%
• ГИС-серверы обычно работали с загрузкой процессора ниже 20%
• SQL Server обычно работал с загрузкой процессора ниже 20%

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

• Система поддерживала эту нагрузку
• Хост-серверы обычно работали с загрузкой процессора ниже 40%
• ГИС-серверы обычно работали с загрузкой процессора ниже 40%, достигая пика при загрузке 50-60%
• SQL Server обычно работал с загрузкой процессора ниже 50%

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

• Система не выдержала нагрузку
• Пик загрузки процессора хост-серверов превысил 80%
• Пик загрузки процессора ГИС-серверов превысил 80%
• Пик загрузки процессора в SQL Server превысил 90%
• Количество успешных одновременных пользователей увеличилось, поскольку запросы не могли быть выполнены из-за перегрузки системы, и система начала возвращать ошибки в журналах и телеметрии

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

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

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

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