«Пан Чемодан»: как мы снизили нагрузку на сервер в 2 раза

«Пан Чемодан» уже 20 лет на рынке мужских и женских сумок и чемоданов. Сейчас в России открыто 62 бутика.

У клиента возникла проблема: из‑за высокой нагрузки на сервер сайт работал медленно — в первую очередь корзина. Для пользователей интернет-магазина это означало сложности с оформлением заказа. Для клиента — падение продаж.

Отзыв клиента

Проект активно эволюционировал и развивался с 2016 года. В прошлом году мы столкнулись с новым препятствием — огромным количеством самописного кода, который начал блокировать обновление движка и установку новых модулей. На любую задачу, будь то установка эквайринга от Сбербанка или интеграция сервисов Mindbox, приходилось тратить в разы больше времени. Увеличивалось время загрузки и обработки, усложнялся поиск ошибок в случае возникновения сбоев. Перерабатывать и перезапускать проект с нуля в этот раз мы были не готовы: слишком высокие косты и риски. Поэтому мы искали. Долго и сложно искали нового подрядчика, который сможет не только бесшовно подхватить проект, но и так же бесшовно обновит версию Битрикса, поможет оптимизировать работу всех систем — от фильтров до промокодов. Мы провели огромное количество переговоров, расчетов и встреч, но все, как один, настаивали на полном перезапуске. Единственным исключением стала Intensa, хотя по началу этот вариант тоже неоднократно звучал.

Предыстория

Клиент подключил программу лояльности, которая генерирует десятки тысяч купонов — сервер и платформа 1С-Битрикс не потянули такую нагрузку.

Проблему надо было решать на системном уровне: снизить нагрузку на сервер и увеличить скорость загрузки корзины.

Что сделали

1 этап. Технический аудит

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

• Стандартный функционал не справляется с запросами на полмиллиона купонов в базе, которые рассчитывают скидку при каждой операции.
• Есть проблемы с настройками кеширования в компонентах. У части компонентов неоптимальное значение времени жизни кеша, остальные компоненты не кешируют данные вовсе.
• Запросы к базе данных некорректны — нет условий или ограничений выборки либо запросы в цикле.
• Реализация скриптов импорта каталога неэффективна. Конструкции в коде потребляют слишком много серверных ресурсов.

2 этап. Работы по оптимизации сервера

1. Провели нагрузочное тестирование сервера, чтобы получить точные данные для дальнейшей работы. Для замеров использовали Apache Benchmark. Он показал время ответа сервера при большом количестве запросов — от 2 до 5 секунд.
2. Использовали модуль логирования, чтобы покрыть бекенд проекта таймерами исполнения. Так мы поняли, какие места в коде нужно оптимизировать.
3. Доработали кеширование в проекте, чтобы информация на страницах быстро и регулярно обновлялась. Для этого оптимизировали время хранения кэша и настроили кэширование там, где его не было.
4. Отрефакторили код и оптимизировали запросы к базе внутри компонентов. Это увеличило скорость генерации страниц и уменьшило нагрузку на сервер.
5. Доработали логику подсчета скидки в стандартных компонентах Битрикса — сделали подзапросы купонам и скидкам только на тех страницах, где это нужно. До этого компонент с купонами выводился на всех страницах сайта и лишний раз перегружал сервер.

Что в результате

После того как мы оптимизировали чекаут (страницы оформления заказа), нагрузка установилась на уровне 1,7 секунды без пиковых значений.

Посещаемость чекаута увеличилась на 25%.

Отзыв клиента

Самое главное, что мы хотели получить, — это упрощение дальнейшего развития. А для этого нам нужно было избавиться от всего старого и ненужного. Плюс, значительно улучшить текущие показатели. Сайт начинал откровенно тормозить в самые неподходящие моменты. Это доставляло неудобства пользователям, а мы теряли потенциальные заказы. Люди нервничали, мы нервничали. Никому это не нравилось. После мягкого перезапуска результаты стали заметны сразу. Сначала я даже не мог поверить, что это случилось, и мысленно продолжал искать какой‑то подвох. А его не было. Звонили знакомые и коллеги, говорили: «Ой, как у вас все быстро работает». Покупателям этот факт тоже определенно понравился. Конверсии медленно, но верно поползли наверх. Приятным дополнением оказалось повышение позиций в поисковой выдаче. Приятной неожиданностью стал факт оперативности поддержки. Мы можем писать вечером, по выходным или 31 декабря. И всегда почти моментально получаем ответ. Отдельное спасибо хочу сказать нашему аккаунту Ирине Мигуновой. За профессионализм. За умение полностью интегрироваться в бизнес заказчика. И за простоту в общении. Многим коллегам по цеху следовало бы у нее поучиться.

При нарастающем трафике время ответа сервера уменьшилось в 2 раза.

Оно не превышает 2 секунд даже при пиковых нагрузках во время праздников и акций.

Общее среднее время загрузки всей страницы вместе с контентом уменьшилось на 35%.

Время ответа сервера всего сайта снизилось на 30%. С 1,6 секунды до 1,1.

Скорость работы компонентов каталога возросла на 18%.

Вот так было:

Вот так стало:

Количество обработанных запросов в секунду выросло на 50%.

До:

После:

Среднее время обработки запроса сократилось на 35%.

До:

После:

Общий итог оптимизации серверной части виден на графике ответа сервера. Взяли период с сентября 2019‑го по май 2020‑го.