Поведение JMeter во время отклика при сборке мусора

Question

В настоящее время я пытаюсь понять, как сборка мусора JMeter влияет на сообщаемое время ответа.

Я могу представить свою мысль на графике ниже

HTTP-запрос от JMeter к примеру .org -> JMeter выполняет G C перед ответом -> Конец G C -> Получение ответа от example.org

Как JMeter обрабатывает это ? Добавляется ли время G C ко времени отклика? G C время вычитается из времени ответа после получения ответа?

Если добавлено время G C, это означает, что G1G C Алгоритм, который встречается часто, но с короткими паузы повлияют на время отклика 90 процентилей. Но ConcurrentMarkSweep будет делать меньше, но более длительных пауз, не влияя на 90 процентиль (что для меня более приемлемо).

Большое спасибо Береги себя

Romain

Answer 1

Согласно Глоссарий JMeter

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

Таким образом, если крупный G C произойдет, пока JVM зависнет, JMeter не получит ответа, поэтому время, потраченное на G C, будет добавлено к общему истекшему времени.

Вы можете посмотреть Одновременное тестирование производительности с высокой пропускной способностью с помощью JMeter , где у этого парня наблюдались скачки пропускной способности, например:

и после перехода на CMS G C получил следующее:

Итак убедитесь, что:

1. Следуйте рекомендациям из 9 Простые решения для отказа JMeter Load Test «Недостаточно памяти» article
2. Мониторинг использования кучи с помощью ie JVisualVM , JMeter должен потреблять от 30% до 80% доступного размера кучи, таким образом, количество сборок мусора должно быть меньше
3. Если вы не сможете создать стабильную схему загрузки, это означает, что генератора с одной нагрузкой недостаточно, и вам потребуется go для распределенного тестирования