предполагаю что бы интенсивность не падала если времена выполнения будут большими чем пейсинг

*3 надо чтобы мочь посмотреть динамику около целевого значения, а не бинарно "уложились или нет"

А как часто приходится проводить тест при временах отклика под 2хSLA? Или 3хSLA? Иногда это может потребоваться. Но есть ли смысл выполнять это в общем случае?

3xSLA - это разве "около целевого значения"?

в общем случае тест где времена выше сла конечно не будет считаться успешным да)

а вы бы взялись ручатся что все хорошо и можно внедрятся если в тесте такое превышение сла?)

пример из работы прям текущей: один из клиентов требует ответ 300мс 100%, остальные 1с 100%. на данный момент это несколько фантастические тайминги, и мы можем вылетать за секунду — работаем над этим. но как мне понять, что работаем мы успешно? а вот так: в конфигах приложения трешолды поднимаю например до 5с, а в графане на графике респонсов рисую клиентские трешолды. таким образом мы знаем: 1) укладываемся ли куда-то, 2) насколько всё плохо, 3) можно сравнить с прошлым коммитом

я бы как лид такое заключение в жизни не отправил бы))

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

почему, как нам это починить, в чем проблема и, главное, масштабы катастрофы какие

требует ответ 300мс 100%, остальные 1с 100%.
вот тут не совсем понимаю, как у 100% операций ответ может быть 300мс и 1с одновременно

один клиент одно сла хочет, другие другое

а ну по сути как раз то о чем я и говорил выше, что по мнт такой тест не будет успешным но может быть нужно :)

я отвечала на тему "зачем умножать"

Воооот. К этому и хотел подвести. А есть ли смысл привязывать пэйсинг именно к SLA?
КМК, пэйсинг надо привязывать к реальному времени выполнения операции, а не к SLA.

пэйсинг к реальности, а соответствие сла по результатм оценивать

или просто в баню пэйсинг)

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

Именно к этому я и хотел подвести

как вам идея "в баню пэйсинг"?)