/sites/default/files/2023-04/Office%20workers%20organizing%20data%20storage-small.jpg

На производительность сайта влияют не только качество кода и оптимизация контента — они могут не иметь смысла, если страдают настройки на сервере. 

Мы в Initlab давно занимаемся настройкой серверов и прекрасно знаем, как много это значит для производительности сайта. Чтобы доказать, насколько важно работать над оптимизацией конфигурации сервера, мы решили провести эксперимент, который наглядно покажет, как влияют настройки на скорость работы сайта и другие важные параметры.

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

Медленный сайт: чем поможет настройка MySQL?

Быстрый сайт важен по всем фронтам: продвижение, репутация, скорость бизнес-процессов и т.д. Многие зацикливаются только на оптимизации самого сайта: код почистить, файлы облегчить, вёрстку оптимизировать. Но как быть, если со всем этим порядок, а посетители сайта всё равно ждут критичные 3-5 секунд на каждой странице?

Дело может быть в настройке баз данных.

База данных (БД) — место хранения информации о товарах, пользователях сайта и т.д.

СУБД (система управления базами данных), в нашем случае MySQL — инструмент управления базой данных.

При установке на сервер MySQL нас встречает конфигурационный файл с параметрами «власти» базы данных по умолчанию: сколько памяти она может использовать, сколько кэша и т.д. Вообще этих параметров сотни, но здесь учтено около десятка. Этот базовый файл рассчитан на маленький сайт и на малый объём памяти.

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

Если конфигурацию оставить как есть или неправильно настроить, БД будет тупить и тормозить, а вместе с ней и сайт. 

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

Грамотная настройка ускорит работу веб-сайтов и веб-сервисов на любых CMS и CMF: Drupal, Laravel, Битрикс, Wordpress, Joomla — в основе любой из них лежат БД.

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

Наш эксперимент

Мы тестировали типовой интернет-магазин на Drupal 10 + Drupal Commerce Kickstart и магазин на Aimeos (Laravel). При этом никаких оптимизаций настроек самих интернет-магазинов не проводили, так как проверяли исключительно влияние настроек базы данных на их производительность. Для тех, кто разбирается в технических деталях и хочет подробностей — милости просим на англоязычный фулл. Здесь сжатая версия с основными цифрами для широкого круга читателей.

В качестве экспертов на это исследование нас пригласила команда сервиса Releem. Задача Releem — подобрать оптимальную конфигурацию для БД, как минимум лучше той, что идёт по умолчанию. Также этот сервис автоматически анализирует состояние MySQL, сервера, текущей нагрузки и может рекомендовать инженерам конфигурацию для увеличения производительности базы данных.

В этом эксперименте мы как раз показали, что базовая конфигурация «не вывозит» даже слабо заполненный товарами сайт. Вот какие показатели мы рассматривали:

Время ответа (задержка), он же time to first byte — время между отправкой запроса и его обработкой на сервере до момента получения клиентом первого байта. 

Количество запросов в секунду — сколько страниц веб-сервер может отдать клиенту в секунду.

Загрузка процессора. Мы собрали показатели загрузки процессора на сервере, чтобы сравнить рабочую нагрузку.

Тестирование мы проводили до и после настройки. Его суть в том, что на сайт как будто заходит условных 20 человек, которые начинают одновременно пользоваться сайтом. В этот момент измеряется его производительность. 

Результаты тестирования Aimeos Laravel

Тестирование показало значительное улучшение производительности между конфигурациями по умолчанию и настроенными с помощью Releem:

  • среднее время отклика сервера сократилось с 1,4 секунды до менее 800 миллисекунд;
  • время отклика (задержка) сократилось на 42%;
  • средняя загрузка процессора сократилась на 86%;
  • количество запросов в секунду увеличилось на невероятные 291% — с 12 до 35 запросов в секунду.

Объём базы данных при тестировании — 500 Мб.
Продолжительность теста — 10 минут.

Результаты тестирования Drupal Commerce Kickstart

Drupal прошел два раунда тестирования с БД разного размера.

База данных объемом 1 Гб

Тестирование показало заметные улучшения в задержке и загрузке ЦП при сравнении конфигурации по умолчанию с настроенной с помощью Releem:

  • среднее время отклика сервера сократилось со 150 миллисекунд до 60 миллисекунд;
  • время отклика (задержка) сократилось на 63% и оставалось очень стабильным с измененной конфигурацией;
  • загрузка ЦП была снижена на внушительные 63%;
  • количество запросов в секунду увеличилось на 2% — с 692 до 707 запросов.

База данных объемом 3 Гб

Ещё лучше результаты получились для базы данных объемом 3 Гб:

  • среднее время отклика сервера существенно снизилось: с 8 секунд до менее 200 миллисекунд;
  • время отклика (задержка) сократилось на 97% и оставалось очень стабильным с измененной конфигурацией;
  • загрузка ЦП также снизилась на 73%;
  • количество запросов в секунду увеличилось на 268% (!) — с 760 до 2040 запросов в секунду (хотя в варианте на 1 Гб разница была всего лишь в 2%).

Продолжительность теста — 10 минут для обоих БД.


Вот такие результаты у нас получились. Разумеется, где-то прирост оказался небольшим, а где-то фантастическим. Но наша изначальная гипотеза была не в достижении конкретных показателей. Мы хотели показать, что даже небольшая настройка параметров даёт значительный эффект. Не говоря уже о том, что все результаты можно отточить до совершенства руками опытных админов.

Заключение

Настройка MySQL однозначно даёт улучшение производительности, что мы и постарались вам продемонстрировать. 

Мы в Initlab знаем цену каждой секунде ожидания и делаем всё, чтобы взаимодействие с сайтами наших клиентов было максимально удобным и быстрым. Настройка MySQL гарантированно приносит пользу проектам, которые раньше вообще не заморачивались на этот счёт.

Если вам нужно проверить и провести апгрейд производительности базы данных MySQL под ваш проект, обращайтесь к нам.
 

Добавить комментарий