Добавление обратного прокси - nginx или лака
В настоящее время мы обслуживаем большинство наших приложений Rails и LAMP поверх Apache и Apache passenger, но мы рассматриваем возможность добавления Nginx или Varnish в качестве обратного прокси-сервера, чтобы несколько снизить нагрузку на наши серверы.
Я знаю, что вы можете использовать Varnish и Nginx вместе, но, учитывая, что есть время, затрачиваемое на изучение того, как работают оба, и, где возможно, мы хотим, чтобы количество "движущихся частей" в нашей инфраструктуре было как можно меньше, Я пытаюсь понять, какие преимущества и недостатки есть между использованием:
- nginx сам по себе как обратный обратный прокси / кеш
- один лак как обратный прокси / кеш
- nginx и лак вместе
Я понимаю, что nginx, как известно, очень быстр, и он становится заметным как полноценный http-сервер, так как становится все популярнее, поэтому я вижу аргумент для того, чтобы потратить некоторое время на изучение работы этого сервера, но Varnish все еще неизвестен мне.
Зачем мне использовать Varnish, если nCache теперь в Nginx?
Спасибо
2 ответа
Ожидаете ли вы использовать Edge Side Includes (ESI)? Если это так, модуль Nginx ESI не работает и имеет некоторые открытые ошибки. Если вы используете Varnish, вывод не сжимается, поэтому вы несколько застряли, используя Nginx для сжатия страниц с поддержкой ESI. В то время как я работаю с фреймворками Python, Rails похож.
С вашей текущей настройкой вы можете сделать что-то вроде:
Nginx -> Apache -> Пассажирские -> Rails Varnish -> Apache -> Пассажирские -> Rails
Оба упали бы перед вашей существующей системой. С Nginx вы также можете предоставить ему прямой доступ к статическим файлам и позволить ему обслуживать тех, кто не использует прокси через Apache. Используя директиву Location, вы можете нарезать части своего веб-пространства и предотвратить прохождение через прокси.
Однако, если вы хотите полностью перейти на Nginx, ваша инфраструктура становится:
nginx -> пассажирский -> рельсы (nginx -> uwsgi -> python)
Если вы добавите Varnish, вы получите:
лак -> nginx -> пассажирский -> рельсы
если вы не используете ESI, в этом случае вы получите:
nginx -> лак -> nginx -> пассажирский -> рельсы
В какой-то момент удаление Varnish из смеси становится довольно интригующим. Тем не менее, последние выпуски Varnish по-прежнему быстрее, чем кэширование Nginx, и у вас есть большой контроль над тем, как вы можете кэшировать. В то время как и Nginx, и Varnish дают вам немного контроля, VCL Varnish позволяет вам писать код на C, чтобы делать то, что не выполняется, без касания исходного кода демона. Полезно ли это для вас, зависит от вас.
Поскольку вы используете Apache в настоящее время, я был бы более склонен поставить Varnish вперед, если вы не собираетесь перейти на Nginx и полностью удалить Apache. Лак в вашем случае - это скорее капельное решение. Если вы решите использовать ESI в будущем, вам нужно будет запустить оба варианта.
Вот сравнительный тест Varnish, Nginx (восходящая звезда), Apache Traffic Server (еще один кеш-прокси), G-WAN (сервер приложений со сценариями C) и Lighttpd (настоящий хороший wweb-сервер):
http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/
Apache Traffic Server - это HTTP-прокси-сервер и сервер кеша, созданные Inktomi и распространяемые как коммерческий продукт до приобретения Inktomi компанией Yahoo.
Yahoo говорит, что использует TS для обслуживания более 30 миллиардов объектов в день. Они также говорят, что TS - "продукт буквально сотен лет разработки".