Нет прома, нет аналитиков( только "не должно упасть"

это я тоже понимаю, поэтому эти сценарии дополнительно еще буду согласовывать. Сейчас я даже объяснить не смогу ПМу что от него надо так как еще даже макеты не до конца согласованы. Соответственно, сценарии могут поменяться

ступени это примерно:
Поднять нагрузку от 1 до 100 запросов в секунду на протяжении 60 секунд
Держать нагрузку 100 запросов в секунду на протяжении 600 секунд
Поднять нагрузку от 100 до 150 запросов в секунду на протяжении 60 секунд
Держать нагрузку 150 запросов в секунду на протяжении 600 секунд

?

да

Да, и так рекурсивно ищем момент деградации системы

О) 🤣 не увидел

Привет!
У вас 1C Bitrix, как в статье?

Если да, то там есть контент, который стоит кешировать. Оценить настройки кеширования можно с помощью
https://www.webpagetest.org/
https://developers.google.com/speed/pagespeed/insights/?hl=RU
Обратите внимание на рекомендации этих простых инструментов.

Там есть PHP Byte Code, который стоит кешировать.

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

И есть база данных. В простом случае, если не настроен мониторинг MySQL, то можно просто заливать процессорами сервер. И нужно мониторить утилизацию процессора. И количество подключений к серверу баз данных. Если есть
https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&CHAPTER_ID=1146
То воспользутесь этим мониторингом. Подробный мониторинг в финальном тесте включать не надо - он понадобится для поиска узких мест. В пристрелочных тестах достаточно будет общего мониторинга

"И как только вы понимаете что различия в ожидании(подаваемая нагрузка) и факте(RPS) вас не устраивают начинается самое интересное))) "  - вот еще бы понять как пересчитать эту подаваемую нагрузку в пользователей для ПМа...и как понять, что "перестало устраивать"...у меня разработчики в мониторе производительности в CMSке не могут объяснить значения на графиках...только количество запросов и в какие часы...а что означает вертилькальная/горизонтальная шкала нет...

ну если сделали например пропорцию 70% рпс поиск а 30% покупка, то максперф может отличаться от того что будет 30% поиска и 70% покупок

т.е. поиск нагружает систему сильнее чем покупка билета

Привет! Извиняюсь что вклиниваюсь, что значит «просто  заливать процессорами сервер»?

процессоромешалка нужна, в жидком виде льем - засыхает час при +25

😀

это уже соответствие модели НТ и ПРОМа, Но да, вещь важная

ахахаха

Ага )
По тексту предположил, что разработчиков нет, аналитиков нет, ... Есть только тестировщик. В этом случае, разобраться, как оптимизировать запросы - долгая задача. И чтобы устранять узкие места в БД самое быстрое - добавлять туда процессорные мощности. Дорого, но быстро.

Сверху , покрошить пару плашками оперативны на 32)

Да, на CMSке Битрикс сайт. Рекомендацию по кешированию - для снижения нагрузки, правильно понимаю и к как таковому нагрузочному тесту отношения не имеют? Я читала, что через Jmeter фронтэнд не грузят (благо его и нет, сайт-по сути новостной портал, с парой форм)
Про него (монитор производтиельснтис) и я написала после вашего поста) что не умеем с ним работать (хотя по идее он работает на основе ЯндексТанка)

Прям в суть попали)) вишенка на торте - хостинга еще нет, а сдавать послезавтра

Из-за простоты этих проверок они рекомендуемые перед проведением теста. Предусловие