Какой сервер MySQL обеспечивает лучшую производительность для Magento

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

Определение производительности

Вы имеете в виду время загрузки страницы для одного пользователя или общую пропускную способность/общий параллелизм? Эти два очень сильно отличаются друг от друга - и не связаны строго. Вполне возможно иметь быстрый магазин с ограниченной емкостью или медленный магазин с большой емкостью.

Поэтому при обращении к любому типу производительность:

1. Время загрузки страницы, воспринимаемое одним пользователем
2. Общая пропускная способность/параллелизм

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

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

Время загрузки страницы, воспринимаемое одним пользователем

Является ли MySQL узкое место
Нет, не напрямую. Все дело в задержке, в большинстве случаев при тестировании времени загрузки страницы будут поражены только кэши. Таким образом, ключ здесь в том, чтобы минимизировать задержку.

• Настройка размеров кэша MySQL соответствующим образом ( правильного ответа нет, мы настраиваем настройки совершенно по-разному, ежемесячно, для каждого магазина)
• Уменьшите задержку в сети. Для 64-байтовых кадров; 51,2 мкс для 10 Мбит/с, 5,12 мкс для 100 Мбит/с и 4,096 мкс для 1 Гбит/с. Это дает улучшение на 20 % просто за счет перехода со 100 Мбит/с на 1 Гбит/с. ^s1
• Увеличьте пропускную способность сети. Вы были бы удивлены, узнав, сколько мегабайт в секунду обменивается между веб-сервером и сервером БД, обычно более 10 Мбит/с, поэтому требуется минимум 100 Мбит/с^s1. Или просто переместите сервер БД локально.
• Используя SOLR. Внешние движки иногда подходят лучше, SOLR, безусловно, быстрее для БОЛЬШИХ каталогов (и я бы подчеркнул, большие каталоги). Даже не настроенный SOLR будет выдавать многоуровневую навигацию и результаты поиска быстрее, чем MySQL.

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

• Настройте приложение. В Magento есть несколько довольно серьезных ошибок в том, как он создает коллекции и кэширует их; мы столкнулись с рядом серьезных проблем с основным кодом, которые могут снизить производительность. В нескольких случаях, простое удаление отображения количества продуктов в результатах многоуровневой навигации сэкономило 2 секунды загрузки большой коллекции.
• Просмотрите медленные журналы MySQL. Проверьте медленные запросы и добавьте индексы по мере необходимости. Разница между выполнением сложного запроса с несколькими соединениями с соответствующими индексами и без них может составлять десятки секунд.

Приложение является узким местом. Не программное обеспечение. Так что просто улучшите основной код или сделайте ваш шаблон менее тяжелым окажет гораздо более сильное влияние на производительность, чем ЛЮБОЙ Изменение конфигурации MySQL.

С чем бы мы не стали возиться

• Изменение механизма хранения. MariaDB и Percona используют один и тот же движок InnoDB - Percona XtraDB. Их можно рассматривать как одно и то же. С точки зрения времени выполнения одного запроса - производительность будет точно отражать сборку ванильного MySQL. Это вступает в игру при нагрузке/параллелизме.
• Запуск Подчиненный MySQL. Это не улучшит производительность, если ведомое устройство не расположено физически ближе (с точки зрения сети) или если у ведомого устройства лучшее оборудование, чем у ведущего. Это вступает в игру при нагрузке/параллелизме.
• Запуск внешнего сервера БД. Это, безусловно, худший совет, который мы видим неоднократно, раздаваемый многими хостингами/агентствами. Пока вы не достигнете потолка в оборудовании/ресурсах или у вас не будет нескольких веб-серверов (читай: высокая доступность), MySQL на локальном машина для магазина Magento - Хорошая идея. Это сокращает все сетевые издержки и задержки. Даже сеть со скоростью 100 Гб/с (да, сто гигабит в секунду) не будет сравняться с локальным сокетом unix по объему, пропускной способности и задержке.

^s1 Только для отдельных серверов баз данных. Не применяется к локальным серверам БД.

Общая пропускная способность/параллелизм

