Наразі ми працюємо з вимогою, щоб перша відповідь веб-сервера повинна надійти менше ніж 200 мс у Великобританії. Наразі під 2 спеціалізованими веб-серверами під балансиром навантаження та на 1 db-сервер ми заходить у 800 мс.

На даний момент на сайті є менше 5 клієнтів, 2 товари, 4 категорії, на даний момент немає інтерфейсу до сайту, він стильний і без зображення.

Він також запускається на nginx за допомогою Varnish.

Хтось може дати мені поради щодо налаштування веб-сервера? Чому наше поступає повільно? Що ви можете порекомендувати для оптимізації цього? Потрібно швидше на 400%!

Я кусаю.

Перша відповідь від веб-сервера повинна надійти менше ніж 200 мс у Великобританії.
На даний момент немає інтерфейсу до сайту, він є стильним і без зображення.

Ви не зможете досягти цих цифр без допомоги ні лаку, ні FPC (або обох). Я, безумовно, сподіваюся, що ця цифра також не повинна містити статичний вміст (коли ви вирішите додати його) - як його майже неможливо досягти (окрім того, що мало зображень / js / css).

Ми заїжджаємо в 800 мс.
Він також працює на Nginx разом з лаком

Ви неправильно налаштували Varnish.

Правильно налаштована установка Varnish забезпечить <100ms час завантаження сторінки (ми бачимо ближче до <10ms).

Насправді, для Magento, ви повинні сподіватися побачити щось подібне,

Коли клієнт не входить у систему ...
Т.е. Не створивши унікальний сеанс (додавання до кошика / списку бажань, вхід у систему тощо)

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

Коли клієнт входить у систему ...
Т.е. Створивши унікальний сеанс (увійшов у систему, елементи у кошику тощо). У цей момент Варніш, швидше за все, не буде. І якщо ви вирішили використовувати ESI - залежно від зворотних дзвінків, він може або підтримувати схожий час завантаження сторінки, як кеш FPC (через накладні витрати завантажувача) - або фактично збільшувати час завантаження сторінки, крім того, що вони не зберігаються.

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache   

Це не справа тюнінгу лаку, а справа - "ви насправді нічого не кешуєте" .

Ідеальні файли конфігурації сервера Magento

Існує не один, ну, не зовсім.

Ми працюємо понад 400 серверів, у всіх магазинах Magento - різного розміру та потужності. І рідко буває, що файли конфігурації, які ми маємо на одному - відповідатимуть іншим. Це тому, що не всі підприємства схожі.

Вузькі пляшки можуть утворюватися через багато різних причин:

1. Висока кількість одночасності відвідувачів, з активними сеансами
2. Жертви "поганих" повзають ботів, створюючи необхідне, неоціненне навантаження
3. Висока частка багатошарових навігаційних хітів
4. Висока кількість пошукових запитів
5. Високий обсяг транзакцій за годину
6. Погано побудований шаблон
7. Занадто багато / повільних / об'ємних сторонніх розширень
8. Застарілі вхідні посилання призводять до високої частки 404 звернень
9. Ємність мережевого інтерфейсу обмежена
10. Великий / складний каталог (багато товарів / категорій / атрибутів)

Тож у магазинах у всьому цьому спектрі кожен має різний підхід до отримання оптимальної продуктивності.

Вирішити питання, викладені вище; ми навмисно уникатимемо просто заявляти "більше / краще обладнання"

1. Використовуйте FPC за межами лаку
2. Відфільтруйте / заблокуйте погані боти на межі мережі - або переадресуйте всі запити до лаку незалежно від стану / URL-файлу cookie
3. Змініть багатошарову навігацію на запас на SOLR, зробіть залежними шаруваті навігаційні фільтри
4. Змінити пошук акцій на SOLR
5. Розподіліть завантаження MySQL в конфігурації Master / Slave - робіть це лише тоді, коли ви гарантовано завантажуєте веб-переглядач Varnish / FPC
6. Повторно складіть шаблон
7. Роздягніть їх
8. Контролюйте журнали доступу постійно та переписуйте URL-адреси на Nginx / Varnish перед доставкою. Якщо ви робите це на рівні Nginx - переконайтеся, що Varnish кешує 301/302 переадресацій.
9. Розділити статичний вміст на CDN або покращити зв’язок
10. Додайте більше апаратного забезпечення (ну, ми повинні були це сказати в якийсь момент)

