Как реанимировать умирающий интернет-магазин
и не потерять продажи в пик сезона
IT-директор
Недавно к нам на поддержку пришел проект. Выглядел заурядно: небольшой интернет-магазин, в каталоге 10 тыс. товаров. Сайт лежал на мощном выделенном сервере — никаких проблем не ожидали. Но через несколько дней проект стал жить своей жизнью: падал, неохотно поднимался.
Прежняя служба поддержки разводила руками: их администратор увольнялся и не хотел вникать. Стали разбираться: в одних случаях сайт поднимался, когда оживляли базу данных, в других — после спада наплыва посетителей. У нас появилось две задачи:
- Сделать так, чтобы сайт работал стабильно и не падал при текущей посещаемости.
-
Пережить в старой версии сайта пик сезона продаж, который наступает через два месяца.
В пик сезона количество пользователей на сайте увеличивается в несколько раз.
Чтобы решить эти задачи, мы решили поочередно оптимизировать:
- Серверное ПО и железо
- Код сайта
- Фронтенд части
Проект работал на связке nginx + apache. Кого-то в 2016 году, возможно, удивит выбор apache в качестве web-сервера (не правда ли, очень очевидная для всех вещь ;) ), но только не разработчиков Bitrix, которые рекомендуют использовать именно его. Для нагруженных проектов он не подходит, поэтому в первую очередь было решено перевести проект на php-fpm.
Мы решили перевести проект на php-fpm. Изучили форум Битрикса, поняли,
что это решение неофициальное, но рабочее. Два дня меняли настройки, переписывали конфигурацию
htaccess на правила nginx, еще один вечер убили, чтобы переключить сайт в наименее посещаемое
время. Ничего не изменилось: никаких улучшений в производительности. Бэкенд отдавался визуально
быстрее и стал более отзывчивым, но время генерации страницы в пиковые периоды все так же
переваливало за 5 секунд.
Мы надеялись на «серебряную пулю», но пришлось искать другое решение.
Поняли, что больше всего нагрузки давала база данных. Решили перенести ее на отдельный производительный сервер. Арендовали сервер у хостера, настроили конфигурацию и репликацию базы данных. Подождали, когда синхронизируется база данных на три гигабайта, еще один субботний вечер потратили на переключение — никакого результата.
Оказалось, сам веб-сервер тратит мало ресурсов. Мы получили вместо одного перегруженного сервера такой же перегруженный сервер с базой данных и второй - скучающий, практически без нагрузки.
Увеличение мощности железа - способ простой, быстрый и относительно дешевый, но часто он не приносит результата. Этот больше похоже на лечение симптомов болезни, а не ее самой. Решение помогает в простых случаях, если чуда не произошло - переходим к оптимизации кода сайта.
Мы нашли, что самое узкое место — фильтр товаров. Он создавал наибольшую нагрузку на базу данных. Значит, нужно его кешировать и отдавать пользователям сохраненный результат. Серверу стало легче, появилась надежда, что мы на правильном пути. Но нагрузка все еще была близка к критическому значению.
Стали разбираться дальше: большинство посетителей приходит на сайт из рекламных кампаний на страницы с заранее сформированными наборами фильтров. Добавили страницы из рекламных кампаний в кеш — нагрузка на сервер снизилась до приемлемого уровня.
Потом перешли к оптимизации запросов к базе данных. Выявили медленные запросы, разбили на части, чтобы сделать выборку проще. Нашли запросы без индексов - добавили необходимые индексы.
По оптимизации сложно давать конкретные советы, потому что каждый случай индивидуален.
В общем случае нужно действовать так:
- Найти самые узкие места и начать оптимизацию с них.
- Добавить в кеш все, что требует серьезных вычислений, редко меняется, но часто запрашивается пользователями.
- Помнить, что несколько простых запросов по индексам практически всегда производительнее, чем один сложный без них.
После решения проблем с серверной частью, взялись за фронтенд. На сайте было установлено невероятное количество партнерских программ, счетчиков, рекламных модулей, консультантов и т. д. Эти скрипты подвешивали браузер пользователя, отрисовка элементов страницы занимала еще около 7-10 секунд.
Мы провели с отделом маркетинга аудит рекламных модулей и счетчиков, удалили
неиспользуемые. Сделали анализ функционала. Оказалось, что один модуль может выполнять
несколько функций — не нужно для этого использовать разные сервисы.
Для отслеживания рекламных кампаний на сайте использовался Comagic, а для онлайн-консультанта
стоял другой скрипт. В Comagic тоже есть онлайн-консультант, поэтому оставили только его.
После изменения фронтенда сайт перестал раздражать посетителя
всплывающими окнами, время отображения страницы в окне браузера сократилось в два раза.
Чтобы оптимизировать фронтенд, нужно:
- Сократить количество загружаемых скриптов в браузере пользователя.
- Объединить файлы скриптов и стилей.
- Отказаться от сложных и тяжелых скриптов или плагинов в пользу легковесных.
- Следить за количеством, не лениться удалять неактуальные или устаревшие.
Работы c сервером результата не дали, но помогли увеличить отказоустойчивость проекта и пережить пик сезона. Сайт выдерживал более 20 тысяч посетителей в сутки без падений сервера.
Работы по оптимизации php-кода позволили сократить время отдачи страницы с неприличных 5-7 секунд до приемлемых 1-1.5 секунды в периоды наибольшей нагрузки.
Работы по оптимизации фронтенд части позволили сократить время загрузки пользовательских скриптов с 10 до 2 секунд, вернули комфортную работу с сайтом.