Нагрузочные тесты

1. План испытаний
2. Подготовка к тесту с использованием приложения JMeter
3. Шаг 1 - Создайте план тестирования
4. Шаг 2 - Определение пула пользователей, выполняющих тест
5. Шаг 3 - Добавление элементов конфигурации
6. Шаг 4 - Обработка целевых запросов
7. Шаг 5 - Наблюдение за результатами - сбор данных
8. Шаг 6 - Запуск теста и результатов
9. суммирование

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

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

План испытаний

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

1. Сценарий использования (путь для навигации по сайту, порядок выполнения конкретных действий).
2. Количество пользователей, следующих за сценарий планируемого использования.
3. Время, в которое указанное число пользователей выполняет сценарий.

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

В нашем случае мы имеем дело с веб-приложением, работающим в веб-браузере. Данные передаются и передаются по протоколу HTTP, а сервером приложений является NGINX.

Один из сценариев - войти в систему пользователей, которые имеют свои учетные записи на сайте, и перейти в свой профиль, чтобы прочитать сообщение. Мы знаем, что около 3000 пользователей заходят на сайт в течение дня. Предполагая, что значительное количество пользователей выполняет эти действия в течение 9-17 часов, у нас есть интервал 8 часов для получения такого трафика. Зная приложение, мы знаем, что самый большой трафик между 9 a 11 - тогда около 50% всех пользователей входят в систему. Таким образом, существует около 12 уникальных пользователей в минуту. Для тестирования мы берем число 24 пользователей, чтобы быть уверенными в том, как приложение будет вести себя, когда трафик увеличивается на 100%.

Подготовка к тесту с использованием приложения JMeter

Мы проводим стресс-тесты, используя бесплатное приложение JMeter ( http://jmeter.apache.org/ ). Это приложение, написанное на языке Java, поэтому оно работает в любой операционной системе, поддерживающей эту технологию. JMeter связывается с протестированным сервисом, взимая плату аналогично тому, как это делают интернет-браузеры. Однако он не работает как браузер - он не поддерживает все действия, поддерживаемые браузером, например, Java Script. Работает по принципу отправленных запросов и проверки ответов, возвращаемых сервером.

Зная реальный план приложения, нам нужно отобразить тот же план в JMeter. Подготовка всего плана сводится к нескольким этапам:

Шаг 1 - Создайте план тестирования

В простейшей форме узел плана тестирования состоит из его имени ( Name ) и, необязательно, переменных ( User Defined Variables ), которые мы будем использовать позже. Мы объявляем две переменные (их имена зависят только от нас):

• site - URL / IP-адрес, под которым будет доступна протестированная система
• port - номер порта, под которым будет доступна тестируемая система

Шаг 2 - Определение пула пользователей, выполняющих тест

Группа пользователей / потоков (Thread Group) позволяет объявить количество пользователей (Number of Threads) за заданный период времени (Ramp-Up Period), которое будет создавать запросы к тестируемой системе. Желательно установить оба значения на «1» на начальном этапе разработки теста. Только когда мы уверены, что весь тест пройден без ошибок, мы изменим эти значения на целевые.

Шаг 3 - Добавление элементов конфигурации

Для указанной группы пользователей мы добавляем элементы конфигурации, общие для целевых http-запросов. Это:

HTTP Request Defaults - конфигурация по умолчанию для отправленных запросов. Мы используем переменные сайта и порта, определенные в плане тестирования сайта, для настройки хоста ( имя сервера или IP ) и порта ( номер порта ).

Диспетчер заголовков HTTP - позволяет добавлять или перезаписывать отправленные заголовки HTTP. Благодаря этому JMeter может выступать в качестве конкретного браузера и операционной системы. Мы можем объявить, например:

• User-Agent (пример для моделирования браузера Windows 10 и Microsoft Edge Desktop): Mozilla / 5.0 (Windows NT 10.0; WOW64) AppleWebKit / 537.36 (KHTML, как Gecko) Chrome / 39.0.2171.71 Safari / 537.36 Edge / 12.0
• Accept-Encoding: gzip, выкачать
• Accept-Language: en-GB, pl; q = 0,8, en-US; q = 0,6, en; q = 0,4

HTTP Cache Manager - позволяет имитировать кеш браузера (если разработанное приложение устанавливает заголовки Last-Modified и Etag . Если вы хотите создать новый кеш для каждого виртуального пользователя, выберите Очистить кеш на каждой итерации .

HTTP Cookie Manager - позволяет сохранять и отправлять куки, как это делает веб-браузер. Каждый поток сохраняет свой собственный файл cookie, значение которого можно увидеть позже в дереве результатов представления списка .

Шаг 4 - Обработка целевых запросов

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

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

Для этого мы добавляем экстрактор регулярных выражений , в котором мы определяем переменную- значение, в которую JMeter будет сохранять значение токена CSFR. Мы собираем значение токена с помощью регулярного выражения, которое в нашем случае из тега HTML Input скрытый тип получает то, что находится в значении этого поля.

Вход на сайт, то есть заполнение полей формы и отправка его в действие входа в систему, также реализовано как HTTP-запрос. На этот раз отправка данных является методом POST, и в качестве параметров отправляются те же параметры, что и при реальном входе в систему.

Чтобы выяснить, какие параметры / переменные должны быть отправлены, чтобы войти в систему, проще всего использовать инструмент разработчика браузера, где вы можете прослушать набор переменных, которые также отправляются POST. Мы передаем ранее загруженный токен CSRF как уже объявленную переменную значения .

Посещение страницы с сообщениями для пользователя и выход из системы - это следующие два HTTP-запроса, которые, используя метод GET, отправляют запросы на URL-адреса, указанные в пути .

Шаг 5 - Наблюдение за результатами - сбор данных

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

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

Шаг 6 - Запуск теста и результатов

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

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

Помимо просмотра результатов в JMeter, вы должны наблюдать за параметрами самого сервера: нагрузка, процессор, RAP и Swap, а также процессы, которые потребляют эти ресурсы.

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

Несколько элементов могут влиять на сам результат - качество / способ написания приложения, конфигурация сервера, но и оптимизация самого уровня представления часто влияет на скорость действия.

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

Результат для целевого числа пользователей:

Результат для 24 пользователей в секунду:

суммирование

Описанный случай теста показывает начальное состояние нагрузочного теста. В конечном итоге тест должен включать вход пользователя в систему, например, с разными логинами и их паролями, время «паузы», в течение которого пользователь, например, читает то, что у него есть на сайте. Поэтому этот сценарий намного ближе к реальному использованию приложения. Также стоит учесть для ваших шагов так называемые Утверждения, которые позволяют вам проверить, есть ли после загрузки страницы обязательные элементы - например, текст приветствия пользователя, его логин и т. Д.

Автор:
Радослав Кухта,

руководитель отдела поддержки и обеспечения качества, Kaliop Poland