гатлинг?

угу

ну только из cart надо передать переменную в order

:)

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

так легко, она у нас всегда будет) getCard же выполнится в любом случае

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

а не увидел второго exec - ок

Так трафик же ничем не отличается и ты его волне себе полностью контролируешь в обоих случаях.

Возможно, мы говорим примерно об одном и том же)

точно нет, усреднение сценария пользователя и скейлинг до их количества в проде != сбор их суммарного импакта в систему и построение профиля на основе этого

Ну хззз, готов поспорить.
При покрытии в районе 80% вполне себе оно показывает как система будет вести себя при аналогичных уровнях на проде.

Вот не соглашусь.

1) Зачастую, бизнес-операции происходят с какой-то зажержкой между собой. Например, пользователь добавил что-то в корзину, а через какое-то время оформил заказ.

Как проверить «оформление заказа», если мы говорим только про «rps подход»? Вот реально как? Откуда корзина возмётся? Мы её создадим непосредственно перед вызовом «оформления заказа»?
В реальности же, если есть задержка между добавлением в корзину и оформлением, то данные могут вымыться из кэша и профиль нагрузки на диски будет другой, несмотря на то, что «общее колиество операций такое же».

2) Зачастую, длительность операций зависит от их объёма. Например, если по сценарию пользователю нужно «добавить что-то в корзину», то длительность добавления может внезапно зависеть от текущего размера корзины.  И хорошо бы проверять разные случаи: «добавим 1 элемент», «добавим 5 элементов». Вот и получилось у нас 2-3 end-to-end сценария. Внимание, вопрос: а будет ли лучше, если мы попытаемся их изобразить исходно в виде «одной только нагрузки про корзину» — да не факт.


Я не говорю, что «только end-to-end, только так», но ооочень странно слышать слова, что «нагружать низкоуровневые части всегда достаточно». Никто же не говорит, что «интеграционные тесты не нужны»? Почему же тогда кто-то говорит, что «интеграционные тесты производительности не нужны»?

Ну 2й пункт легко делается в одном сценарии

А про первый ты не совсем прав

воспроизводил по статистике и получил один в один % соотношения запросов по NewRelic и вышло точная копия продовского поведения, разве в этмо случае можно говорить про то, что это не показывает реальной картины?

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

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

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

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

ты про рпс подход? или ты это сделал юзерами?

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

Юзерами

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