Угу в гутленге тож так можно

понял, думал может есть джедайские техники

Только ситхские

О каком докладе речь? Можно ссылку?)

Джедайские есть, называются https://en.wikipedia.org/wiki/Integer_programming

Для особо внимательных, там есть глава «Proof of NP-hardness»
Т.е. это в алгоритмически «нерешаемая» задача

Если честно, то не понимаю зачем в таком случае делать новые тг, если можно тыкнуть обычную, и там в самом начале ставить shaping timer.

Типо понятно, что на данный мосент задачи по контролю рпс и тесту открытой моделью решены костылями, но эти костыли уже настолько устоялись, что все привыкли 😂

шейпинг таймер работает плохо

Timer может лишь притормозить треды, но он не может сказать «ей, пока не надо их создавать».
А у нас возникла ситуация, что тестировать нужно 48+часов, и если тредов будет создаваться многовато, то стабильность плохая. Циклы в TG почему-то не хотят использовать (ну, пробовали год назад, почему отказались от цикла уже никто не помнит)

Хмммм

Да и в целом, не барское это дело следить за тредами и rampup.
Надо чтобы «хочу N rps» и чтобы оно давало эти N rps.

Очень интересно.  Мы и циклами и рампапами постоянно пользуемся и не встречали проблем. Даж на тестах сравнимых по продолжительности

Аминь 🙏

В целом хотелось бы такую функциональность, но и подход с тредами (виртуальными пользователями) тож очень полезен. Да же заказчикам зачастую проще объяснятт не в рпс и тпс, а в пользователях

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

Вот если бы в рамкой одной тг или всего  теста можно было тпсы устанавливать, вот это было бы огонь 🙂

Может потому что ломается стандартный механизм ассершенов и перехода на след итерацию?

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

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

Если я усну а проснусь через сто лет и меня спросят что происходит в qaload, я отвечу: обсуждают катушки в жметер
Салтыков-Щедрин 1889г

каждый день это разные юзеры, кто-то пошел кофе пить, у кого то кот по клаве пробежал

ну нет же! объясняют почему погано подавать нагрузку в юзер