Ви потрапляєте в широкий, широкий світ оптимізації тут, і там, звичайно, не існує єдиного розміру, який підходить для всіх підходів.
Визначте продуктивність
Ви маєте на увазі час завантаження сторінки для одного користувача або загальну ємність / загальну сумісність? Два дуже різниться - і не є суто пов'язаними. Цілком можливо мати швидкий магазин з обмеженою місткістю; або повільний магазин з великою ємністю.
Отже, звертаючись до будь-якого типу продуктивності:
- Час завантаження сторінки одним користувачем
- Загальна потужність / одночасність
Ви повинні самостійно вирішувати власні рішення - тим більше, що у кожного є свої вузькі місця.
Давайте припустимо, що ви працюєте з компетентним хостом, який уже налаштував інші аспекти вашого сервера оптимально для вашого магазину.
Час завантаження сторінки одним користувачем
Чи є MySQL вузьким місцем.
Не безпосередньо. Все стосується затримки, в більшості випадків при тестуванні часу завантаження сторінки - потраплять лише кеші. Тому ключовим тут є мінімізація затримок.
- Налаштуйте розміри кешу MySQL відповідно (правильної відповіді немає, налаштування налаштовуються зовсім по-різному, щомісяця, у магазині)
- Зменшити затримку в мережі. Для 64-байтних кадрів; 51,2 мкс для 10 Мбіт / с, 5,12 мкс для 100 Мбіт / с і 4,096 мкс для 1 Гбіт / с. Це дає покращення на 20% лише за рахунок переходу від 100Mbps до 1Gbps. s1
- Збільшити ємність мережі. Ви були б здивовані тим, що багато мегабайт в секунду обмінюються між веб-сервером та сервером БД, як правило, перевищує 10 МБ / с - тому s1 потрібно як мінімум 100 Мбіт / с . Або просто перемістіть сервер БД локально.
- Використання 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 / Slave (понад 1000 замовлень на годину) - ми ніколи не вважали вимогою використовувати Master / Master у виробництві. Ми провели обширне тестування, але ніколи не виявили це вигідним з точки зору продуктивності та з притаманними йому ризиками та проблемами Майстра / Майстра, просто цього не варто.
Масштабування читання проти запису
Останній абзац дійсно веде до ключової області масштабування читання та запису. Масштабування читання може виконуватися досить нескінченно, не надто сильно ускладнюючи додавання все більшої кількості рабів.
Зважаючи на те, що коефіцієнт "Читання до писемності" Magento становить приблизно 0,1% - розгляд записів не повинен викликати особливих проблем. Ось чому я не переймався згадкою MySQL Cluster та його розумних функцій, таких як автоматичне загострення (розділення таблиць на окремі машини).
Апаратне, апаратне, апаратне забезпечення
Апаратне забезпечення - це найшвидша відповідь, коли йдеться про вдосконалення, тому я навмисно не згадував це вище в обох сценаріях.
Але всі зміни програмного забезпечення у світі не матимуть жодних значень, якщо базового обладнання не вистачає. Це може означати ...
- Неякісні комутатори з обмеженими буферами
- Надмірно насичені мережеві посилання
- Географічно віддалені сервери
- Погана мережа QoS / CoS
- Обмежений загальний об'єм оперативної пам'яті
- Оперативна пам'ять з низькою пропускною здатністю пам'яті
- Підсистема жорсткого диска з низьким рівнем ВОП
- Програмний RAID-контролер
- Процесор низької тактової частоти
- Чіпсет з низькою пропускною здатністю
- Віртуалізація обладнання (майже всі типи, крім віртуалізації ядра)
На сьогоднішній день існує дійсно висока стеля щодо того, наскільки високою можна фактично масштабувати обладнання. Дозволяє ігнорувати міф про нескінченне масштабування "у хмарі", оскільки хмарна апаратура має тенденцію бути досить посередньою. Наприклад, флагманські моделі Amazon мають лише 12 ядер при 3,3 ГГц. Але поза цим є кілька дуже потужних серверів - наш верхній сервер має 160 ядер та 2 ТБ (так, терабайт) оперативної пам’яті. Ми ще не бачили, щоб хтось перевищував можливості цього.
Таким чином, у вас є масштабна сфера вертикального масштабування, перш ніж вам навіть потрібно буде розглянути питання про горизонтальне масштабування.
Завжди рухається ціль
Варто зазначити, що в гонитві за виконанням, вузьке місце завжди буде рухатися.
Для акцій магазину Magento.
Увімкніть кеші. PHP - це вузьке місце
Додавання резервного кешу. PHP - це вузьке місце
Додавання кешу на повну сторінку на рівні програми. PHP - це вузьке місце
Додавання кеша на рівні сервера (наприклад, лак). 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 ГБ жорсткого диска: 4x 80 к IOP / с SSD диски
RAID: апаратний RAID 10
Magento версія: Magento EE
ОС: MageStack
Протягом усього часу середнє навантаження залишалось менше 3,00.
Приклад 2 - 180 замовлень на годину
Буквально два дні тому новий наш клієнт легко намочив великий стрибок руху. Обробка 180 замовлень на годину за допомогою одного сервера та Magento Community Edition .
1 серверний
процесор: 2x
оперативної пам'яті Intel E5-4620 : 64 ГБ жорсткого диска: 4x 80 к IOP / с SSD диски
RAID: апаратний RAID 10
Magento Версія: Magento CE
ОС: MageStack
Веб-сайт: Wellgosh.com
Протягом усього часу середнє навантаження залишалось менше 6.00. Навантаження в цьому сценарії було вищою, і це зменшилося до декількох факторів.
- Настроювання на стороні магазину не проводилось, як у Прикладі 1
- Відсутність FPC на рівні додатків
І з огляду на це, ми все ще отримали детальну статистику, щоб дати відгуки за допомогою графіків. Вони розповідають про відмінну історію розподілу навантаження між ключовими компонентами відокремленої архітектури Magento (балансир завантаження, веб-сервер, db-сервер тощо - за допомогою MageStack ).
Отже, спереду та назад ... дата, яку ви хочете подивитися, - о 12:00 22 лютого.
Пакети брандмауера
Лакувати трафік
Nginx трафік
Завантаження MySQL
Навантаження процесора
І найголовніше - розподіл навантаження
Цей образ справді все це говорить. І це те, що MySQL, безумовно, не є тягарем - ще не принаймні. Тож наші поради, зосередьтесь на важливості вашої роботи в іншому місці, якщо ви не обробляєте більше декількох тисяч замовлень на годину.
І в підсумку
Внесення змін до продуктивності - це "не один розмір". Це випадок аналізу ваших поточних вузьких місць та внесення тонких змін / коригувань відповідно до вашого магазину та інфраструктури.
Але продуктивність осторонь, є й інші переваги використання Percona
Ми використовуємо Percona XtraDB майже виключно. Ми запускаємо спеціально складені збірки MySQL, розроблені спеціально для Magento, і під час цього процесу консультувалися з Percona. Але це не просто ефективність вплинула на цей вибір.
- Інструментарій Percona
- pt-дайджест запитів
- xtrabackup
- тощо.
- Частота вивільнення Percona
- Консультативна підтримка Percona
- Теплий кеш перезапускається із збереженням пулу InnoDB
І багато іншого. Тому використання його через MySQL мало інші переваги, ніж просто продуктивність. Насправді - MySQL є і завжди був найменшим занепокоєнням у справі працездатності та стабільності.
Атрибути: wellgosh.com , sonassi.com , iebmedia.com .