Я думаю об архитектуре нового веб-сервера. Будет ли хорошей идеей иметь Varnish в качестве кэша перед Nginx в качестве обратного прокси-сервера и предоставлять статические файлы перед Apache для всех тяжелых задач?
Я собираюсь запустить php и ruby в приложениях rails.
Будет ли слишком много накладных расходов на передачу php-запросов в apache через два других процесса?
Большое спасибо!
Ответы:
Да, это действительно. Мой личный подход заключается в том, чтобы использовать Varnish заранее и использовать VCL для разделения трафика между статическими запросами NGINX и вашими тяжелыми нагрузками (будь то Apache или Passenger или ... это не имеет значения). Это особенно верно, если он находится на той же машине, где вам не нужны дополнительные издержки. Это не обязательно купить вам что-нибудь.
Varnish (пока) не поддерживает сжатие gzip, так что, возможно, стоит поменять его местами с nginx, чтобы сжать то, что лак отправляет обратно. Поскольку лак и nginx не борются за одни и те же ресурсы (nginx использует ЦП для сжатия gzip, а лак использует память), они должны работать без перебоев на одной машине.
Varnish теперь поддерживает сжатие gzip , поэтому, если вам не требуется SSL-завершение (как это предлагается в комментариях), я бы посоветовал помещать лак непосредственно в контакт с Интернетом.
Для http:
(интернет) -> (лак, gzip, кеширование, esi) -> (приложение)
Для https:
(интернет) -> (nginx, ssl) -> (лак, gzip, кеширование, esi) -> (приложение)
Если вы хотите, чтобы там тоже был apache (для повсеместной поддержки mod_foobar), я бы поставил его между лаком и приложением
Обновление: Обновлено, чтобы включить поддержку gzip в лаке 3.0. Добавлен ssl / esi как предложено в комментариях
Сумма накладных расходов не должна быть значительной. Я предполагаю, что одна из причин, по которой вы хотите использовать эти два уровня, - это масштабируемость; в этом случае вы, скорее всего, увидите, по сравнению с apache, что лак и nginx работают не очень усердно.
Если вы используете все три уровня на одном компьютере, это не должно повлиять на производительность, прежде чем вы достигнете емкости самого сервера.
Как альтернатива, почему бы не лак + nginx с пассажиром? Я использовал эту настройку в прошлом, а использование nginx для пассажиров относительно легкое и работало довольно хорошо. Возможно, стоит подумать, если вы не состоите в браке с Apache, управляющим вашим стеком рельсов.
Я администратор системы для платформы электронной коммерции запуска. Мы используем varnish + nginx перед нашим стеком PHP / apache, и он творил чудеса.
У нас есть приложение с высоким использованием памяти, и оно использовало около 15-20 гигабайт оперативной памяти на каждый веб-узел, и как только мы добавили лак вперед, теперь оно составляет около 8 гигабайт оперативной памяти на узел. Они никогда не пили.
Поэтому я очень рекомендую это.
Я использую Drupal с модулем boost на сервере Apache + PHP + MySQL, но перед ними я использую Nginx с включенной функцией gzip-static и использую результаты boost для обслуживания пользователей.
И в довершение ко всему, я использую лак, все на одном компьютере, у меня хорошие результаты.
Я также использую Nginx для настройки заголовков, которые Drupal не очень хорошо подходит для кеша.
Это плохая идея, если вам не нужно что-то вроде ESI. У Nginx есть своя собственная система кеширования, которая работает лучше .
Apache можно использовать для прекращения (дешифрования) SSL, проверьте http://noosfero.org/Development/Varnish#SSL