Отже, маючи це на увазі - ви побачите, що, ймовірно, не буде конфігураційного файлу Nginx, конфігураційного файлу пулу PHP fcgi, конфігураційного файлу MySQL або файлу конфігурації Varnish, який буде однаковим. Пару, що з обладнанням змінюється сам; наявна пам’ять, продуктивність вводу / виводу (HDD та мережа) та процесор - і ви знайдете, що є нехитрі зміни, які призводять до того, що ви хочете отримати бажану на 400% продуктивність - але жодного швидкого відповіді ви не знайдете в режимі он-лайн.

Ви можете скопіювати + наклеїти білий папір Magento, спонсорований Peer 1, на якість (ми б не рекомендували його) сподіваємось, що налаштування не перевищують наявної пам’яті, обмежень потоку, стану TCP / IP, ємності вводу / виводу та призводять до меншої продуктивності, ніж конфігурація Apache / mod_php ванілі

Тож продовжимо далі.

Ідеальний стек сервера Magento

Це швидше наблизить вас до реальності. Хороший приклад, щоб продемонструвати це - показати, як налаштована спеціальна Magento OS, MageStack

Візьміть окремі підкомпоненти, і ви отримаєте список найоптимальнішого / найважливішого програмного забезпечення при правильній налаштуваннях для запуску магазину Magento. Зокрема:

Брандмауер, фільтр DOS, балансир завантаження, лак, Nginx, PHP, Redis, Memcached, MySQL

Отже, коли ви запитуєте:

Що таке найкраща настройка сервера Magento?

Яка саме ваша мета?

1. Висока доступність
2. Надійність
3. Простота управління
4. Продуктивність
5. Масштабованість

Досить читати лекції, як би ми це зробили

Щоб частково відобразити відповідь, подану на сервері , виникла подібна вена. У вашому розпорядженні 3 сервери - тому спочатку орієнтуйте їх якомога оптимальніше. Ми уникатимемо широко доступного рішення, оскільки це далеко виходить за межі цієї відповіді.

Підкомпоненти, необхідні для налаштування декількох серверів:

• Брандмауер
• Балансир завантаження
• Веб-сервер
• MySQL Server
• Загальне зберігання

Тож ми будемо багатоцільовими деякими системами. Відповідність PCI-DSS диктує роль для кожного сервера. Отже, з 5 ролями та 3-ма серверами - ви будете порушені негайно. MageStack подолає це за допомогою віртуалізації - ви можете зробити те ж саме.

Сервер 1: Завантажити балансир + Веб-сервер
Сервер 2: Веб-сервер
3: Сервер баз даних

Без низькою латентністю і значною пропускної здатності мережі (> 1Гбіт, <125μs), а які не мають загального зберігання - його краще для вас , щоб просто зберігати каталог магазину кореня на кожному комп'ютері , і копіювати дані, або в режимі реального часу з використанням ionotifyабо минула , використовуючи cronробота. Знову ж таки, ми уникатимемо мережевих файлових систем, таких як NFS, або реплікуваних блокових пристроїв, таких як Gluster або DRBD - оскільки потрібна широка настройка та пристойна пропускна здатність мережі.

Лак повинен сидіти якомога ближче до передньої частини. Але лак не може розшифрувати SSL. Тому комбінуйте його з SSL-термінатором; Nginx, Pound, Stunnel, Stud і т. Д. Вбудований балансир навантаження в лаку не є великим - але був би достатнім для налаштування двох серверів.

