1. Обзор
В предыдущем уроке мы увидели, как использовать Gatling для нагрузочного тестирования пользовательского веб-приложения.
В этой статье мы будем использовать инструмент стресса Gatling для измерения производительности промежуточной среды этого веб-сайта.
2. Тестовый сценарий
Давайте сначала настроим наш основной сценарий использования — тот, который близок к типичному пользователю, который может просматривать сайт:
- Перейти на главную страницу
- Открытие статьи с домашней страницы
- Перейти к Руководствам/ОТДЫХУ
- Перейти в категорию ОТДЫХ
- Перейти к полному архиву
- Открыть статью из архива
3. Запишите сценарий
Теперь мы запишем наш сценарий с помощью регистратора Гатлинга следующим образом:
$GATLING_HOME/bin/recorder.sh
И для пользователей Windows:
%GATLING_HOME%\bin\recorder.bat
Примечание: GATLING_HOME — это ваш каталог установки Gatling.
Существует два режима Gatling Recorder : HTTP Proxy и HAR Converter.
Мы подробно обсуждали режим прокси-сервера HTTP в предыдущем руководстве , поэтому давайте теперь рассмотрим параметр HAR Converter.
3.1. HAR-конвертер
HAR — это сокращение от HTTP Archive — это формат, который в основном записывает полную информацию о сеансе просмотра .
Мы можем получить файлы HAR из браузера, а затем использовать Gatling Recorder, чтобы преобразовать их в симуляцию.
Мы создадим наш файл HAR с помощью инструментов разработчика Chrome:
- Меню -> Дополнительные инструменты -> Инструменты разработчика
- Перейти на вкладку «
Сеть » - Убедитесь, что установлен флажок «
Сохранить журнал» . - После того, как вы закончите навигацию по веб-сайту, щелкните правой кнопкой мыши запросы, которые вы хотите экспортировать.
- Затем выберите «Копировать все как HAR».
- Вставьте их в файл, а затем импортируйте из регистратора Gatling.
После того, как вы закончите настройку регистратора Гатлинга в соответствии со своими предпочтениями, нажмите «Пуск».
Обратите внимание, что выходная папка по умолчанию — GATLING_HOME/user-files-simulations .
4. Моделирование
Сгенерированный файл моделирования аналогичным образом написан на Scala. В целом все в порядке, но не очень читабельно, поэтому мы внесем некоторые коррективы, чтобы очистить его. Вот наше окончательное моделирование:
class RestSimulation extends Simulation {
val httpProtocol = http.baseURL("http://staging.foreach.com")
val scn = scenario("RestSimulation")
.exec(http("home").get("/"))
.pause(23)
.exec(http("article_1").get("/spring-rest-api-metrics"))
.pause(39)
.exec(http("rest_series").get("/rest-with-spring-series"))
.pause(60)
.exec(http("rest_category").get("/category/rest/"))
.pause(26)
.exec(http("archive").get("/full_archive"))
.pause(70)
.exec(http("article_2").get("/spring-data-rest-intro"))
setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)
}
Важным примечанием здесь является то, что полный файл моделирования намного больше; здесь мы не включили статические ресурсы для простоты.
5. Запустите нагрузочный тест
Теперь мы можем запустить нашу симуляцию следующим образом:
$GATLING_HOME/bin/gatling.sh
И для пользователей Windows:
%GATLING_HOME%\bin\gatling.bat
Инструмент Gatling просканирует GATLING_HOME/user-files-simulations и выведет список всех найденных симуляций, чтобы мы могли их выбрать.
После запуска симуляции вот как выглядят результаты:
Для одного пользователя:
> request count 304 (OK=304 KO=0)
> min response time 75 (OK=75 KO=-)
> max response time 13745 (OK=13745 KO=-)
> mean response time 1102 (OK=1102 KO=-)
> std deviation 1728 (OK=1728 KO=-)
> response time 50th percentile 660 (OK=660 KO=-)
> response time 75th percentile 1006 (OK=1006 KO=-)
> mean requests/sec 0.53 (OK=0.53 KO=-)
---- Response Time Distribution ------------------------------------
> t < 800 ms 183 ( 60%)
> 800 ms < t < 1200 ms 54 ( 18%)
> t > 1200 ms 67 ( 22%)
> failed 0 ( 0%)
Для 5 одновременных пользователей:
> request count 1520 (OK=1520 KO=0)
> min response time 70 (OK=70 KO=-)
> max response time 30289 (OK=30289 KO=-)
> mean response time 1248 (OK=1248 KO=-)
> std deviation 2079 (OK=2079 KO=-)
> response time 50th percentile 504 (OK=504 KO=-)
> response time 75th percentile 1440 (OK=1440 KO=-)
> mean requests/sec 2.411 (OK=2.411 KO=-)
---- Response Time Distribution ------------------------------------
> t < 800 ms 943 ( 62%)
> 800 ms < t < 1200 ms 138 ( 9%)
> t > 1200 ms 439 ( 29%)
> failed 0 ( 0%)
Для 10 одновременных пользователей:
> request count 3058 (OK=3018 KO=40)
> min response time 0 (OK=69 KO=0)
> max response time 44916 (OK=44916 KO=30094)
> mean response time 2193 (OK=2063 KO=11996)
> std deviation 4185 (OK=3953 KO=7888)
> response time 50th percentile 506 (OK=494 KO=13670)
> response time 75th percentile 2035 (OK=1976 KO=15835)
> mean requests/sec 3.208 (OK=3.166 KO=0.042)
---- Response Time Distribution ----------------------------------------
> t < 800 ms 1752 ( 57%)
> 800 ms < t < 1200 ms 220 ( 7%)
> t > 1200 ms 1046 ( 34%)
> failed 40 ( 1%)
Обратите внимание, что некоторые запросы не удалось выполнить при тестировании 10 одновременных пользователей — просто потому, что промежуточная среда не способна справиться с такой нагрузкой.
6. Заключение
В этой быстрой статье мы изучили вариант HAR для записи тестовых сценариев в Gatling, а также провели простой начальный тест foreach.com.