Я надеялся, что можно сделать пул из гита, и там уже будет пул.

Ну короче, проблема нигде нормально не решена. Две недели закопать все равно придется.
Серьезные пацаны вообще Istio берут и месяцами страдают, чтобы с этим жить.

хай! а есть какие-то гайды по написанию перфоманс тестов на английском? тестировщик хочет тестировать перфоманс по 1й минуте - тотальное непонимание, как системы рабоатют.

Литературы на английском полно, смотри в закрепе

статьи на русском

Так-то очевидно, что тестировать по минуте - хреново
Но в плане разминки для ума - можно обдумать ситуацию, когда можно :)

так WRK ему в помощь, инструмент как раз и ориентирован на "БАБАХ!" в пару минут, лупит мощно и от души, но сценарии самые простые
правда сразу надо упомянуть, что долгосрочных эффектов нагрузки он не увидит

1) разогрев системы не нужен (не требуется или уже сделан)
2) за минуту система успевает сделать >100 (лучше >1000) полноценных тестируемых кейсов

Другой вариант - тестирование конкретной баги, которая проявляется под нагрузкой в течение минуты

все перфоманс сценарии которые он мне принес идут по одной минуте, и у нас жаба

ГЦ, разогрев, буфера в ОС...

тот же ССД, который может со временем деградировать

:)

Так что, есть что-то не на 100+ страниц, чтобы у парня хоть что-то появилось в голове на тему сценариев?

Всем привет
Вопрос по созданию профиля нагрузки в jMeter
Хочу использовать Throughput Shaping Timer
Но не совсем понимаю как правильно использовать значения в нем
Например, есть сценарий нагрузки на 8 запросов, есть профиль нагрузки
Start RPS 1 = 10
End RPS 1 = 100
Duration 1 = 60
————————
Start RPS 2 = 100
End RPS 2 = 100
Duration 2 = 600

Как правильно задать значения users, ramp-up, loop?
По логике ramp-up = Duration 1 + Duration 2 = 660
loop = 1
Все приводят такую формулу Thread Pool Size = RPS * <max response time> / 1000

и правильно приводят формулу: рамп ап и максимальный лимит "юзеров" не важен, если у вас ограничение в рпсах.
активно использоваться будет только то число "юзеров", которые необходимы для генерации рпс в текущий момент времени, согласно схеме.
либо сервер должен отвечать достаточно быстро, либо "юзеров" - достаточно много.

Поправлю - треды - это не лимит юзеров. Все треды в случае обычной тред группы стартуют в течении ramp-up независимо от timers(в нашем случае Throughput Shaping Timer). В сценарных тестах(а зачем еще нужен jmeter) кол-во тредов имеет значение. Шедулер лишь паузы между семплерами подбирает динамически между всеми тредами, но все треды работают параллельно.

https://jmeter-plugins.org/wiki/ThroughputShapingTimer/
"provide enough working threads for your RPS, JMeter timers can only delay threads (and limit RPS). You may pair this plugin with Concurrency Thread Group using Schedule Feedback Function to dynamically maintain thread count required to achieve target RPS."

проще всего посмотреть максимальное время выполнения операции на прогоне, например там пол секунды, закладываем сколько то на случай деградации - допустим секунда. таким образом 1 тред максимально сможет выполнять 1 рпс в худшем случае. применяем к своим данным - максимум у вас 100 рпс, тогда вам должно хватит 100 юзеров

@pavelbulich важно прикинуть времена отклика и взять максимальный свой, без этого оценить нужное количество тредов, можно только экспепементально. либо взять заведомо очень много, но это может негативно сказаться на системе

Спасибо, буду экспериментировать)