При работе с сайтом, который растет от увеличения количества товаров или трафика с рекламы в скором времени придется перейти в режим работы под названием highload из-за высоких нагрузок на сервер. Но может произойти и такое, что Ваш сайт не растет, а сервер все чаще перегружается с последующей блокировкой данных. Именно с такой проблемой мы столкнулись, пока дорабатывали сайт для интернет-магазина светового оборудования, у которого в ассортименте имеется более 100 тысяч товаров.
Исходная ситуация
Данный проект располагался на сервере, у которого был высокий потенциал ресурсов, чтобы обеспечивать быструю и бесперебойную работу сайта даже при высоких нагрузках. Но происходило так, что сервер не отвечал на действия пользователей либо реагировал с очень большой задержкой при возрастающей посещаемости сайта.
Поиск проблемы
Проведя аудит настроек сервера и сайта, мы разделили работу на 2 этапа: анализ back-end и front-end. При этом удалось выявить низкую скорость загрузки страниц на back-end’e – около 80 секунд на самых популярных страницах. И как следствие, это приводило серьезному снижению конверсии.
Решение
Шаг №1: настройка баз данных.
Первым шагом являлась настройка баз данных MySQL, при этом, не меняя системы хранения и исходя только из доступных источников и нагрузки проекта. Данные действия были направлены на оптимизацию потребления ресурсов оперативной памяти, что в последствии позволило не уходить с сервера в SWAP, когда, исчерпав все свои ресурсы оперативной памяти, он начинал работать из файла подкачки и тормозил работу сайта.
Шаг №2: смена типа хранения на InnoDB.
Причина выбора именно InnoDB.
В InnoDB все данных хранятся в больших файлах, которые используются вместе, в отличие MyISAM, к помощи которого прибегали раннее. В нем для конкретной таблицы создается отдельный файл данных. InnoDB надежно хранит данные, благодаря их блокировке на уровне строки и транзакционности.
У InnoDB есть одно главное преимущество – скорость работы. Делая запрос в базу InnoDB, блокируется только строка, в отличие от MyISAM, где происходит блокировка целой таблицы. Получается так, что пока запрос не выполнится, то никакие другие обращения к таблице или строке будут не осуществимы. Так как строки по объему меньше таблиц, то InnoDB справляется с поставленными задачами лучше.
Помимо всего вышеперечисленного была осуществлена оптимизация работы базы данных InnoDB. К примеру, оптимизации подверглись следующие параметры:
# InnoDB parameters
innodb_file_per_table
innodb_flush_log_at_trx_commit
innodb_flush_method
innodb_buffer_pool_size
innodb_log_file_size
innodb_buffer_pool_instances
innodb_file_format
innodb_locks_unsafe_for_binlog
innodb_autoinc_lock_mode
transaction-isolation
innodb-data-file-path
innodb_log_buffer_size
innodb_io_capacity
innodb_io_capacity_max
innodb_checksum_algorithm
innodb_read_io_threads
innodb_write_io_threads
Предварительные результаты
Благодаря выполнению шагов 1 и 2, количество одновременных соединений с веб-сервером уменьшилось, так как запросы и подключение к базе данных начали быстрее обрабатываться, что снизило нагрузку на оперативную память.
Шаг №3: Перенастройка Nginx и установка модулей кэширования brotli, pagespeed, proxy_buffering.
Nginx представляет собой быстрый и надежный сервер без лишних функций. Уже на протяжении длительного времени Nginx обслуживает таких российских IT-гигантов, как Яндекс, Рамблер и ВКонтакте. Nginx поддерживает буферизацию (proxy_buffering) и кеширование (proxy_cache), если использовать дополнительные сервера. Этим преимуществом мы и воспользовались.
Не обошлось и без казусов при настройке Nginx. У клиента обычный интернет-магазин товаров, но настройки буферизации, которые нам удалось найти во время аудита, могли сделать его стриминговым сервисом. При значительном уменьшении значения в client_max_body_size, это помогло нам уменьшить объем потребляемой памяти.
Шаг №4: Оптимизация настроек PHP-FPM и Memcache и отключение Apache.
PHP-FPM часто используют в паре с Nginx. Обработкой скриптов занимается PHP-FPM, а Nginx обрабатывает статистические данные. Это позволяет быстрее работать, чем модель Nginx + Apache.
У Apache скорость обработки запросов ниже. К примеру, Apache приходится постоянно считывать несколько конфигурационных файлов на сервере, при этом тратя время и ресурсы системы. По итогу, мы приняли решение отключить Apache, который только потреблял ресурсы, не принося никакой пользы.
Важным моментом стал перевод работы PHP-FPM на unix socket. Сделать это нужно было потому, что Nginx довольно быстрый веб-сервер, который не в состоянии самостоятельно обрабатывать скрипты. Для этого требуется бэкенд в виде PHP-FPM. Для того, чтобы данная связка работала без потери скорости, мы решили использовать unix socket. Это способ подключения к PHP-FPM, который позволяет исключать сетевые запросы и дает заметный прирост в скорости работы сайта.
Результаты работ
- Благодаря вышеперечисленным действиям, время отклика главной страницы снизилось с 24 секунд до 3, а внутренних – до 5.
- Потребление ресурсов сервера уменьшилось.
- Сервер стабилизировался – зависания прекратились.
- Увеличилась глубина просмотров на 30%, что смогло дать улучшение в SEO и в последующих продажах: рост поведенческих показателей → рост позиции сайта в выдаче → рост трафика → рост продаж.
- Для клиента были написаны рекомендации по оптимизации front-end части сайта для ускорения работы ресурса.
Например:
- Оптимизация графиков и настройка выдачи изображений в формате webp;
- Настройка lazyload – загрузки данных;
- Вынос всех некритических для отображения страницы скриптов в конец страницы.
Вывод
У нас удалось ускорить сайт и устранить проблемы с его загрузкой, не меняя код. Скорость сайта влияет на многие показатели: начиная удобством пользователей и оканчивая ранжированием сайта в поиске, что значительно сказывается на конверсии.