Nginx + PHP-FPM - це добре, але не пийте занадто багато Nolx-коль-допомоги. Він буде майже однаково виконаний з традиційною конфігурацією Apache / mod_php, ось кілька хороших читань про те, чому б не використовувати Nginx . Nginx - це хороший, дуже хороший товар, але він, безумовно, не є вузьким місцем магазину Magento - зважаючи на його складність та відсутність рідної підтримки Magento. Більшість початківців системних адміністраторів виграють від використання Apache / mod_php над чим-небудь іншим. Це може здатися архаїчною рекомендацією щодо використання PHP-FPM - але наші тести на ефективність показали продуктивність лише на 7% швидше за допомогою рішення Nginx - при правильній настройці. Налаштування та досвід, необхідний для високоефективного, надійного налаштування Nginx / PHP-FPM, є досить великим, щоб його перевершити Apache / mod_php. Що б ви не вирішили скористатися, це ваш дзвінок.

Сервер бази даних простий, MySQL. Як уже згадувалося раніше, якщо у вас сайт з високою конверсією, рекомендується налаштувати Master / Slave. Чи слід дотримуватися такого підходу, можна визначити, прочитавши цю статтю .

Тоді ваші периферійні кеші, Memcached та Redis. У менших магазинах зберігання сеансів в одному екземплярі Memcache та швидкий кешбек-кеш в іншому принесуть хороші переваги продуктивності. Ми не радимо зберігати теги кеша в повільному бекенді - оскільки це спричиняє більше проблем, ніж створює. Тож із налаштуванням Memcached вам доведеться втратити теги кешу . Замість цього ми використовуємо конфігурацію , як це .

Redis не є рідним для Magento, але з розширенням від Colin Mollenhour - його краще рішення, ніж Memcache, підтримує теги кеша, зберігання сеансів і навіть стійке зберігання кешу - його не настільки мінливий, як Memcache . Але у нього є свої недоліки. Ми виявили у великих масштабних виробничих магазинах (> 500 замовлень на годину,> 30 тис. Уніфікатів на годину), що кеш (та теги) можуть заповнюватися дуже швидко, і як тільки точка насичення потрапила, механізм LRU дещо виходить з ладу ( незважаючи на різні налаштування) і спричиняє велике негайне вузьке місце. Тому доцільно регулярно обрізати старі записи вручну.

То яке обладнання потрібно використовувати для чого?

Веб-сервери: Найшвидший процесор, більшість процесорних ядер, співвідношення 2 ГБ оперативної пам’яті / основний
сервер БД: Швидкий ЦП, найшвидший диск вводу / виводу, більшість оперативної пам’яті

Тож, коли багатоцільові ваші 3 машини, найкращим компонуванням буде:

Сервер 1: Термінатор SSL -> Лак -> Nginx / Apache> PHP
Server 2: Nginx / Apache> PHP, Redis, (MySQL Slave)
Сервер 3: MySQL

Що стосується конкретної конфігурації кожної програми. Ну, це залежить від ваших технічних характеристик, складності вашого магазину, типу та характеру відвідувачів та чистого обсягу відвідувачів.

Ви перебуваєте на відмінному шляху з цією конфігурацією кластера. Я рекомендую додати виділений хост кешу для Redis; виберіть один з високою потужністю процесора та великою кількістю оперативної пам’яті (~ 64 ГБ).

Ось повний перелік конфігурацій, які я використовував для високодоступного, відмовного, розподіленого та завантаженого кластеру LEMP. Вона включає в себе app/etc/local.xml, в core_config_dataтаблицю і конфігурацій для MySQL, PHP-FPM, Nginx і Redis. Усі запущені 64-розрядні Ubuntu 12.04 LTS. Конфігурації містять безліч оптимізацій без недоліку.

Основні моменти

• Користувачі адміністраторів: 46
• Категорії: 2450 (найбільший - 2400 товарів)
• Суб'єкти товарів: 101 000
• Комбіновані товари: 484
• Товарні відносини: 54 000
• На складі та включена налаштована продукція: 10000
• Блоки CMS: 3100
• Сторінки CMS: 1400

