Offtop.
Есть наблюдение, что при срабатывании полной сборки мусора может срабатывать и очистка Metaspace. Но это зависит от JVM. Поэтому, теоретически, при меньшем размере Xmx мы имеем более регулярные сборки мусора в Metaspace, и меньшую вероятность переполнения области памяти даже при лимите 256МБайт.

А по документации, область Metaspase не чистится, чистится по неизученным правилам.

И по умолчанию размер области памяти не ограничен. И такие ошибки не приводят к проблемам. Знаю одну систему, где такие ошибки есть, а система работает 24х7 и ничего

Подскажите, плиз, я правильно понимаю что нагрузка заданная в тесте умножается на количество серверов? или она распределяется? То есть если я хочу получить 100 RPS то в тесте нужно сделать 100/2, где 2 кол-во серверов  нагрузки? и также с потоками

Корневую транзакцию вы не добавили. Стоит добавить, чтобы оценить длительность одного прохода.
Обратите внимание, что длительность сценария в данном случае переменная. И потенциально бесконечная за счет while.

Есть ли у While предельное количество итераций или предельное время ожидания ответа? Возможно, я и помогал с написанием цикла, помню такое. Хорошо, если будет предельное количество итераций.

Повторение Header Manager - утяжеляет сценарий. Достаточно добавить Header Manager в Thread Group или вообще в Test Plan (корень)

View Result Three в сценарии - лишний элемент. Он может замедлить тест и точно замедлит его при запуске в GUI-режиме.

Вы же запускаете тест в консольном режиме?

Да, верно

в while есть ограничение

да, запускаю в консольном. Для распеределенного запуска использую такую команду jmeter -n -t "скрипт.jmx" -r -l "путь к отчету\log.jtl"

View Result - не всегда отключаю, буду стараться скрывать перед запуском

В While по факту может крутиться по 600 итераций, предел задан большой - 50000

Не проверял, что будет если его оставить в консольном режиме. Поэтому утверждать не буду. Но и исключать, что он копит ответы тоже не буду

Можно выделить процесс ожидания в отдельную катушку. Так как потенциальное время ожидания высокое.

Summary тоже не нужно оставлять ? его можно будет получить из файла лога

Из файла лога можно будет получить. Да. А оставлять или нет - не изучал.

Тут невысокие интенсивности ведь. Если верно понял. Summary не замедлит такой сценарий так, чтобы это стало явным узким местом.
В более интенсивном сценарии точно стоит отключать все, что можно.

да не интенсивно. спасибо!

Я вот, к примеру, вычищаю все все что можно убрать (все листенеры, все дебаг штуки) и потом не приходится думать а что же могло подкушать память да ресурсы.

А почему бы и gc руками не форсануть? Мне в некоторых случая помогало

Его не нужно форсить потому что) Это очень плохая практика

gc гораздо лучше вас знает, когда ему следует работать