+1

Да, когда не сможет под контекст выделить минималку

Типа, мне было бы удобнее чтобы вместо замедления интенсивности, jmeter мне сразу бы кидал oom при нехватке памяти) так легче детектить, что ее не хватает

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

А гиг памяти весь в хипе был?

Ага

Ну может это и показатель

Ну или сделай правило :
Когда увеличение ресурсов не повысило производительность, можно считать, что максперф найден

Не, я расколол этот jmeter! Он отжирает очень большой буфер, если ему дать возможность. Типа, без каких либо причин съест 3-4-5 гб, в то время как этот же тест мог бы спокойно работать на 2

Ага, но об этом нужно всегда помнить и это потенциально лишние тесты

Типа, да, с этим приходится жить

Опыт сын ошибок трудных ...
Я слоу, и читаю чатик по диагонали.. но если бы вы знали сколько человек яростно желают проводить тесты нагрузки в продакшене, вы бы удивились.
Не проходит и месяца, как нам прилетат кто-нибудь с таким желанием.
И приходится объяснять, что это не самая хорошая идея, но нет, мы идём своим путём.
Итак, где тестирование в пром, случалось на моей практике.
1. Госуха, тестового стенда нет и не предвидится, но можно волевым решением сделать технологическое окно и остановить систему.
2. Тестируем на продуктивном стенде и железе перед выводом в эксплуатацию (так называемый Пре-пром).
3. Идея постройки идемпотентной модели, не меняющей состояние после тестов. Обычно это какая-то очень маленькая часть нагрузки. На моей памяти даже после создания такой модели приходит понимание, что это не показательно.
4. Есть система не бизнес-критикал, и не мишен-критикал, и хорошо масштабируется и есть изолированные филиалы или модули. Но опять адово согласовать это.
5. Стартапы и не Энтерпрайз,
Тут не про деньги.

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

вообще я просто пошутила в сторону одной из весьма радикальных фраз Rины: "я не рекомендую никому из этого чата тестировать в prod" :)

а если по сабжу: приведенные кейсы вроде как делятся на "авось никто не заметит, а если и да, то пофигу" — это 1, 4, 5, "хз зачем, но очень хочется в проде посмотреть" — это 3, ну а 2ое вообще не тест в проде как таковой...

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

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

Список оценки обычно индивидуальный. Мы всегда делаем индивидуальную оценку для каждого проекта.
Но чтобы понять масштаб, можно начать с отдельной методики НТ и отдельного профиля, и отдельного набора скриптов.

Да верно, он сожрет даже 100 гб)

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

Только вместо хрома жметер?

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

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