Профиль нагрузки
Что делают пользователи и в какой пропорции: смотрят каталог, ищут, оформляют заказ.
Тест строится на реальном профиле нагрузки, а не на абстрактном числе пользователей.
Что делают пользователи и в какой пропорции: смотрят каталог, ищут, оформляют заказ.
Скрипты, повторяющие реальное поведение, включая паузы между действиями.
Наращиваем нагрузку и фиксируем, при каком количестве начинается деградация.
Что упирается первым: процессор, память, диск, база данных или внешний сервис.
Что происходит за пределом: плавная деградация или полный отказ и как система восстанавливается.
Что настроить, что оптимизировать, что масштабировать и в каком порядке.
Подготовка сценариев - несколько дней. Сами прогоны идут быстро, повторяются после каждой доработки.
Какую нагрузку нужно держать и с каким временем отклика. Без числа тест бессмыслен.
Тестовый контур, скрипты, наполнение данными, сопоставимыми с боевыми.
Постепенный рост, фиксация метрик на каждом уровне.
Отчёт с узкими местами и приоритетами оптимизации.
Тестировать на пустой базе бессмысленно. Каталог из ста товаров ведёт себя иначе, чем из ста тысяч: запросы, которые работали мгновенно, начинают перебирать таблицы. Тестовый контур должен быть сопоставим с боевым по объёму данных.
Крайне нежелательно: тест может положить его для реальных пользователей и испортить статистику. Правильный путь - копия на отдельном контуре. Если копии нет, тест проводится ночью с ограниченной нагрузкой и по согласованию.
Пиковую, а не среднюю, с запасом в два-три раза. Средняя посещаемость мало что говорит: нагрузка приходит всплесками после рассылки, рекламы или упоминания в СМИ.
Порядок обычно такой: сначала настройка кеширования и оптимизация запросов к базе - это дешевле всего и часто даёт кратный эффект. Наращивание ресурсов - следующий шаг, а переработка архитектуры - последний.
Расскажите, какую нагрузку ожидаете и когда. Смоделируем и покажем, где система начнёт сдавать.
Город не найден. Проверьте написание.