Ну от Славы уже есть доклад про это
Разве не так?

Недавно обсуждали инструменты. Там есть интересная статья. В которой одни инструменты побеждают другие по RPS. И ключ победы, как раз, в управлении соединениями (IMHO). Чем менее реальное управление соединениями, тем выше скорость. Тема известная. Ее надо знать, применять. Может удобная кнопка в JMeter нужна для этого. И пару статей с докладом

Вот, товарища Вячеслава не проведёшь!
У меня, да, мысль в контексте этой же статьи. Ну и вообще в разрезе постоянных тут обсуждений «сколько потоков ставить».

Ещё бы понять как эта настройка должна удобно регулироваться

Можно просто галочку добавить, для опции

httpclient.reset_state_on_thread_group_iteration

Со значением по умолчанию false. Куда-нибудь в
https://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request_Defaults

httpclient.reset_state_on_thread_group_iteration

+1

так есть же галочка в thread group’е

«same user on each iteration»

Это она и есть? Ничего себе. В описании от Филиппа было про кеш что-то.

А вот откуда это, не от Филиппа, от тебя, Володя

Точно, это она и есть:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62861

И её значение сейчас по умолчанию True. То есть JMeter по умолчанию ведёт себя, как ускоренный. Чего раньше не было.

Значит нужна будет статья, почему иногда надо нужно замедлить JMeter. С рассказом об отключении «same user on each iteration»

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

Например, есть проблема на продуктиве - зависает веб-сервер (nginx, apache, haproxy), клиенты получают ошибку "503 Сервер не доступен" при высоком количестве запросов (RPS). Мониторинг настроен плохо, поэтому деталей нет. Получаем задачу:

1. Воспроизвести проблему
2. Разобраться в причинах
3. Исправить, предложить рекомендации по устранению

Так как на руках есть профиль нагрузки (запросы и их интенсивность). И ожидаемый результат: 503 в ответ. То пишется тест, пусть в JMeter (новом), wrk, k6, ...

Причина проблемы может быть в следующем.
На продуктиве вот такая конфигурация:
[Клиенты] -> [Балансировщик] -> [nginx/haproxy] -> [app] -> [DB]

Причины по которым некоторые клиенты получают ошибку 503:
1. Зависла [DB], из-за индексов, настроек DB, ... кончились подключения к DB, ошибка по цепочке [DB]->[app]->[nginx/haproxy]... ушла клиенту
2. Завис [app], из-за памяти, логирования, блокировок, ... кончились свободные worker-ы в app, ошибка по цепочке [app]->[nginx/haproxy]... ушла клиенту
3. Завис [nginx/haproxy], из-за лимита соединений (TCP Time Wait), лимита потоков, просто много памяти было выделено так как каждая сессия это память, ошибка по цепочке [nginx/haproxy]->... ушла клиенту

В тесте делается такая конфигурация:
[JMeter] -> [nginx/haproxy] -> [app] -> [DB]

Система тестируется. Скорее всего причина ошибок была (1) или (2). Причина находится, индексы добавляются, утечка памяти чинится, все счастливы.
И такие причины будут выявлены все зависимости от того, сколько соедиенний будет установлено между
[JMeter] -> [nginx/haproxy]
Тут чем меньше соедиенний, тем меньше расходов на их установку и тем выше будет интенсивность отправки запросов. Тем проще будет найти проблемы в [app] и [DB].

Но, если всегда тестировать на малом количестве соединений, то будет сложно найти проблемы в [nginx/haproxy].
Ошибка 503 может быть и не им сформирована. Она может быть из-за того, что проявилась причина (3), завис [nginx/haproxy]. И ошибку отдал [Балансировщик], который не получил ответа от [nginx/haproxy], она есть в логах [Балансировщик], но её нет в логах [nginx/haproxy].

Причина (3) проявится при большом количестве подключений. Чтобы такое большое количество создать, надо будет, чтобы инструмент нагрузки их создавал, чтобы нагрузочных агентов было несколько.

Особенно важно это становится, если проект контентный:
[Клиенты] -> [Балансировщик] -> [nginx/haproxy]
или
[Клиенты] -> [nginx/haproxy]

Благодарен вам, за развернутый ответ)

А чтобы обходиться без тестирования можно вести статистику ошибок на [Балансировщик] и [nginx/haproxy], в ELK или кто-то ещё.
Или мониторить соединения, дескрипторы, сокеты, ... на станциях и настраивать систему.

Другая причина для использования большого количества подключений. Чтобы проверить, что в цепочке
[JMeter] -> [nginx/haproxy] -> [app] -> [DB]
прокси в виде [nginx/haproxy] защищает [app] от большого количества подключений.

Подключение к [app] дорогое - много памяти.
Подключение к [nginx/haproxy] дешевле.

Поэтому и используют [nginx/haproxy], они держат соединения с клиентами, и через пул подключений, ограниченный сверху (пусть в 200), работают с [app]. Так стабильнее.
Для этого надо будет из [JMeter] создать много сессий. Много потоков.

Необходимо такое тестирование вот из-за чего. Бывает в [app] не ограничен пул, или ограничен в 2000 воркеров (много очень). И всё это работает только потому, что перед ним есть [nginx/haproxy], который допускает до [app] только 200 одновременных клиентов, и поэтому в [app] работает только 200 воркеров. И мы не получаем "Out of memory" в [app].

Но если ни [nginx/haproxy] ни [app] не настроены или в них "Для хорошей производительности" все настройки были выставлены в максимум.
А мы в инструменте [JMeter] создаём 10 подключений, вместо 1000, то мы никогда и не нагрузим систему.

Но это уже не очень связано с темой

«same user on each iteration»

Тут даже на сопоставлении 1 поток - 1 соединение можно сделать тысячи соединений, просто выставив в JMeter 1000 потоков.
Это написал для полноты.

Всем привет, есть вопрос. Попытался найти в интернете но без результатов, может кто знает как сделать:
Вывод в результаты Jenkins job, где проходит сборка jmeter скрипта нагрузки, ссылки на график из grafana по timestamp?
Ещё круче, если кто-то знает, как можно показать сами графики с помощью какого-нибудь плагина Jenkins или хотя-бы скриншоты графиков из grafana

«same user on each iteration»

Ещё раз, благодарю.

Если я правильно понял вопрос, то в дженкинсе можно после окончания нагрузочного теста опубликовать автосгенереный отчёт jmeter