Как ускорить сайт в 4 раза, просто перенастроив сервер

Если вы работаете с сайтом, который постепенно растет, - увеличивается количество товаров, трафик с рекламы - то рано или поздно придется перейти в режим работы highload, высоких нагрузок на сервер. Но что делать, если ваш сайт не растет, а сервер все чаще не выдерживает, и происходит блокировка данных? Именно с этой проблемой мы столкнулись, дорабатывая сайт для интернет-магазина светового оборудования с ассортиментом более чем 100 000 товаров.

Как ускорить сайт в 4 раза, просто перенастроив сервер

Исходная ситуация

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

Поиск проблемы

Мы провели аудит настроек сервера и сайта, разделив работы на два этапа: анализ 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 количество одновременных соединений с веб-сервером уменьшилось, так как запросы к базе данных и подключение к ней стали обрабатываться быстрее.

Как ускорить сайт в 4 раза, просто перенастроив сервер

Это в свою очередь привело к уменьшению потребляемой оперативной памяти.

Как ускорить сайт в 4 раза, просто перенастроив сервер

Шаг 3. Перенастройка Nginx и установка модулей кэширования brotli, pagespeed, proxy_buffering

Nginx позиционируется как простой, быстрый и надежный сервер, неперегруженный функциями. Уже длительное время Nginx обслуживает серверы многих высоконагруженных российских сайтов, например, Яндекс, Mail.Ru, ВКонтакте и Рамблер. Для улучшения производительности при использовании дополнительных серверов, Nginx поддерживает буферизацию (proxy_buffering) и кеширование (proxy_cache), чем мы и воспользовались.

Не обошлось и без курьезов настроек Nginx. У клиента был обычный интернет-магазин с товарами, тогда как настройки буферизации, которые мы обнаружили во время аудита, позволяли ему быть чуть ли ни стриминговым сервисом. Мы существенно уменьшили значения в параметре client_max_body_size, что в совокупности с перенастройкой Nginx еще больше снизило потребление памяти.

Как ускорить сайт в 4 раза, просто перенастроив сервер

Шаг 4. Оптимизация настроек PHP-FPM и Memcache и отключение Apache

PHP-FPM нередко используется в паре с веб-сервером Nginx. Последний обрабатывает статические данные, а обработку скриптов отдает PHP-FPM. Такая реализация работает быстрее, чем распространенная модель Nginx + Apache.

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

Необходимым шагом стал перевод работы PHP-FPM на unix socket. Зачем это понадобилось? Nginx сам по себе довольно быстрый веб-сервер, однако самостоятельно он не может обрабатывать скрипты. Для этого необходим бэкенд в виде PHP-FPM. Чтобы вся эта связка работала без потери скорости, мы использовали unix socket – способ подключения к PHP-FPM, позволяющий избегать сетевые запросы и дающий значительный прирост в скорости работы сайта.

Результаты работ

1. Время отклика главной страницы уменьшилось с 24 секунд до чуть более 3 секунд, внутренних до 5-8 сек.

Как ускорить сайт в 4 раза, просто перенастроив сервер

2. Уменьшилось потребление серверных ресурсов.

Как ускорить сайт в 4 раза, просто перенастроив сервер

3. Стабилизировалось поведение сервера - он перестал зависать.

4. Глубина просмотров увеличилась на 30%, и как следствие, это дало улучшение в SЕО, а также последующих продаж: растут поведенческие показатели => растут позиции сайта в выдаче => растет трафик => растут продажи.

5. Клиенту были даны рекомендации по оптимизации front-end части сайта для ускорения работы сайта. Например:

  • оптимизировать графики и настройку выдачи изображений в формате webp;
  • настроить lazyload-загрузки данных;
  • вынести все некритические для отображения страницы скрипты в конец страницы.

Вывод

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

55
7 комментариев

Про innodb написана немного хрень, этот тип таблиц даст прирост скорости вывода данных, по сравнению с myisam, в том случае, если данные часто меняются. Myisam блокирует всю таблицу во время изменения строк, но не во время вывода. В интернет магазине навряд ли часто изменяются данные в тех таблицах, откуда они наиболее часто выводятся. Правда и недостатков у перехода на innodb не много, только увеличение занимаемого места на диске в два раза.

Время отклика страницы это именно время генерации php (в данном случае) кода, а затем еще идет загрузка всех ресурсов и отрисовка фронтенда. В наше время обычно время отклика сайта должно быть 0,1 секунды и меньше. Кое-как может жить сайт с временем отклика до секунды. Если на подопытном сайте время отклика было 24 секунды... то просмотров там могло быть от силы десятки в день. Никто сейчас не сидит по 30 секунд перед белым полотном в ожидании хоть какой-то реакции сайта. Поэтому скорее всего вы говорите о времени полной загрузки страницы, но тогда перечисленные работы не могли дать такой эффект без других оптимизаций, как раз перечисленных в списке про фронтэнд.

Пожалуйста, подключайте к написанию технических статей - технических специалистов. Зачастую одно слово, которое обозначает «вроде бы то же самое», на самом деле меняет весь смысл статьи или ее части, превращая его в бессмыслицу.

12
Ответить

MyISAM уже давно deprecated, на текущий момент нет ни одной причины для использования этого движка. Даже на самом MySQL отказались от использования этого движка для системных таблиц, он медленный и ненадежный. То что MyIsam быстрее innodb давно миф. При правильной настройке InnoDb будет давать прирост производительности не только за счет вставок, но и за счет более оптимальных сортировок, и прочей кучи оптимизаций которые продолжают добавлять в innodb/extradb. MyISAM имеет тенденцию крэшится без возможности восстановления при средней нагрузке и количестве данных от миллиона строк.

Innodb обеспечивает ACID, более качественную и производительную структуру хранения индексов в tablespace,  оптимальную работу с индексами на уровне оптимизатора запросов. Кластеризованные индексы, которые значительно ускоряют работу по primary key. Автоматическое восстановление после crash. И много других преимуществ.

То что ребята написали про тюнинг изоляции транзакций очень странно, очевидно их нет в проекте и все идет автокоммитом.

1
Ответить

Комментарий недоступен

8
Ответить

Комментарий недоступен

2
Ответить

В InnoDB данные хранятся в больших совместно используемых файлах, в отличие от используемого прежде MyISAM, где для каждой конкретной таблицы создается отдельный файл данных.

Эммм,  но вы же ниже написали - innodb_file_per_table
Этот параметр отвечает за хранение таблиц в отдельных файлах в Innodb :)
А в последних версиях MySQL он включен по умолчанию.

посмотрите /var/lib/mysql.

2
Ответить

Молодцы! Понаблюдайте за ответом сервера, где лежит ваш сайт. Есть скачки до неприятных значений. По динамике месяца к месяцу тренд не очень хороший. Данные из CrUX.

1
Ответить

Напрашивается как минимум еще SSI, которая позволит генерировать блоки страницы параллельно. 

1
Ответить