Почти каждая веб-студия слышит от клиента одну и ту же фразу: сайт жутко тормозит, сделайте что-нибудь. Беда в том, что узкое место ищут уже после запуска - когда реклама проплачена, трафик пришёл, а система его не держит. Остановить кампанию выходит не всегда: баннер на чужом сайте уже оплачен, и снимать его никто не будет.
Поэтому про производительность уместна поговорка: готовь сани летом. Нагрузочное тестирование заранее показывает, сколько посетителей сайт выдержит и что сломается первым - чтобы наплыв трафика не превратился в отказ сервиса.
Почему сайт работает медленно
В подавляющем большинстве случаев причина - одна из двух:
- →Неоптимизированный код - тяжёлые запросы, лишние обращения к базе, отсутствие кэша.
- →Ограничения хостинга - низкий тариф, слабое железо, узкий сетевой канал.
Даже если сегодня сайт быстрый, на старте полезно ответить на три вопроса: при каком числе посетителей скорость страниц ещё комфортна; при каком наступает отказ сервиса; за счёт чего сайт ляжет в первую очередь - процессора, памяти или сетевого канала. Последнее особенно важно при наплыве новых пользователей: в их браузерах ещё нет закэшированных стилей, картинок и скриптов, и узкий канал может убить сайт просто трафиком.
Что такое нагрузочное тестирование
Нагрузочное тестирование - это проверка производительности сайта под потоком запросов: сбор метрик, измерение времени отклика и сопоставление с требованиями. Тест прогоняют специальными сервисами - например, k6, Apache JMeter, Яндекс.Танк, BlazeMeter. При выборе сервиса смотрят на несколько вещей:
- →Что измеряет - только время генерации страницы или полную загрузку с nginx, который отдаёт статику (js, css, картинки). Полная загрузка показательнее.
- →Сложные сценарии - умеет ли прогонять цепочку вроде оформления заказа, а не только дёргать одну страницу.
- →Расписание - можно ли запустить тест ночью, не нарушая сон админу.
- →Лимиты и пинг - хватает ли мощности по числу соединений и насколько близко нагрузочный сервер к вашему.
На что обратить внимание при тесте
- 01Отключите кэш. Чтобы найти узкие места, тестируйте с выключенным кэшем - и самого Битрикса, и низкоуровневого MySQL. Под это держат отдельные скрипты на cron.
- 02Наращивайте нагрузку постепенно. Сразу на максимуме потоков легко уронить сервер. Идите серией тестов, увеличивая потоки шагами.
- 03Отключите контроль активности Битрикс или добавьте исключения - иначе нагрузочные серверы быстро забанит, и оплаченный тест отработает вхолостую.
- 04Поднимите лимит соединений MySQL выше прогнозируемого числа потоков, иначе получите ошибку Too many connections вместо честной картины.
Сценарии решают всё
Ключевая ошибка закрадывается в самом начале - в выборе, куда слать нагрузку. Если направить ботов не на узкое место, тест покажет отличный результат, а реальные пользователи получат отказ сервиса. Поэтому запуску всегда предшествует моделирование действий пользователя: открытие карточки и оформление заказа - это разная нагрузка, как и заказ на 50 позиций против заказа на 800.
Прежде чем составлять сценарии, изучите статистику Яндекс.Метрики или аналитики: на какие страницы заходят, чем пользуются, сколько товаров в среднем и в максимуме кладут в заказ. При росте трафика те же действия вырастут пропорционально - вот на них и направляют ботов.
Типичный набор действий интернет-магазина, который стоит заложить в сценарии:
- →главная, список товаров, последняя страница пагинации, карточка товара;
- →сортировка, переключение количества на странице, умный фильтр, поиск по сайту;
- →добавление в корзину, регистрация, авторизация;
- →корзина с малым и большим числом позиций;
- →оформление обычного, оптового и быстрого заказа.
Не откладывайте на потом
Нагрузочный тест особенно важен перед всплеском спроса - маркетинговой кампанией или сезоном: цветы к 8 Марта, шины в межсезонье. Но задача шире разового пика: это и поиск узких мест, и проверка запаса прочности сервера, и балансировка в веб-кластере, и подготовка нового сайта к публикации на продакшен.
Базовую проверку модулями Битрикса можно сделать самому - см. самостоятельный аудит сайта на 1С-Битрикс. Часть нагрузки на больших каталогах снимает HTTP-кэширование, а тяжёлый код иногда тянет за собой перевод сайта на PHP 8. Если хотите узнать запас прочности до того, как придёт трафик, - проведём нагрузочное тестирование и покажем, что чинить.
