Я думаю об архитектуре нового веб-сервера. Будет ли хорошей идеей использовать Varnish в качестве кеша перед Nginx в качестве обратного прокси и обслуживать статические файлы перед apache для всей тяжелой работы?
Я собираюсь запустить приложения php и ruby on rails.
Будет ли слишком много накладных расходов на передачу php-запросов к apache через два других процесса?
Большое спасибо!
Да, это действительно так. Мой личный подход заключался бы в использовании Varnish заранее и использовании VCL для разделения трафика между статическими запросами NGINX и вашей тяжелой работой (будь то Apache или Passenger или ... это не имеет значения). Это особенно верно, если является на той же машине, поскольку вам не нужны дополнительные накладные расходы. Это не обязательно что-то вам купит.
Varnish (пока) не поддерживает сжатие gzip, поэтому было бы неплохо поменять его с nginx впереди, чтобы сжать то, что varnish отправляет обратно. Поскольку varnish и nginx не борются за одни и те же ресурсы (nginx использует процессор для сжатия gzip, а varnish использует память), они должны работать без сбоев на одной машине.
Лак сейчас поддерживает сжатие gzip, поэтому, если вам не нужно завершение SSL (как предлагается в комментариях), я бы предложил использовать лак непосредственно в контакте с Интернетом.
Для http:
(internet) --> (varnish, gzip, caching, esi) --> (application)
Для https:
(internet) --> (nginx, ssl)--> (varnish, gzip, caching, esi) --> (application)
Если вам тоже нужен apache (для повсеместной поддержки mod_foobar), я бы поставил его между лаком и приложением.
Обновить: Обновлено, чтобы включить поддержку gzip в Varnish 3.0. Добавлен ssl / esi, как предложено в комментариях
Накладные расходы не должны быть значительными. Я предполагаю, что отчасти вы хотите использовать эти два уровня для масштабируемости; В этом случае вы, скорее всего, увидите, что по сравнению с apache, varnish и 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