Современные корпоративные системы, используемые в крупных компаниях, должны обеспечивать возможность одновременной работы большого числа пользователей. Малейший сбой вызывает простои в работе и снижение эффективности сотен и даже тысяч сотрудников, приводя к значительным убыткам. Стабильность работы таких систем, их способность выдерживать пиковые нагрузки являются ключевыми задачами для бизнеса. Решение этих задач заключается в ответах на наиболее важные вопросы:

Как изменится производительность Системы, после установки обновлений?
Если производительность снизится, то что будет причиной этого?
Как можно оптимизировать производительность Системы?
Выдержит ли Система планируемое увеличение числа пользователей?
Устойчива ли Система к возникновению пиковых нагрузок?

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

О ПРОЕКТЕ

Число пользователей Системы:………………	25 000 — 50 000
Пиковые нагрузки:…………………………………….	1000 — 3 000
Инструмент тестирования:………………………	Meter
Цель нагрузочного тестирования:…………..	регулярная проверка производительности системы до и после установки плановых релизов

01 Как подготовиться к проведению тестирования производительности?

Вопрос бизнеса:
Как минимизировать стоимость тестирования производительности?

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

Вопрос бизнеса:
Что покажет нам тестирование производительности?

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

Кроме того, чтобы понять есть ли запас производительности и как быстро Система будет восстанавливаться после предельных нагрузок, мы проводили стресс-тесты.

Вопрос бизнеса:
Можем ли мы быть уверенными, что условия нагрузочного тестирования максимально приближены к условиям реальной эксплуатации?

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

Мы изучили как реальные пользователи работают в Системе. Разработали и параметризировали тестовые сценарии и скрипты нагрузочного тестирования с учетом бизнес-логики процессов заказчика. С каждым новым релизом в функционал Системы вносились различные изменения. Мы учли это и регулярно проводили актуализацию скриптов и тестовых данных.

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

Само тестирование проводилось на тестовом стенде. На нем мы развернули тестовую среду, полностью повторяющую промышленную. Благодаря этому тестирование получилось максимально приближенно к реальным условиям, минимизировав, таким образом, количество упущенных из-за разницы сред дефектов.

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

Вопрос бизнеса:
Насколько результаты нагрузочного тестирования релевантные?

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

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

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

Вопрос бизнеса:
Какие параметры можно будет контролировать при проведении тестирования?

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

 

02 На что обращать внимание при проведении нагрузочного тестирования?

Вопрос бизнеса:
Тестирование началось и что? Все в порядке? Какие оперативные выводы о работе Системы можно получить сразу?

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

Для того, чтобы контролировать ситуацию, необходимо оперативно отслеживать ключевые метрики производительности:

• Число виртуальных пользователей
• Время отклика на запрос
• Производительность (число запросов в секунду)
• Число и тип ошибок
• Производительность серверов приложений
• Производительность базы данных

В JMeter для отслеживания этих показателей достаточно добавить соответствующие «Листенеры» Add > Listener >.

Чтобы видеть число виртуальных пользователей добавляем график jp@gc — Active Threads Over Time. Время отклика на запрос покажет jp@gc — Response Times Over Time. Там же можно увидеть и число ошибок, отметив соответствующий чекбокс. Увидеть детали ошибок можно, открыв View Results Tree. Производительность, среднее время отклика на запрос и скорость передачи данных можно отслеживать в Summary Report. Статистические параметры тестов выводятся в Aggregate report, подробнее о них будет рассказано в части, описывающей итоговый анализ результатов. Посмотреть динамику производительности серверов приложений и БД можно в «Листенере» jp@gc — PerfMon Metrics Collector. Подробнее можно посмотреть на сайте jmeter-plugins.org.

 

03 Как проводить анализ результатов нагрузочного тестирования?

Вопрос бизнеса:
Ок, графики, таблички, а что в сухом остатке, из-за чего возникла деградация производительности?

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

При анализе результатов нагрузочного тестирования, необходимо иметь представление об основах статистики. Подробнее об этом можно почитать в статье Key Mathematic Principles for Performance Testers.
Важно учитывать, что среднее значение времени отклика на запрос не является наиболее показательной метрикой. Ведь несколько запросов, выполняющихся существенно (в десятки и сотни раз) дольше остальных, дадут очень большой вклад при расчете среднего значения. Гораздо важнее анализировать перцентиль (Line) 90% или 95% — время за которое отклик получает соответствующая доля запросов.  То есть, если рассматривать упорядоченное по возрастанию распределение времени отклика для всех запросов, то перцентиль 90%  — это значение, для которого 90% выборки имеет меньшее время отклика. В JMeter этот параметр можно найти в Aggregate report.

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

Для расчета времени выполнения сценариев в общем тесте потребовалось анализировать базовые данные теста. Их можно увидеть, использовав «Листенер» View results in table. Зная первый и последний шаг (запрос) для каждого из выполняемых сценариев, можно отфильтровать всю выборку и рассчитать время выполнения сценария для каждого пользователя. На основе этих данных можно рассчитать статистические показатели: среднее время выполнения сценария или время, за которое сценарий выполняется 90% (95%) пользователей. Какой из этих показателей брать зависит от числа пользователей и разброса в выборке.

Анализ позволил определить какие из бизнес-процессов будут выполняться медленнее. Для них мы детально проанализировали увеличение времени отклика на каждый из запросов.

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