Падение Jmeter-хитов в секунду через 2 часа - PullRequest
0 голосов
/ 04 октября 2019

В наших нагрузочных тестах с jmeter наблюдается падение числа обращений в секунду примерно через 2 часа. Jmeter работает без графического интерфейса в распределенном режиме. Мой счетчик потоков в минуту составляет 25 КБ, и мы работаем с 6 серверами.

Чтобы исключить jmeter в качестве узкого места, я проверил, есть ли у Jmeter пул соединений с ограничением размера.

НоJmeter, кажется, поддерживает пулы http-соединений на поток. Согласно Поддерживает ли JMeter пул HTTP-соединений? .

Понятно, что значение по умолчанию составляет 2000 миллисекунд согласно свойству httpclient4.time_to_live в jmeter.properties

# TTL (in Milliseconds) represents an absolute value.
# No matter what, the connection will not be re-used beyond its TTL.
#httpclient4.time_to_live=2000

Версияjmeter: 4.0.0, который использует реализацию клиента Http4

Это означает, что Jmeter создает соединения для каждого потока, время ожидания которых составляет 2 секунды.

Принимающий веб-сервер Jetty имеет следующие значения пула соединений:

maxThreads = 3200
minthread = 656
idleTimeout = 60000

Возможно ли, что падение числа попаданий в секунду из-за jmeter вызвано из-за медленного / отсутствия ответа от сервера Jetty.? Существуют ли правила сопоставления числа потоков Jmeter с пулом соединений целевого веб-сервера. ?

Примечание. Я понимаю, что пропускная способность обычно зависит от ответа тестируемого приложения. Но будет ли тестируемое приложение каким-либо образом влиять на число попаданий Jmeter в секунду на целевой сервер .?

Обновление: с https://stackoverflow.com/a/40689714/1165859, ясно, что существует корреляция между попаданиями в секунду иТестируемое приложение. Но моя проблема в том, что все хорошо в течение первых 2 часов. После чего количество ударов в секунду падает.

1 Ответ

0 голосов
/ 08 октября 2019

То, что вы делаете, больше похоже на Soak Testing , основной целью которого является проверка на утечки памяти и с учетом снижения пропускной способности с течением времени он выглядит как "классический"" утечка памяти.

Итак, мои рекомендации:

  1. Использовать JVisualVM или эквивалентный для мониторинга использования кучи, GC активность, поведение потоков и т. Д. на стороне Jetty
  2. Используйте JMeter PerfMon Plugin для мониторинга использования процессора, памяти, подкачки, сети, использования диска и т. д.
  3. Используйте инструмент профилирования, например JProfiler или YourKit для поиска самых больших объектов, "самых тяжелых" методов и т. д.
  4. Вы также можете применить вышеупомянутые 3 пункта к JMeter
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...