В настоящее время мы работаем с требованием, чтобы первый ответ от веб-сервера был в Великобритании менее чем за 200 мс. В настоящее время под 2 выделенными веб-серверами под балансировщиком нагрузки и 1 дБ-сервером мы находимся на 800 мс.

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

Он также запускается на nginx с Varnish.

Кто-нибудь может дать мне какой-нибудь совет по настройке веб-сервера? Почему наши приходят медленно? Что вы можете порекомендовать для оптимизации этого? Нужно быстрее на 400%!

Я укушу

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

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

Мы входим в 800 мс.
Он также запускается на Nginx с Varnish.

Вы неправильно настроили лак.

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

На самом деле, для 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   

Это не случай настройки Varnish, это случай "вы вообще ничего не кешируете" .

Идеальные файлы конфигурации сервера Magento

Нет, ну, не совсем.

Мы работаем более 400 серверов, все чисто магазины Magento - разных размеров и емкости. И редко когда файлы конфигурации у нас на одном - будут совпадать с файлами другого. Это потому, что не все предприятия одинаковы.

Узкие места могут образовываться по разным причинам:

1. Большое количество одновременных посетителей, с активными сессиями
2. Жертвы «плохих» роботов-ползунов, генерирующие необходимую, бесценную нагрузку
3. Высокая доля многоуровневых навигационных хитов
4. Большое количество поисковых запросов
5. Большой объем транзакций в час
6. Плохо построенный шаблон
7. Слишком много / медленных / громоздких сторонних расширений
8. Устаревшие входящие ссылки, приводящие к высокой доле 404 обращений
9. Пропускная способность сетевого интерфейса на пределе
10. Большой / сложный каталог (много товаров / категорий / атрибутов)

Так что с магазинами по всему этому спектру у каждого свой подход к более оптимальной производительности.

Решить проблемы, изложенные выше; мы намеренно избегаем просто указывать «больше / лучше оборудования»

1. Используйте FPC за пределами Varnish
2. Отфильтровывать / блокировать плохих ботов на границе сети - или перенаправлять все запросы в Varnish независимо от состояния куки / URL
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%, но ни одного быстрого ответа вы не найдете в Интернете.

Вы можете скопировать + вставить спонсируемую Peer 1 белую бумагу Magento по производительности (мы не рекомендуем); Надеемся, что настройки не превысят вашу доступную память, ограничения потоков, состояния TCP / IP, емкость ввода-вывода и приведут к меньшей производительности, чем обычная конфигурация Apache / mod_php.

Итак, давайте продолжим.

Идеальный серверный стек Magento

Это с большей вероятностью приблизит вас к реальности. Хороший пример для демонстрации этого - показать, как настроена выделенная ОС Magento, 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 мкс), а не с общим хранилищем - вам лучше просто хранить корневой каталог хранилища на каждом компьютере и реплицировать данные либо в режиме реального времени, ionotifyлибо с использованием упущенной cronработа. Опять же, мы будем избегать сетевых файловых систем, таких как NFS, или реплицированных блочных устройств, таких как Gluster или DRBD, - так как требуется обширная настройка и приемлемая пропускная способность сети.

Лак должен сидеть как можно ближе к передней части. Но Varnish не может расшифровать SSL. Так что объедините его с терминатором SSL; Nginx, Pound, Stunnel, Stud и т. Д. Встроенный балансировщик нагрузки в Varnish не очень хорош, но его вполне достаточно для установки двух серверов.

Nginx + PHP-FPM - это хорошо, но не пейте слишком много помощи от Nginx. Он будет работать почти так же, как и в традиционной конфигурации Apache / mod_php, вот несколько хороших прочтений о том, почему не использовать Nginx . Nginx - это хороший, очень хороший факт, но он определенно не является узким местом магазина Magento - и учитывая его сложность и отсутствие поддержки Magento. Большинство начинающих системных администраторов выиграют от использования Apache / mod_php над всем остальным. Это может показаться архаичной рекомендацией по использованию PHP-FPM, но наши тесты производительности показали, что при использовании решения Nginx производительность всего на 7% выше - при правильной настройке, Настройка и опыт, необходимые для высокопроизводительной и надежной установки Nginx / PHP-FPM, достаточно велики, чтобы превзойти Apache / mod_php. Какой бы выбор вы ни выбрали, это ваш звонок.

Сервер базы данных прост, MySQL. Но, как уже упоминалось ранее, если у вас сайт с высоким уровнем конверсии, рекомендуется конфигурация Master / Slave. Следует ли вам следовать этому подходу, можно узнать, прочитав эту статью .

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

Redis не является родным для Magento, но с расширением от Colin Mollenhour - это лучшее решение, чем Memcache, поддерживает теги кеша, хранилище сессий и даже постоянное хранилище кеша - это не так изменчиво, как Memcache . Но у него есть свои недостатки. Мы обнаружили, что в крупных производственных магазинах (> 500 заказов / час,> 30 000 уникальных единиц / час), что кэш (и теги) могут заполняться очень быстро, и как только точка насыщения была достигнута, механизм LRU несколько выходит из строя ( несмотря на различные настройки) и вызывает массивное непосредственное узкое место. Поэтому целесообразно регулярно удалять старые записи вручную.

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

Веб-серверы: самый быстрый ЦП, большинство ядер ЦП, соотношение 2 ГБ ОЗУ /
сервер основной БД: быстрый ЦП, самый быстрый дисковый ввод-вывод, большая часть ОЗУ

Таким образом, при многоцелевом использовании ваших 3-х машин наилучшим макетом будет:

Сервер 1: SSL Terminator -> Varnish -> Nginx / Apache> PHP
Сервер 2: Nginx / Apache> PHP, Redis, (MySQL Slave)
Сервер 3: MySQL

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

Вы находитесь на отличном пути с этой конфигурацией кластера. Я рекомендую добавить выделенный хост кеша для Redis; выберите один с высокой мощностью процессора и большим количеством оперативной памяти (~ 64 ГБ).

Вот полный список конфигураций, которые я использовал для кластера LEMP высокой доступности, отказоустойчивого, распределенного и с балансировкой нагрузки. Он включает app/etc/local.xmlв себя core_config_dataтаблицу и конфигурации для MySQL, php-fpm, nginx и Redis. Все работают Ubuntu 12.04 LTS 64-bit. Конфигурации включают в себя множество оптимизаций без недостатков.

Особенности

• Администраторов: 46
• Категории: 2450 (самый большой из них - 2400 продуктов)
• Объекты продукта: 101 000
• Комбинированные продукты: 484
• Товарные отношения: 54 000
• В наличии и доступно настраиваемых продуктов: 10 100
• Блоки 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 = models
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMenu.git --branch = production
• https://github.com/Vinai/customer-activation
• https://github.com/gknoppe-guidance/magento-cachebuster

Хост кеша

Существует два хоста, на которых выполняется Redis в конфигурации главный-подчиненный с автоматическим переключением при сбое. Три экземпляра 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 (ведомый)
• Четырехъядерный процессор Intel Xeon 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, когда не кэшируется лаком и не включен по умолчанию (время загрузки страницы корзины изменилось с 6 до 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 настроен на автоматическую загрузку нового экземпляра, если при редком случае у нас возникают всплески трафика, которые не могут быть обработаны текущей установкой.