В настоящее время мы обслуживаем большинство наших приложений Rails и LAMP через Apache и Apache, но мы рассматриваем возможность добавления Nginx или Varnish в качестве обратного прокси, чтобы несколько снизить нагрузку на наши серверы.
Я знаю что ты жестяная банка использовать Varnish и Nginx вместе, но, учитывая, что нужно потратить время на изучение того, как работают оба, и, где это возможно, мы хотим, чтобы количество «движущихся частей» в нашей инфраструктуре было как можно меньше, я пытаюсь понять, что преимущества и недостатки между использованием:
Я понимаю, что nginx, как известно, чрезвычайно быстр, и он становится все более популярным как полноценный http-сервер, поэтому я вижу аргумент в пользу того, чтобы потратить некоторое время на изучение того, как этот сервер работает, но Varnish все еще неизвестен меня.
Зачем мне использовать Varnish, если nCache теперь находится в Nginx?
Спасибо
Вот сравнительный тест 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 - это «продукт буквально сотен лет разработки».
Ожидаете ли вы использовать Edge Side Includes (ESI)? Если это так, то модуль Nginx ESI неисправен и имеет несколько открытых ошибок. Если вы используете Varnish, вывод не сжимается, поэтому вы несколько застряли при использовании Nginx для сжатия страниц с поддержкой ESI. Пока я работаю с фреймворками Python, Rails похож.
С вашей текущей настройкой вы можете сделать что-то вроде:
Nginx -> Apache -> Passenger -> Rails Varnish -> Apache -> Passenger -> Rails
Оба упадут перед вашей существующей системой. С помощью Nginx вы также можете предоставить ему прямой доступ к статическим файлам и позволить ему обслуживать их без необходимости прокси-сервера через Apache. Используя директиву Location, вы можете отрезать части вашего веб-пространства и предотвратить прохождение этого через прокси-сервер.
Однако, если вы хотите полностью перейти на Nginx, ваша инфраструктура станет:
nginx -> пассажирский -> рельсы (nginx -> uwsgi -> python)
Если вы добавите Varnish, вы получите:
лак -> nginx -> пассажирский -> рельсы
если вы не используете ESI, и в этом случае вы получите:
nginx -> лак -> nginx -> пассажирский -> рельсы
В какой-то момент удаление лака из смеси становится довольно интригующим. Однако последние выпуски Varnish по-прежнему работают быстрее, чем кеширование Nginx, и у вас есть большой контроль над тем, как вы можете кешировать. Хотя и Nginx, и Varnish дают вам довольно много контроля, VCL Varnish позволяет вам писать код на C, чтобы делать вещи, которые ни один из них не делает из коробки, не затрагивая исходный код демона. Вам решать, будет ли это полезно для вас.
Поскольку в настоящее время вы используете Apache, я был бы более склонен поставить Varnish впереди, если вы не собираетесь переходить на Nginx и полностью удалять Apache. Лак в вашем случае - это скорее простой раствор. Если вы решите, что собираетесь использовать ESI в будущем, вам нужно будет запустить оба.