да мы вроде и не про открытую и закрытую модель.
моя ключевая часть позиции - проблема интерпретации. это к тому, что в отчетах хотят писать юзеров чтобы показывать бизнесу.
но данная хотелка заставляет пилить скрипты через нагрузку в тредах. что ЧАСТО (не всегда) приводит к сценарному подходу.

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

поэтому я комплексно не понимаю, зачем люди именно пропагандируют этот подход.

а в процессе обсуждения искали минусы в моем подходе и реализации, попутно его выясняя. но конструктива пока мало

В самом опеншифте есть мониторинг.

он вроде только за маленький интервал

Не поленился посмотрел.

неделя

а где такая вьюшка, я только в подах вижу метрики

Девелопер - Мониторинг

но там от версии опеншифта зависит. в старых по моему нет.

понял, похоже старый у нас

Одна итерация сценария = 1 пользователь
Интенсивность по количеству итераций сценария в минуту или в час  = результат нагрузки, который пишут в отчет

Потоки в отчет не пишут же.
Если кто-то пишет количество потоков в отчет. То это ошибка интерптерации, согласен
Это можно написать как справочную информацию

Нагрузка подавалась с машин на которых было 8 ядер CPU, 16 ГБайт памяти, машин было 3, Xmx был 10 ГБайт, потоков было до 3 000.

Но не как результат. Результат это сценарии - сколько сценариев было сделано.
А сколько при этом ресурсов было затрачено не особо важная информация, обычно

ну я не про этот кейс. к сценарному подходу у меня тоже есть вопросы - но меньше сильно)

Вот это слово в скобках - большой обман, согласен

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

Вот так можно подать стабильную нагрузку в 10 сценариев в сек, в течение 100 сек

В этом и только в этом случае
Значение 1000 в поле Number of Threads (users) соответствует количеству операций, которые сделали пользователи

А значит это 1000 пользователей в сумме запустят свои сценарии в течение 100 сек

Вот так уже 2000 пользователей запустят свои сценарии

И слово users в скобках уже становится неправдой

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

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

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

Да, при выполнении одинаковых транзакций в разных сценариях тяжело точь в точь воспроизвести тпс с условного прода. Но при сложных юзкейсах это почти нереально сделать и на уровне рпса, поскольку почти никогда нет  end-to-end кейсов которые будут в 100% случаев выполнятся сначала и до самого конца

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

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