Здесь вы попадаете в широкий, широкий мир оптимизации, и, конечно, не существует единого подхода, подходящего для всех.
Определить производительность
Вы имеете в виду время загрузки страницы для одного пользователя или общую емкость / общий параллелизм? Эти два совершенно разные - и не строго связаны. Вполне возможно иметь быстрый магазин с ограниченной емкостью; или медленный магазин с большой емкостью.
Поэтому при рассмотрении любого типа производительности:
- Время загрузки страницы воспринимается одним пользователем
- Общая емкость / параллелизм
Вы должны справиться с каждым независимо со своими собственными решениями - тем более что у каждого есть свои узкие места.
Давайте предположим, что вы работаете с компетентным хостом, который уже настроил другие аспекты вашего сервера оптимально для вашего магазина.
Время загрузки страницы воспринимается одним пользователем
Является ли MySQL узким местом
Нет. Не напрямую. Все дело в задержке, в большинстве случаев при тестировании времени загрузки страницы - только кеши будут поражены. Таким образом, ключ здесь заключается в том, чтобы минимизировать задержки.
- Настройте размеры кэша MySQL соответствующим образом (нет правильного ответа, мы настраиваем настройки совершенно по-разному, ежемесячно, для магазина)
- Уменьшите задержку сети. Для 64-байтовых кадров; 51,2 мкс для 10 Мбит / с, 5,12 мкс для 100 Мбит / с и 4,096 мкс для 1 Гбит / с. Это дает улучшение на 20% только путем перехода от 100 Мбит / с к 1 Гбит / с. s1
- Увеличьте емкость сети. Вы будете удивлены тем, как много мегабайт в секунду обмениваются между сервером Web и БД, обычно превышающим 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 замедляет работу. Если у вас правильно сконфигурированы Varnish и 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 / Master. Из-за довольно высокой точки перелома аппаратного насыщения установки Master / Slave (более 1000 заказов в час) - мы никогда не считали необходимым использование Master / Master в производстве. Мы провели обширное тестирование, но никогда не находили его выгодным с точки зрения производительности, и, учитывая риски и проблемы, присущие Мастеру / Мастеру, оно просто не стоит.
Масштабирование чтения и записи
Последний абзац действительно ведет к ключевой области масштабируемости чтения и записи. Масштабирование чтения может выполняться довольно бесконечно без особых сложностей с добавлением все большего количества рабов.
Учитывая, что соотношение чтений к письмам у Magento составляет около 0,1%, учитывая, что записи не должны вызывать беспокойства. Вот почему я не потрудился упомянуть MySQL Cluster и его умные функции, такие как автоматическое разделение (разделение таблиц на отдельные машины).
Аппаратное, аппаратное, аппаратное обеспечение
Аппаратное обеспечение - это самый быстрый ответ, когда дело доходит до улучшения, поэтому я сознательно не упомянул об этом выше в обоих сценариях.
Но все изменения программного обеспечения в мире не будут иметь никакого значения, если базового оборудования недостаточно. Это может означать ...
- Низкокачественные коммутаторы с ограниченными буферами
- Слишком насыщенные сетевые ссылки
- Географически удаленные серверы
- Плохая сеть QoS / CoS
- Ограниченный общий объем оперативной памяти
- ОЗУ с низкой пропускной способностью памяти
- Подсистема HDD с низким IOP
- Программный RAID-контроллер
- Низкая тактовая частота процессора
- Чипсет с низкой пропускной способностью
- Аппаратная виртуализация (почти все типы, кроме виртуализации на уровне ядра)
В настоящее время существует очень высокий потолок того, насколько высоко вы можете масштабировать оборудование. Давайте проигнорируем миф о бесконечном масштабировании «в облаке», поскольку облачное оборудование имеет тенденцию быть довольно посредственным. Например, у флагманских моделей Amazon всего 12 ядер при 3,3 ГГц. Но помимо этого есть несколько очень мощных серверов - наш топ-сервер имеет 160 ядер и 2 ТБ (да, терабайта) оперативной памяти. Мы еще не видели, чтобы кто-то превосходил возможности этого.
Таким образом, у вас есть широкие возможности для вертикального масштабирования, прежде чем вам даже нужно будет рассмотреть горизонтальное масштабирование.
Вечно движущаяся цель
Стоит отметить, что в погоне за производительностью узкое место всегда будет двигаться.
Для стокового магазина Magento.
Включите тайники. Узким местом является PHP.
Добавьте кеш сервера. Узким местом является PHP.
Добавьте кеш страницы на уровне приложения. Узким местом является PHP.
Добавьте кеш на уровне сервера (например, Varnish). Узкое место в MySQL
Добавьте альтернативный поисковый / многоуровневый механизм навигации (например, SOLR / Sphinx). Узким местом является PHP.
Добавьте больше серверов приложений. Узкое место
- MySQL. Добавьте подчиненный MySQL. Внешнее кэширование является узким местом.
Добавьте больше серверов внешнего кэширования. Узким местом является PHP.
Добавьте больше серверов приложений. SOLR / Sphinx является узким местом
Etcetera.
Это в значительной степени превращается в случай повторного полоскания. Но ясно, что MySQL определенно не является первым портом вызова для оптимизации - и действительно вступает в игру только тогда, когда MySQL потребляет больше ресурсов процессора пропорционально PHP - и это ТОЛЬКО когда-либо происходит, когда используются FPC и Varnish. и сервер (ы) просто обрабатывают заказы и ничего больше (потому что все остальное находится в кеше).
Не вносите изменения вслепую
Простое добавление ведомого MySQL, потому что вы читаете выше, говорят, что это поможет, может стоить вам производительности и надежности на огромном уровне. Переполненная сеть, подчиненный сервер с низкой спецификацией или даже неправильные настройки могут вызвать проблемы с репликацией, которые могут сделать ваш магазин медленнее, чем это было с самого начала, или вызвать проблемы синхронизации между ведущим и ведомым.
Чтобы положить вещи в перспективе - некоторые примеры из реального мира.
Пример 1 - 300 заказов в час
Мы использовали следующее оборудование для обслуживания 300 заказов в час ; и только в этот переломный момент - тогда мы почувствовали необходимость добавить выделенный сервер MySQL и локальный подчиненный MySQL.
1 Сервер
ЦП: 2x Intel E5-4620
ОЗУ: 64 ГБ HDD: 4x 80k IOP / s SSDs
RAID: Аппаратный RAID 10
Magento Версия: Magento EE
ОС: MageStack
В течение всего времени средние нагрузки оставались ниже 3,00.
Пример 2 - 180 заказов в час
Всего два дня назад наш новый клиент легко впитал большой всплеск трафика. Обработка 180 заказов в час с одним сервером и Magento Community Edition .
1 Сервер
ЦП: 2x Intel E5-4620
ОЗУ: 64 ГБ HDD: 4x 80k IOP / s SSDs
RAID: Аппаратный RAID 10
Magento Версия: Magento CE
ОС: MageStack
Веб-сайт: Wellgosh.com
В течение всего времени средние нагрузки оставались ниже 6,00. В этом сценарии нагрузка была выше, и это было связано с несколькими факторами.
- Настройка магазина не была выполнена, как в примере 1
- Отсутствие FPC уровня приложения
И учитывая недавнюю ситуацию, у нас все еще есть подробная статистика, чтобы дать некоторую обратную связь с помощью графиков. Они отлично рассказывают о том, как распределяется нагрузка между ключевыми компонентами отдельной архитектуры Magento (балансировщик нагрузки, веб-сервер, сервер БД и т. Д. - с использованием MageStack ).
Итак, спереди назад ... дата, на которую вы хотите посмотреть, - в 12:00 22 февраля.
Пакеты межсетевого экрана
Лак Трафик
Nginx Traffic
MySQL Load
Загрузка процессора
И самое главное, распределение нагрузки
Это изображение действительно говорит обо всем. И это то, что MySQL, конечно, не является бременем - по крайней мере, пока. Так что наш совет, сфокусируйте свои проблемы с производительностью в другом месте, если только вы не обрабатываете более нескольких тысяч заказов в час.
И в заключение
Внесение изменений в производительность не "один размер подходит всем". Это случай анализа ваших текущих узких мест и тонких изменений / корректировок в соответствии с вашим магазином и инфраструктурой.
Но помимо производительности, есть и другие преимущества использования Percona.
Мы используем Percona XtraDB, почти исключительно. Мы запускаем специально скомпилированные сборки MySQL, которые мы разработали специально для Magento и консультировались с Percona в ходе этого процесса. Но не только производительность повлияла на этот выбор.
- Percona Toolkit
- PT-запрос-дайджест
- XtraBackup
- и т.п.
- Частота выпусков Percona
- Percona консультативная поддержка
- Теплый кэш перезапускается с сохранением пула InnoDB
И многое другое. Таким образом, использование его над MySQL имело и другие преимущества, помимо производительности. Фактически, MySQL является и всегда был наименьшим из наших беспокойств в стремлении к производительности и стабильности.
Атрибуты: wellgosh.com , sonassi.com , iebmedia.com .