Трафік серпня 2013 року:

• 40 мільйонів переглядів сторінок щомісяця
• 2,3 мільйона унікальних відвідувачів
• 46 000 щомісячних кас
• 89% відвідувачів із США

Веб-хости

За резервними, високо доступними апаратними брандмауерами та апаратними балансирами навантаження стоїть 10 хостів. Більшість статичних активів завантажуються на CDN.

• Середній час відгуку на рівні сайту: 282 мс
• Середня відповідь FPC: 48 мс
• середнє навантаження: 0,6 - 1,0 (у тестах, продуктивність знижується на 35% при середньому навантаженні ~ 5,0)
• Подвійний процесор Intel Xeon E3-1230 V2 при 3,30 ГГц (по 4 ядра)
• Оперативна пам’ять 32 ГБ DDR3 1333 МГц

Модулі

• https://github.com/colinmollenhour/Cm_RedisSession
• https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
• https://github.com/aligent/CacheObserver.git --branch = моделі
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMenu.git --branch = виробництво
• https://github.com/Vinai/customer- активація
• https://github.com/gknoppe-guidance/magento-cachebuster

Хости кешу

Є два хости, що працюють Redis в конфігурації master-slave з автоматичним відмовою. Три екземпляри Redis (сеанси, бекенд і FPC) використовуються для збільшення пропускної здатності та забезпечення тонкої настройки постійної поведінки.

• 3000 команд в секунду
• Середній час відповіді 0,7 мс
• середнє навантаження від 1,0 до 1,5
• Квадратний процесор Intel Xeon E5-2620 0 при 2,00 ГГц (6 ядер кожен)
• 128 ГБ оперативної пам'яті DDR3 1333 МГц
• Механічні диски, RAID 1, апаратний контролер

Хости бази даних

Є два хости, на яких працює MySQL 5.6.11 в конфігурації головного підлеглого з теплим відмовою.

• 1500 команд в секунду
• Середній час відгуку - 1,1 мс
• середнє навантаження 0,1 (головний) і 0,4 (підлеглий)
• Quad Intel Xeon CPU E7- 2860 при 2,27 ГГц (10 ядер кожен)
• 128 ГБ оперативної пам'яті DDR3 1333 МГц
• SSD, RAID 1 + 0, апаратний контролер
• MySQL 5.6.11 з tcmalloc

Ще одна порада сервера для Magento - це встановлення PHP 5.4 або 5.5 за допомогою OPcache . PHP 5.4 набагато швидше, ніж 5.3 ( http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/ ).

Хочу додати ще одну важливу пораду, яка покращила швидкість сторінки magento, коли не кешується лаком, і не включена за замовчуванням (час завантаження сторінки кошика змінився з 6sc на 1,5sc).

Активуйте кеш запитів mysql в /etc/mysql/my.conf

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

cache_type включити його, розмір кешу - це значення, яке використовується кеш-пам'яттю, а обмеження кешу - максимальний розмір результату запиту для кешування

З нашою поточною конфігурацією ми отримуємо початкову відповідь у 400 мс і завершуємо документ за 2 секунди (використовуючи стандартне з'єднання 5 Мбіт / с). Розмір нашої домашньої сторінки - 1 мб.

Наша настройка базується на AWS наступним чином: У нас є екземпляр ec2 з балансиром навантаження, підключеним до бази даних RDS (з відмовою). Ми також реалізували кеш на повній сторінці із резервним кешем Redis для зберігання кешу та сеансу.

У середньому ми маємо 300 - 400 відвідувачів на день, але з увімкненим кешуванням Redis ми мали мінімальне використання ресурсів ec2, зберігаючи швидкість та зменшуючи витрати.

Причиною, що у нас є балансир навантаження, є те, що ec2 налаштований автоматично завантажувати новий екземпляр, якщо в рідкісних шансах у нас з'являються сплески трафіку, з якими поточна установка не може впоратися.