Является ли MySQL узким местом
Может быть. Но только после того, как вы прибьете свой PHP производительность и емкость до такой степени, что MySQL замедляет работу. Если у вас правильно настроен лак и FPC ( не заставляйте нас начинать с того, сколько неудачных попыток мы видели с любым из них) - тогда MySQL действительно становится узким местом.

Таким образом, в дополнение к вышеуказанным модификациям.

• Измените движок MySQL. XtraDB может преуспевать под нагрузкой и действительно демонстрирует реальные преимущества по сравнению с обычным дистрибутивом MySQL.
• Будьте в курсе событий с MySQL.5.5 работает лучше, чем 5.0 под нагрузкой.
• Измените драйвер PHP MySQL. PHP 5.3 и новее имеет собственный драйвер MySQL, но в некоторых случаях мы нашли PHP 5.2 с отдельным драйвером, который превосходит MySQLND для Magento. Проверьте это сами
• Изменить поисковую систему. Перенос поиска на SOLR/Sphinx (или даже некоторые сторонние внешние сервисы) действительно может облегчить бремя нетранзакционной нагрузки (т.Е. Люди, не размещающие заказы)
• Изменение уровня навигационный движок. Опять же, SOLR - это блестящий движок для многоуровневой навигации, и благодаря своей неблокирующей природе он намного быстрее, чем MySQL.
• Добавьте подчиненное устройство MySQL. Это помогает просматривать (нетранзакционную) загрузку, но не поможет вам обрабатывать больше заказов в час, поскольку обработка и репликация этих данных зависит от Мастера

С чем бы мы не стали возиться

• Мастер/Мастер. Из-за довольно высокой переломной точки насыщения аппаратным обеспечением настройки Master/Slave (более 1000 заказов в час) - мы никогда не считали необходимым использовать Master/Master в производстве. Мы провели обширное тестирование, но так и не нашли его выгодным с точки зрения производительности, а с учетом присущих Мастеру рисков и проблем, это просто не стоит того.

Масштабируемость чтения и записи

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

Учитывая, что соотношение операций чтения и записи в Magento составляет около 0,1%, учитывая, что операции записи не должны вызывать особого беспокойства. Вот почему я не удосужился упомянуть MySQL Cluster и его умные функции, такие как автоматическое сегментирование (разделение таблиц на отдельные машины).

Оборудование, оборудование, оборудование

Аппаратное обеспечение - это самый быстрый ответ, когда дело доходит до улучшения, поэтому я намеренно не упоминал об этом выше в обоих сценариях.

Но все изменения программного обеспечения в мире не будут иметь никакого значения, если вашего базового оборудования недостаточно. Это может означать...

• Коммутаторы низкого качества с ограниченными буферами
• Чрезмерно насыщенные сетевые связи
• Географически удаленные серверы
• Плохое качество обслуживания сети/CoS
• Ограниченный общий объем оперативной памяти
• Оперативная память с низкой пропускной способностью
• Жесткий диск с низким IOPs подсистема
• Программный RAID-контроллер
• Процессор с низкой тактовой частотой
• Чипсет с низкой пропускной способностью
• Аппаратная виртуализация (почти все типы, кроме виртуализации на уровне ядра)

В настоящее время существует действительно высокий потолок того, насколько высоко вы можете масштабироваться на оборудовании. Давайте проигнорируем миф о бесконечном масштабировании "в облаке", поскольку облачное оборудование, как правило, довольно посредственное. Например, флагманские модели Amazon имеют только 12 ядер при частоте 3,3 ГГц. Но за пределами это, есть несколько очень мощных доступных серверов - наш лучший сервер имеет 160 ядер и 2 ТБ (да, терабайт) оперативной памяти. Мы еще не видели, чтобы кто-то превышал возможности этого..

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

Постоянно движущаяся цель

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

Для биржевого Magento магазин.

Включите кэш. PHP является узким местом
Добавьте внутренний кэш. PHP является узким местом
Добавьте кэш полной страницы на уровне приложения. PHP является узким местом
Добавьте внешний кэш на уровне сервера (например. Лак). MySQL является узким местом
Добавьте альтернативный механизм поиска/многоуровневой навигации (например. СОЛР/Сфинкс). PHP является узким местом
Добавьте дополнительные серверы приложений. MySQL является узким местом
Добавить подчиненный MySQL. Внешний кэш является узким местом
Добавьте дополнительные серверы кэширования переднего плана. PHP является узким местом
Добавьте дополнительные серверы приложений. SOLR/Сфинкс - это узкое место

