Как реанимировать умирающий интернет-магазин

и не потерять продажи в пик сезона

опубликовано
5159 10 мин.

Для интернет-магазина любое «падение сайта» — это провал в продажах, потеря десятков или сотен тысяч выручки. Расскажем, что нужно проверить, чтобы сайт работал стабильно и не падал при любых нагрузках, даже в пики сезона продаж.

Недавно к нам на поддержку пришел проект. Выглядел заурядно: небольшой интернет-магазин, в каталоге 10 тыс. товаров. Сайт лежал на мощном выделенном сервере — никаких проблем не ожидали. Но через несколько дней проект стал жить своей жизнью: падал, неохотно поднимался.

Прежняя служба поддержки разводила руками: их администратор увольнялся и не хотел вникать. Стали разбираться: в одних случаях сайт поднимался, когда оживляли базу данных, в других — после спада наплыва посетителей. У нас появилось две задачи:

  1. Сделать так, чтобы сайт работал стабильно и не падал при текущей посещаемости.
  2. Пережить в старой версии сайта пик сезона продаж, который наступает через два месяца.
    В пик сезона количество пользователей на сайте увеличивается в несколько раз.

Чтобы решить эти задачи, мы решили поочередно оптимизировать:

  • Серверное ПО и железо
  • Код сайта
  • Фронтенд части
Оптимизация серверного ПО

Проект работал на связке nginx + apache. Кого-то в 2016 году, возможно, удивит выбор apache в качестве web-сервера (не правда ли, очень очевидная для всех вещь ;) ), но только не разработчиков Bitrix, которые рекомендуют использовать именно его. Для нагруженных проектов он не подходит, поэтому в первую очередь было решено перевести проект на php-fpm.

Мы решили перевести проект на php-fpm. Изучили форум Битрикса, поняли, что это решение неофициальное, но рабочее. Два дня меняли настройки, переписывали конфигурацию htaccess на правила nginx, еще один вечер убили, чтобы переключить сайт в наименее посещаемое время. Ничего не изменилось: никаких улучшений в производительности. Бэкенд отдавался визуально быстрее и стал более отзывчивым, но время генерации страницы в пиковые периоды все так же переваливало за 5 секунд.
Мы надеялись на «серебряную пулю», но пришлось искать другое решение.

Поняли, что больше всего нагрузки давала база данных. Решили перенести ее на отдельный производительный сервер. Арендовали сервер у хостера, настроили конфигурацию и репликацию базы данных. Подождали, когда синхронизируется база данных на три гигабайта, еще один субботний вечер потратили на переключение — никакого результата.

Оказалось, сам веб-сервер тратит мало ресурсов. Мы получили вместо одного перегруженного сервера такой же перегруженный сервер с базой данных и второй - скучающий, практически без нагрузки.

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


Оптимизация кода сайта

Мы нашли, что самое узкое место — фильтр товаров. Он создавал наибольшую нагрузку на базу данных. Значит, нужно его кешировать и отдавать пользователям сохраненный результат. Серверу стало легче, появилась надежда, что мы на правильном пути. Но нагрузка все еще была близка к критическому значению.

Стали разбираться дальше: большинство посетителей приходит на сайт из рекламных кампаний на страницы с заранее сформированными наборами фильтров. Добавили страницы из рекламных кампаний в кеш — нагрузка на сервер снизилась до приемлемого уровня.

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

По оптимизации сложно давать конкретные советы, потому что каждый случай индивидуален.
В общем случае нужно действовать так:

  1. Найти самые узкие места и начать оптимизацию с них.
  2. Добавить в кеш все, что требует серьезных вычислений, редко меняется, но часто запрашивается пользователями.
  3. Помнить, что несколько простых запросов по индексам практически всегда производительнее, чем один сложный без них.
Оптимизация фронтенда

После решения проблем с серверной частью, взялись за фронтенд. На сайте было установлено невероятное количество партнерских программ, счетчиков, рекламных модулей, консультантов и т. д. Эти скрипты подвешивали браузер пользователя, отрисовка элементов страницы занимала еще около 7-10 секунд.

Мы провели с отделом маркетинга аудит рекламных модулей и счетчиков, удалили неиспользуемые. Сделали анализ функционала. Оказалось, что один модуль может выполнять несколько функций — не нужно для этого использовать разные сервисы.
Для отслеживания рекламных кампаний на сайте использовался Comagic, а для онлайн-консультанта стоял другой скрипт. В Comagic тоже есть онлайн-консультант, поэтому оставили только его.
После изменения фронтенда сайт перестал раздражать посетителя всплывающими окнами, время отображения страницы в окне браузера сократилось в два раза.

Чтобы оптимизировать фронтенд, нужно:

  1. Сократить количество загружаемых скриптов в браузере пользователя.
  2. Объединить файлы скриптов и стилей.
  3. Отказаться от сложных и тяжелых скриптов или плагинов в пользу легковесных.
  4. Следить за количеством, не лениться удалять неактуальные или устаревшие.

Результат

Работы c сервером результата не дали, но помогли увеличить отказоустойчивость проекта и пережить пик сезона. Сайт выдерживал более 20 тысяч посетителей в сутки без падений сервера.

Работы по оптимизации php-кода позволили сократить время отдачи страницы с неприличных 5-7 секунд до приемлемых 1-1.5 секунды в периоды наибольшей нагрузки.

Работы по оптимизации фронтенд части позволили сократить время загрузки пользовательских скриптов с 10 до 2 секунд, вернули комфортную работу с сайтом.

Шпаргалка: если интернет-магазин не справляется с нагрузкой
1.
Проводим общий анализ производительности
Выявляем слабые места, определяемся, в каком направлении нужно приложить усилия в первую очередь (база данных, код сайта, сервер и программное обеспечение)
2.
Включаем лог медленных запросов, анализируем запросы к базе данных
Расставляем необходимые индексы. Разбиваем сложные запросы по большому количеству данных на несколько простых выборок по индексам.
3.
Добавляем кеширование страниц или отдельных блоков
Кешируем все, что часто запрашивается, но редко меняется. Особое внимание уделяем навигационным меню и фильтрам.
4.
Оптимизируем пользовательские скрипты
Удаляем неиспользуемые скрипты, отказываемся от тяжелых. По возможности добавляем их асинхронную загрузку.
5.
Используем производительное программное обеспечение на сервере
Переводим сайт на работу на связке php-fpm+nginx, если этого до сих пор не сделано. Отказываемся от apache.
6.
Увеличиваем ресурсы сервера
Считаем, сколько будет стоить докупить железо, увеличить ресурсы в Облаке, перенести сайт на более производительный сервер. Сравниваем с потерями, которые несем от оттока посетителей, принимаем решение.
Поделиться статьей
Комментарии
Другие статьи
То самое чувство, когда нужно снять рекламный ролик

На примере CUBE: #ТоСамоеЧувство
 

опубликовано
5852 15 мин.
Как продвигать в интернете новые бренды

Ошибки и решения

опубликовано
4424 15 мин.