Это извечный вопрос. Одним словом не ответить. В целом - есть ограничение.

На станции с 4 Гбайт ОЗУ делали раньше всегда 1000 потоков. Было у нас такое правило. Сильно не думали.

Потом подумав стал мониторить, сколько потоков создано и сколько памяти выделено.
И поделив одно на другое можно определить стоимость одного вашего потока. Она зависит от вашего сценария, постпроцессов. Примерно 10 КБайт и больше (с постпроцесорами, скачиванием больших ответов, ...). 8 000 000 / 10 = 800 000. Но зная точный размер памяти под поток можно определить сколько потоков можно уместить в 8 Гбайт для вашего скрипта.

Сделайте так. Запустите тест. Откройте jvisualvm. Откройте там jmeter. Сделайте полную сборку мусора, и сразу heap dump. Грубо поделив размер кучи на потоки получим средний размер. А если точно, то... Откройте heapdump в Memory Analyser (mat). Вверху в панели будет кнопка статистики потокам. Посмотрите сколько памяти в чистую заняли потоки. И точно поделите этот размер на их количество.

Много подключений создать тоже непросто. Надо станцию настраивать. Увеличить лимиты на диапазон исходящих соединений (диапазон портов), включить переиспользование сокетов, увеличить количество дескрипторов на процесс (по умолчанию 4096), ...

Тут необходимость большого количества пользователей приводит к вопросу ускорения работы сценария. Нужен же TPS, а не пользователи. Чем меньше тормозит сценарий, тем эффективнее используются потоки. Тем меньше их нужно.

И начать стоит с подбора таймера. Чем меньше поток спит в таймере, тем лучше он работает. Throughput Shaping Timer хорош. Другие таймеры тоже хороши. Их под задачу подбираете.

Ещё некоторые советы собрал в докладе Ускоряем Apache JMeter.

Вот тут еще можно почитать про закрытую/открытую модели.
http://users.cms.caltech.edu/~adamw/papers/openvsclosed.pdf

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

За секунуду целый сценарий...хм интересно.
А каким образом это делаемся, что бы выйти на данную цифрую. Если я правильно понимаю, может быть рассинхрон в ответах от сервера и мы просто не сможем попасть в данную цифру?

У каждого разные сценарии. И, да, сценарий «подключить услугу в личном кабинете» может состоять из нескольких шагов (залогиниться, нажать пару кнопок, перейти по нескольким страницам) и таких сценариев запросто может быть несколько в секунду.

>Если я правильно понимаю, может быть рассинхрон в ответах от сервера и мы просто не сможем попасть в данную цифру?

Это смотря как нагрузочные скрипты писать.
Если взять Precise Throughput Timer, то он будет точно попадать в целевой показатель «количества сценариев в секунду/часть/или что там у вас»

Подробнее я рассказывал в этом докладе (тогда timer ещё не входил в состав JMeter, а в 5.0+ он уже есть): https://www.youtube.com/watch?v=3PWBBc7rZxw

Искал информацию по мониторингу, нашел репозиторий отличный

https://github.com/DataDog

Конкретно вот этот, со статьями, изучаю:
https://github.com/DataDog/the-monitor

А я его добавил, спасибо

сложная интеграция с метром как по мне, точнее не самая обычная....

У меня пока получилось только через агент настроить лиснер лога (метра) и потом его парсить через встроенный "generate metrics" который в бете.... и то не всегда все логи отпаршивает

а вот как отдельный мониторинг системы - огонь

Коллеги, добрый день! Кто может подскажет откуда ноги растут?

Пытаюсь сохранить тело запроса в препроцессоре

Jsr223

а код сам дср можно?)

По документации вроде корректно, но может и в глаза долблюсь...

При получении через контекст также ошибка

Но при этом значение сохраняется)))

import org.apache.jmeter.config.Argument;
import org.apache.jmeter.config.Arguments;
String body = ctx.getCurrentSampler().getArguments().getArgument(0).getValue();
vars.put("body", body);