Вячеслав Смирнов — Ускорение Apache JMeter
Апач JMeter не требует рекламы, но редко уделяют время скорости загрузки самих скриптов.
Вячеслав рассматривает подходы к оптимальному написанию скриптов, что позволяет сэкономить на загрузке машин и позволяет по-новому взглянуть на JMeter. Apache JMeter — популярный инструмент тестирования производительности со множеством компонентов и возможностей.
Те же операции можно выполнить несколькими способами в Apache JMeter. В проектах, где необходима высокая нагрузка, важным становится вопрос производительности скрипта загрузки.
И было бы неплохо иметь рейтинг производительности компонентов Apache JMeter и подходов к написанию сценариев.
Используя инструменты профилирования Java-приложений, такие как Java Flight Recorder, jVisualVM, SJK, имея доступ к исходным кодам инструмента, написав синтетические тесты и проведя тематические исследования, мы подготовили отчет о тестировании производительности инструмента тестирования производительности.
Доклад будет интересен инженерам по тестированию производительности, использующим Apache JMeter, как начинающим, так и опытным, а также разработчикам, использующим JVM/JDK в своей работе и занимающимся профилированием и оптимизацией кода.
Всем привет! Сегодня я расскажу вам, как ускорить Apache JMeter. 
Немного о себе.
Я посещаю конференции как спикер и как слушатель.
Он был преподавателем в университете, вел курсы по тестированию, писал статьи на Хабре.
Это преимущества.
Но у меня есть и недостатки.
Много их.
Мне говорят, что я довольно неторопливый парень, но некоторые вещи могу делать быстро.
Я ускоряю системы в банках и раньше делал это в других компаниях.
И я часто делал это с помощью Apache JMeter. Сегодня мы попробуем ускорить не просто какие-то системы, а сам Apache JMeter. 
Я думаю, вы знаете, что такое JMeter.
- Это один из самых известных и старых продуктов на рынке.
Он известен с 2003 года.
- Имеет плагины для более чем 50 систем, форматов, методов подготовки и обработки результатов.
- Сохраняет статистику в ClickHouse, InfluxDB, Graphite. Многие системы сбора статистики, которые вы видели, отображают это в Grafana или в виде html-отчета.
- Также удобно интегрироваться в системы CI/CD.
- Имеет хорошую интеграцию с различными инструментами разработки.
- И есть замечательное сообщество.
Сегодня мы рассмотрим 5 основных тем.
Этот:
- HTTP-запросы.
Как отправлять HTTP-запросы с максимальной интенсивностью.
- Как скачивать и отправлять большие файлы.
И в то же время мы столкнемся с некоторыми проблемами.
- Также PostProcessor для HTTP-ответов.
- Препроцессор.
- И я расскажу вам об одном секретном оружии.
Это секретное оружие ускорит все.
Моя цель — развеять миф, возможно известный многим, о том, что JMeter медленный.
И мне бы хотелось, чтобы вы достигли следующих целей:
- Мы укрепили свои знания о том, как спроектировать тест таким образом, чтобы тормозила система, а не тесты.
- Как сделать тестовые прогоны экономичными: вы можете запускать тесты в нескольких экземплярах много раз и встраивать это в конвейер CI/CD, где необходимы практически непрерывные прогоны нагрузки.
- И тесты они разработали быстро и просто.
Начнем с самого первого, с HTTP-запроса — максимальная интенсивность.
Сэмплеры.
HTTP.Request.X. Простой тест. Несколько GET-запросов к локальному серверу.
Для этого теста я написал простой скрипт. Назвал его Samplers.HTTP.Request.X. X означает, что он параметризован.
В нем все параметризовано.
Сам тест довольно простой.
Давайте посмотрим, из чего он состоит. Он отправляет GET-запросы в цикле и все.
Запуск и остановка nginx в тесте с использованием OS Process Sampler В начале теста и в конце теста я запускаю локальный сервер nginx. Для этого я использую setup-reel и TearDown-reel, в которых nginx запускается с помощью OS Process Sampler и в конце останавливается.
Nginx с конфигурацией по умолчанию.
Для скорости — два процесса вместо одного.
Сердцем теста является одна группа потоков и HTTP-запрос внутри нее.
Я в нем все параметризовал: на какой сервер отправить запрос, какую страницу скачать.
По умолчанию используются настройки KeepAlive. Это важно, мы обратим на это внимание позже.
В этом тесте мы будем делать короткие сценарии, например открытие стартовой страницы — это один запрос.
И сделаем скрипты на 10 запросов — открываем стартовую страницу, вводим пароль для входа, или на 100, 1000 запросов, используя Loop Controller здесь.
В нем, передав параметр RequestCount, я могу изменить длину скрипта.
Таким образом мы можем проверить, насколько быстро JMeter будет работать для скриптов разной длины.
А вверху Thread Group есть параметры: сколько потоков — Threads, сколько итераций — LoopCount. 
Таким образом, мы проведем серию экспериментов, в которых будем изменять параметры в трех направлениях:
- Количество нитей: 1, 2, 3.
- Длина сценария.
Короткие скрипты на 1, 10, 50, 100 запросов.
- И мы включим/отключим Keep-Alive.
Изменяя эти параметры, я провел довольно много тестов.
Давайте посмотрим на них.
Если мы запустим тест только на одном потоке, то увидим следующую картину.
На тесте с одним запросом (короткий запрос — просто откройте страницу) мы видим среднюю интенсивность, которой можно достичь.
Это примерно 300-400 запросов в секунду.
Если мы увеличим длину сценария, скажем, до 10, то интенсивность увеличится примерно до 4000 и так далее в порядке возрастания.
Понятно, что при отключенном Keep-Alive такой возможности нет; для него каждое соединение новое.
По мере увеличения количества потоков (два потока, три потока) значения, естественно, увеличиваются.
В моем конкретном тесте разница между двумя и тремя потоками была небольшой.
На что следует обратить внимание? Почему я включил и отключил Keep-Alive? Давайте сравним, какой эффект это дает. 
Что происходит в тестах, состоящих только из одного запроса? Все тесты, которые я видел на JMeter, состояли всего из одного запроса.
Там ребята взяли разные инструменты и добавили в него ровно один запрос и сравнили, как JMeter, выполняющий один запрос в цикле, сравнивается с другими инструментами, которые делают то же самое.
JMeter, который выполняет только один запрос, работает не так быстро.
Даже если вы просто отключите Keep-Alive, это станет быстрее.
Мой тест показывает это.
Если сделать тест более достоверным, то включение или отключение Keep-Alive практически не имеет значения.
Они уже примерно равны по скорости.
А вся мощь Keep-Alive раскрывается, когда тест достаточно велик, т. е.
50-100 запросов.
Полезный вывод для тех, кто работает с нагрузками или пишет бенчмарки: Keep-Alive полезен.
Он включен по умолчанию.
Нет необходимости отключать его.
Но вся его мощь раскрывается, когда скрипт достаточно длинный, хотя бы более 10 запросов.
Давайте помнить об этом.
И вспомним еще один несколько негативный момент. Если вы пишете тесты в JMeter или других инструментах, то не делайте их совсем простыми, т.е.
из одного запроса.
Они оказываются слишком короткими.
И есть избыток соединений, которые в очередной раз не закрываются.
Это снижает для нас максимальную интенсивность.
Наши самые базовые сценарии состоят не из одного запроса или 100, а из чего-то среднего, например, из 10. Это означает зайти, войти в систему, зайти куда-то, выйти из системы.
Это примерно 10 запросов.
Мы видим, что наш сценарий из 10 запросов производит примерно от 4000 до 5000 операций в секунду.
Но мы также видим, что у JMeter довольно большой потенциал.
Попробуем разогнать наш простой скрипт с 4000 до 16000 операций в секунду.
И возможно, мы даже превысим эти значения.
Я думаю, мы сможем это сделать
Для этого нам нужно:
- Инструменты мониторинга.
Я использовал Telegraf, InfluxDB, Grafana.
- Некоторые инструменты, позволяющие контролировать сетевую подсистему.
Для этого в Linux есть отличная утилита — Netstat и другие консольные программы.
- Настройки сетевой подсистемы ядра легко доступны через файловую систему Linux: /proc/sys/net/*.
- Документация.
- Профилировщики: SJK, Java Flight Recorder.
- И настройки самого JMeter.
Сначала давайте запустим наш тест производительности для 10 запросов без каких-либо изменений.
И давайте следить не просто за средним значением интенсивности, а за тем, как оно выглядит на графике.
Я использовал JMeter Backend Listener. А это график из Графаны.
Я ожидал, что интенсивность будет стабильной, т.е.
ровно 4000-5000. Но оно не стабильно, прыгает с нижней полки 500 (по одному запросу) на верхнюю полку 16000 (по 100 запросам).
Мы видим брызги.
Кроме того, есть ошибки.
Например, код ответа, отличный от HTTP. В этом случае в Linux я получаю следующую ошибку: адрес недоступен.
В Windows могут быть и другие ошибки: соединение не может быть установлено.
Но суть у них одна.
В данном случае я поймал 5,24% ошибок.
И испытание уже не совсем удачное.
Если мы профилируем JMeter в этот момент с помощью SJK, то профилирование показывает, что самый длинный метод, т.е.
более 64%, — это socketConnect. То есть JMeter не занимается отправкой запросов и получением ответов, или разбором чего-то, или чего-то медленного внутри него.
Он ждет, чтобы ему предоставили новый сокет для подключения к нашему локальному nginx. И именно здесь проводится большая часть рабочего времени.
Зная все это, попробуем как-нибудь ускорить процесс.
У нас три пути, как у рыцаря на распутье.
Что это за пути? 
- Мы можем изменить сам скрипт, т.е.
что-то изменить в JMeter.
- Мы можем изменить настройки JMeter. Настроек довольно много, есть что менять.
- И мы можем изменить настройки операционной системы, то есть как-то настроить ядро, настроить Linux, чтобы он работал быстрее.
Скрипт JMeter: увеличиваем количество запросов (RequestCount) до 50. Изменяем сам скрипт.
Если помните, я начал с того, что мы запускали тесты с разной длиной скрипта: 1, 10, 50, 100. И было понятно, что когда скрипт был достаточно длинным (50 и 100), нам стабильно давали 16 000 или даже больше запросов в секунду.
Итак, если вы столкнулись с этими проблемами и хотите ускориться, то способ ускорить тесты путем редактирования скрипта — внести в него больше запросов.
В данном случае мы решили ограничить длину 10 запросами и не увеличивать ее, поэтому для нас увеличение не лучший подход. Давайте попробуем что-нибудь еще.
Может быть, HTTP Cache Manager ускорит процесс? Скажу сразу, да, ускоряется, но тут у меня есть небольшая оговорка: я загружаю достаточно простой html-документ. Он мал.
А в небольшом документе, если вы добавите HTTP Cache Manager, эффект будет небольшим.
Это будет почти незаметно.
Интенсивность у меня такая же была на 4800. И процент ошибок примерно такой же, только чуть меньше.
JMeter, по-прежнему использующий HTTP Cache Manager, большую часть времени тратит на метод SocketConnect. То есть ожидаем подключения к нашему локальному nginx. 
Таким образом, в данном конкретном случае разогнать тест путем модификации скрипта не удалось, поскольку мы решили не удлинять скрипт. По нашему определению задачи это 10. Но HTTP Cache Manager по небольшим ответам нам ничего не дал.
Откатим все изменения.
Давайте представим, что мы вернулись в прошлое и никаких изменений не произошло, HTTP Cache Manager не был добавлен.
И давайте попробуем другой вариант. Нажмем на настройки самого JMeter. 
Первая настройка, которую я решил выбрать и которую, наверное, все видели, но никогда не меняли, — это HttpClient4 в Java. По умолчанию — HttpClient4. Если мы изменим реализацию java-клиента (в данном случае я использовал Java 8), мы получим значительное ускорение в 3,3 раза и не получим вообще ни одной ошибки.
То есть это практически установка мечты.
Можно, конечно, использовать его с оговорками, поскольку JavaClient не может делать все, что поддерживается в HttpClient4. Он был разработан специально для JMeter. Но если у вас простой HTTP, то почему бы и нет? 
На данный момент профилирование показывает, что JMeter уже позаботился о бизнесе.
Большую часть времени он читает ответ. Некоторое время он уже отправляет запросы.
То есть мы не зависаем на методе socketConnect. Изменение этого параметра устранило проблему.
Но давайте снова вернемся в прошлое.
Давайте представим, что мы не меняли эту настройку.
Давайте искать другой путь.
Есть еще одна настройка.
Он позволяет отключить сброс состояния между двумя итерациями, т.е.
мы выполнили 10 запросов, и там происходит сброс состояния.
Закрываем все соединения, отправляем TCP — закрываем, SSL — переинициализируемся и начинаем все сначала.
Вы можете сказать «ложь»: не сбрасывайте состояние, установите его и используйте повторно.
Давайте попробуем это изменить.
И, о чудо! Тест ускорился почти в 4 раза.
В некоторые моменты я даже превышал 20 000 в секунду.
И это только при слабеньком ноуте с 4 ядрами и тремя потоками.
Неплохо, но важно понимать, что эта настройка хоть и уменьшила определенное количество подключений, которые мы установили к серверу, но значительно увеличила интенсивность.
Позвольте мне суммировать эти два параметра.
Если заменить реализацию HttpClient4, то мы ускорились в 3,3 раза.
А если сделать так, чтобы использовался дефолтный клиент, но не сбрасывать соединение, то ускорение почти в 4 раза.
Неплохой результат.
Но вернемся еще раз.
Давайте представим, что мы не меняли эти настройки.
И давай попробуем что-нибудь еще.
А еще у нас есть настройки операционной системы.
А в подсистеме сети ядра есть большое количество опций, которые мы сейчас попробуем использовать, чтобы наши соединения быстрее возвращались в JMeter, т. е.
все происходило быстрее.
Для этого запускаем тест заново, но включаем мониторинг всего, что доступно.
Допустим, я мониторил nginx. Мы видим, что подключения к nginx достаточно интенсивные, т.е.
интенсивность подключения скачет от 0 до 1200-1300-1400. А в пике оказывается, что максимальный уровень соединений в секунду примерно в 10 раз меньше интенсивности в тесте.
Это логично.
Делаем 10 запросов - подключение, 10 запросов - подключение.
То есть графики коррелируют. 
График использования ЦП, где красная линия — системное время, а синяя линия — время пользователя.
А все остальные строки — это ожидания и что-то еще.
А на графике видно, что конфигурация по умолчанию тратит большую часть времени на системные вызовы, а пользовательский код теряет в 3,5 раза.
Итак, обратим внимание на различные системные метрики.
Прежде всего в сети.
А мониторинг метрик, который в Графане и Телеграфе называется.
Netstat, в частности метрика tcp_time_wati, показывает, что с момента запуска теста мы быстро доходим до полки, которая явно фигурирует на уровне 28,231. Это магическое число.
И остаёмся на этой полке на протяжении всего теста.
Иногда только наклоняется, но потом возвращается.
То есть нас что-то удерживает, ограничивая значение tcp_time_wait этим числом.
Чтобы отслеживать, кто подключается к нашему локальному nginx (я запускал локальный nginx на локальном порту 5555), мы используем утилиту NetStat. Он показывает, что установлено только одно соединение от JMeter к nginx, а все остальные находятся в состоянии TIME_WAIT. То есть все эти 28 000 — JMeter установил соединение, потом итерация закончилась, и он сказал: «Закройте соединение».
И теперь соединение ждет, пока nginx ему подтвердит: «Да, я согласен, давайте закрывать», т.е.
происходит какое-то согласование.
Это происходит не мгновенно, поэтому соединение некоторое время висит в таком состоянии.
Поиск в документации быстро приводит нас к опции, которая контролирует количество соединений, которые мы можем открыть.
Он называется local_port_range. Его значение по умолчанию в Ubuntu составляет от 32 000 до почти 61 000. А если от 61 000 вычислить 32 000, то получим свои 28 000. Вы можете просмотреть этот параметр с помощью утилиты cat, выполнив команду «cat /metric name», и будет отображено его значение по умолчанию.
А изменить эту метрику можно с помощью команды «echo», вызвав ее с правами администратора.
Допустим, мы сдвинем левую границу 32 000 еще левее и сделаем наш диапазон немного больше, т. е.
в два раза: с 1 025 до 60 999. Полностью в ноль передвигать не стал, так как не знаю, к каким последствиям это приведет. Мне очень помогло @blog.kireev.pro .
Там очень хорошо описано, что такое tcp_time_wait, почему он возникает и что с этим делать.
Мы меняем настройку.
Перезапускаем тест. И имеем ускорение примерно в 1,6 раза.
Теперь интенсивность скачет не с 500 до 16 000, а с 3 500 до 19 000. Это уже хорошо.
Среднее число составило 7700. 
Ошибки исчезли, что очень важно.
Почти победа.
Если вы посмотрите, что JMeter сейчас делает с профилировщиком, он все еще зависает на методе socketConnect. 
Мы ускорили работу и избавились от ошибок «Адрес недоступен», используя опцию ip_local_port_range. 
Но мы только лечили симптомы, проблема осталась, все равно висим на сокетКоннекте.
А если вернуться к метрике Netstat: tcp_time_wait, т.е.
мониторить ее с помощью Telegraf, посмотреть Grafana, то мы увидим, что до 28 000 уже не дотягиваем.
Сейчас их число достигло 32 768. Опять замечательная цифра, думаю, знакомая айтишникам.
И что-то нам подсказывает, что это еще один предел.
И, возможно, мы сможем его найти.
Есть такой лимит. И есть такая опция: максимальное значение tw_buckets, максимальная длина очереди TIME_WAIT. Если вы снова запустите команду «cat», она сообщит вам, что значение по умолчанию в Ubuntu равно 32 768. 
И мы можем изменить его, скажем, дважды, написав туда значение 65 000. Давай сделаем это.
Перезапустим тест, но увы, нагрузка осталась прежней.
В среднем примерно то же самое.
Оно по-прежнему подскакивает с 3500 до 19 000. 
Каковы преимущества? Tcp_time_wait был на полке с номером 32 768, но сейчас его нет. Сначала она подскакивает до 46 000. А во время теста плавает в более рыхлом интервале, то есть полки нет, но разгоняться нам это не помогло.
Давайте запомним этот момент. Это опыт. Если мы увеличим local_port_range, а потом увеличим tw_buckets сверху, не откатываясь в машине времени, то tw_buckets как-то ничего хорошего нам не добавляет, но мы отходим от полки.
И это плюс.
Профилирование показывает, что при двух настройках JMeter всё равно зависает на методе socketConnect, но в меньшей степени — примерно на 50%.
Будем искать настройки дальше.
И поиск по настройкам приводит нас к тому, что можно повторно использовать соединение TIME_WAIT. Для этого в настройку tcp_tw_reuse нужно прописать «1».
По умолчанию установлено «0».
Теги: #Тестирование веб-сервисов #Тестирование ИТ-систем #нагрузочное тестирование
-
Выбор Фирмы Цифрового Маркетинга
19 Oct, 24 -
Екатеринбург, Четверг, 13 Декабря!
19 Oct, 24