И Так Далее.

Это в значительной степени становится случаем повторения полоскания. Но что ясно понять, так это то, что MySQL, безусловно, не является первым портом вызова для оптимизации - и действительно вступает в игру только тогда, когда MySQL потребляет больше процессора пропорционально PHP - и это происходит только тогда, когда используются как FPC, так и Varnish, а сервер(ы) просто обрабатывает заказы и ничего больше (потому что все остальное находится в кэшах).

Не вносите изменения вслепую

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

Чтобы представить вещи в перспективе - несколько примеров из реального мира.

Пример 1 - 300 заказов в час

Мы использовали следующее оборудование для обслуживания 300 заказов в час ; и только в этот переломный момент мы почувствовали необходимость добавить выделенный сервер MySQL и локальный подчиненный сервер MySQL.

1 Сервер
Процессор: 2x Intel E5-4620
ОПЕРАТИВНАЯ ПАМЯТЬ: 64 ГБ Жесткий диск: 4x 80k Твердотельные накопители IOP/s
RAID: Аппаратный RAID 10
Версия Magento: Magento EE
Операционная система: Magestack

В течение всего времени средние значения нагрузки оставались ниже 3,00.

Пример 2 - 180 заказов в час

Всего два дня назад наш новый клиент легко справился с большим всплеском трафика. Обработка 180 заказов в час с помощью одного сервера и Издания сообщества Magento.

1 Сервер
Процессор: 2x Intel E5-4620
ОПЕРАТИВНАЯ ПАМЯТЬ: 64 ГБ Жесткий диск: 4x 80k ВГД/с твердотельные накопители
RAID: Аппаратный RAID 10
Версия Magento: Magento CE
Операционная система: Magestack
Веб-сайт: Wellgosh.com

В течение всего времени средние значения нагрузки оставались ниже 6.00. В этом сценарии нагрузка была выше, и это объяснялось несколькими факторами.

1. Настройка на стороне магазина не выполнялась, как в примере 1
2. Отсутствие FPC на уровне приложений

И, учитывая недавность этого, у нас все еще есть подробная статистика, чтобы дать некоторую обратную связь с помощью графиков. Они рассказывают отличную историю о том, как нагрузка распределяется между ключевыми компонентами отдельной архитектуры Magento (балансировщик нагрузки, веб-сервер, сервер бд и т. Д. - С использованием Magestack).

Итак, спереди назад... дата, на которую вы хотите посмотреть, - 12:00 22 февраля.

Пакеты брандмауэра

Лак Трафик

Трафик Nginx

Загрузка MySQL

Загрузка процессора

И самое главное, распределение нагрузки

Это изображение действительно говорит обо всем. И это то, что MySQL, безусловно, не является бременем - по крайней мере, пока. Поэтому наш совет: сосредоточьте свои проблемы с производительностью в другом месте, если вы не обрабатываете более нескольких тысяч заказов в год. час.

И вкратце

Внесение изменений в производительность - это не "один размер для всех". Это случай анализа ваших текущих узких мест и внесения незначительных изменений/корректировок в соответствии с вашим магазином и инфраструктурой.

Но помимо производительности, есть и другие преимущества использования Percona

Мы используем Percona XtraDB почти исключительно. Мы запускаем специально скомпилированные сборки MySQL, которые мы разработали специально для Magento и проконсультировались с Перкона во время процесса. Но на этот выбор повлияла не только производительность.

• Инструментарий Percona
  • pt-запрос-дайджест
  • xtrabackup
  • и т.д.
• Частота выпуска Percona
• Консультативная поддержка Перконы
• Теплый кэш перезапускается с сохранением пула InnoDB

И многое другое. Таким образом, использование его через MySQL имело другие преимущества, кроме просто производительности. На самом деле - MySQL есть и всегда был меньше всего нас беспокоит стремление к производительности и стабильности.

Атрибуции: wellgosh.com, sonassi.com, iebmedia.com.