Настройка обратного прокси-сервера, спецификации сервера?
В настоящее время у нас есть два сервера в настройке 1+1. 1 apache, 1 mysql. Оба выделенные с 32 ядрами и 64 ГБ оперативной памяти. С каталогом более 300 тыс. Magento EE 1.11
Следуя "Оптимизации для максимальной производительности" Magento, мне было интересно, каковы были бы оптимальные спецификации сервера, если бы мы добавили обратный прокси-сервер, такой как Varnish или nginx, на основе текущей настройки 1+1?
В руководстве спецификации тестового оборудования для всех серверов были следующими:
- ПРОЦЕССОР: 2 x Intel® Процессор Xeon® E5645 @ 2,40 ГГц - 12 ядер, 24 потока
- Жесткий диск: RAID1-LSI MegaRAID SAS 9260-4i; 2 x SAS 164 ГБ 15 000 об/мин
- ОПЕРАТИВНАЯ память: 24 ГБ ECC
- Сетевая интерфейсная карта: Intel 1 ГБ 82576
Я чувствую, что добавление еще одного сервера со спецификациями текущей настройки является излишним. Все, что делает обратный прокси-сервер, - это раздает кэшированный контент, и если что-то динамично, оно отправляется в apache/PHP для обработки. Есть какие-нибудь хорошие руководства или книги на эту тему?
2 answers
Во-первых, не читайте слепо какое-либо руководство (независимо от того, предоставлено Magento или нет) и попытайтесь определить конфигурацию сервера и спецификацию сервера для вашего собственного развертывания.
Их тесты и результаты полностью соответствуют их условиям тестирования и не применимы к вашему собственному магазину.
Каждый магазин Magento отличается
Кроме того, выбор оборудования для вашего развертывания - это не то, что кто-либо здесь может сделать с имеющейся у вас информацией представленный.
Вы предоставили недостаточно информации для полезного ответа.
- Сколько у вас посетителей в пиковый день
- Сколько у вас посетителей в час пик
- Предлагаете ли вы цифровые загрузки
- Какой объем транзита вы сейчас достигаете (в Мбит/с)
- Какая доля веб-трафика является SSL и нет SSL
- Как долго вы готовы хранить устаревшие товары в кэше
Для обратного прокси-сервера, вам нужно...
- Пропорциональный объем оперативной памяти для ваших хранилищ кэша (минимум 4 ГБ)
- Стандартные диски (дисковый ввод-вывод не имеет значения)
- Сетевая карта высокого класса (для уменьшения прерываний, повышения задержки и пропускной способности)
- Пропорциональное количество ядер процессора уровню трафика
- Необязательно. Аппаратная расшифровка SSL
Наш совет
Не беспокойтесь. На данный момент в вашем развертывании уже есть недостатки
- 2 отдельных пункта сбой
- Узкая пропускная способность MySQL по сети
- Слишком мало ядер на веб-сервере
- Слишком много ядер на сервере БД
- По указанным жестким дискам на веб-сервере
- Под указанными жесткими дисками на сервере БД
Хотите верьте, хотите нет, Magento работает лучше на одной машине до тех пор, пока вы не достигнете пределов вертикального масштабирования, потому что узкое место MySQL на удаленной машине с высокой задержкой, ограниченной независимо от скорости вашей сети, намного выше чем иметь его в одной и той же системе и иметь скорость оперативной памяти повсюду.
Не поймите меня неправильно, безусловно, есть переломный момент, когда многоцелевая машина 1 создает свои собственные проблемы с конкуренцией; но 32 ядра - это довольно небольшой предел нагрузки.
Если вы все еще продолжаете продвигаться вперед
Кэш-память для сайта с низким трафиком (менее 200 тыс. уникальных посетителей в день) обычно не требует более 2 ГБ оперативной памяти и 1-ядерный процессор - с жесткими дисками низкого класса. Но для вас это может быть просто на вашем веб-сервер в любом случае - он не будет привлекать никаких ресурсов, и, установив его на третью машину, теперь у вас будет 3 одиночных точки отказа и еще больше узких мест в сетевой активности.
Отнеситесь к этой статье со щепоткой соли - это маркетинговое упражнение от партнера 1, и большая его часть неверна.
По моему опыту, любого VPS (не OpenVZ) с 512 МБ оперативной памяти и 1 или 2 ядрами должно быть достаточно для прокси-сервера nginx для большинства пользователей. Увеличьте объем до 1 ГБ, и прокси-сервер будет легко обрабатывать 10 Мбит/с смешанного трафика кэшированного/динамического контента http/https. Если нет особой причины, по которой вы не можете/не должны просто запускать его на том же сервере, что и Apache, и, если что, это будет небольшое чистое сокращение использования ресурсов.