Nginx против Apache в качестве обратного прокси, какой выбрать

36

этот вопрос, возможно, задавался здесь, но я не смог найти ни одного, который бы действительно соответствовал моему вопросу. Слышал, что производительность nginx весьма впечатляет, но у Apache есть больше документации, сообщества (читай: эксперт), чтобы получить помощь

Теперь то, что я хочу знать, как сравниваются оба веб-сервера с точки зрения производительности, простоты настройки, уровня настройки и т. Д. КАК ОБРАТНЫЙ ПРОКСИ-сервер в среде vps ??

Я все еще взвешиваю два из них для веб-приложения ruby ​​(не ROR), обслуживаемого thin (одним из веб-серверов ruby).
Конкретный ответ будет высоко ценится. Общий ответ, не касающийся рубиновой части, в порядке. Я все еще нуб в администрировании веб-сервера.

MHD
источник
Ответы tnx на martin и webdestroya, теперь я склоняюсь к nginx
mhd
Разве не имеет смысла использовать специально разработанный реверс-прокси, такой как лак?
ptman

Ответы:

31

Я хотел поместить это в комментарии, так как я согласен с наиболее важным моментом ответа webdestroyas, но он стал слишком длинным.

Вы находитесь в среде VPS, это означает, что вам, скорее всего, будет недостаточно оперативной памяти. Только по этой причине вам понадобится Nginx, так как его объем памяти меньше, чем у Apache.

Также я не согласен с некоторыми из упомянутых аргументов.

Простота настройки:
Nginx не сложнее, чем Apache. Это другое. Если вы привыкли к Apache, то изменить всегда будет сложнее, это не значит, что сам стиль конфигурации сложнее. Я полностью перешел с Apache на Nginx более года назад, и сегодня мне будет сложно настроить сервер Apache, тогда как Nginx будет чрезвычайно прост в настройке.

Для Ruby:
Nginx имеет Passenger, однако я обычно вижу его описанным как низший метод подключения к Ruby. Я не программист на Ruby, поэтому я не могу это проверить, но я часто вижу, что Unicorn и Thin упоминаются как лучшие альтернативы.

В заключение:
Nginx был создан, чтобы быть обратным прокси. Изначально все, что он делал, - это обслуживал статические файлы и обратный прокси-сервер к внутреннему серверу через HTTP / 1.0. С тех пор были добавлены fastcgi, балансировка нагрузки и различные другие функции, но первоначальной целью проекта было предоставление статических файлов и обратного прокси-сервера. И это делает это действительно хорошо.

Apache, напротив, является веб-сервером общего назначения. Я не сомневаюсь, что он может полностью изменить прокси, но он не был спроектирован так, чтобы иметь минимальный объем памяти, и в результате он требует больше ресурсов, чем Nginx, что означает, что мой начальный аргумент среды VPS вступает в игру.

Мартин Фьордвальд
источник
+1 за разъяснение.
Джон Гарденье
Я бы зашел так далеко, чтобы рекомендовать его как ваш единственный веб-сервер. см. мои комментарии serverfault.com/questions/133481/… <- здесь. Я использую его как единственный веб-сервер на моем VPS, и я получил других пользователей на борту с FastCGI для их приложений PHP / CGI.
Джейсон
Джейсон Я использую его в качестве своего единственного веб-сервера уже более года, и он обрабатывает миллионы загрузок страниц в день. Я полностью согласен с вашей рекомендацией! :)
Мартин Фьордвальд
8

Производительность:
NGinX. Этот сервер, как известно, является одним из самых эффективных веб-серверов и используется многими различными компаниями (Notable, MediaTemple)

Простота настройки:
Apache. Конфигурация Apache действительно проста и действительно мощна. Nginx мощен, но его очень сложно понять, так как он больше похож на язык программирования, чем на файл конфигурации.

Уровень настройки:
Apache. Для Apache написано множество модов и других плагинов. Хотя в Nginx все еще есть плагины для него, я думаю, что у Apache гораздо больше, чем у Nginx.

Для Ruby:
я знаю, что Nginx можно использовать как мощный балансировщик нагрузки с Mongrel / Webrick. Однако у Apache есть Phusion / Passenger, что делает интеграцию более приятной.

Победитель обратного прокси:
NGinX

Митч Демпси
источник
2
Мне интересно, не спорю. Почему Nginx победитель обратного прокси? Остальная часть вашего ответа на самом деле не выделяет одно из другого. Во всяком случае, это склоняется в пользу Apache.
Джон Гарденье
1
Ну, потому что по большей части вам нужен обратный прокси из-за высокой нагрузки. Что означало бы, что производительность, вероятно, самая большая проблема, и в этом случае Nginx был победителем, поэтому я выбрал его. Как разработчик, я люблю apache, но с точки зрения «как я могу получить максимальную производительность от этого веб-сервера», я бы пошел с Nginx
Митч Демпси
8

Nginx основан на событиях, а apache - на процессах. Под высокой нагрузкой это имеет значение в мире ... Apache должен разветвлять или запускать новый поток для каждого соединения, а nginx - нет. Эта разница проявляется в основном в использовании памяти, но также во времени отклика пользователя и других показателях производительности. Nginx может обрабатывать десятки тысяч одновременных соединений поддержки активности HTTP на современном оборудовании. Apache будет использовать 1-2 МБ стека для каждого соединения, поэтому, выполняя вычисления, вы видите, что вы можете обрабатывать только несколько сотен или, может быть, тысячу соединений одновременно, не начав менять местами.

Мы используем nginx перед Apache и IIS в нашей среде в качестве прокси-сервера для балансировки нагрузки и кэширования, и не могли быть счастливее. Вместо пары очень дорогих арендуемых устройств F5 мы используем два небольших nginx-бокса, и наши сайты работают намного быстрее как по ощущениям, так и по измеренному времени отклика.

rmalayter
источник
1

Я был в той же дилемме, что и ты, две недели назад.

Чтобы дать Вам действительно краткий ответ: Из моих исследований nginx действительно быстр и дружествен к ресурсам, но было решено только отменить прокси-статические файлы. Остальное зависит от решений, которые Вы должны настроить или составить сценарий.

AFAIK nginx не имеет файлов htaccess, поэтому вам нужно найти способ обойти это, если зависит от этой функции.

AFAIK все необходимое работает, и я видел учебники.

Я пойду с nginx с моими настройками тестирования и профилирования. У меня есть типичное приложение LAMP.

Я читал, что есть люди, которые обращаются через прокси и обслуживают статические файлы из nginx и передают все остальное, как PHP, работающему экземпляру Apache. Они требуют хорошего компромисса. У меня нет данных об этом, но вы можете знать.

deploymonkey
источник
2
Отключение переопределений htaccess на apache по соображениям производительности встречается довольно часто, поддержка такой функции на сервере, предназначенном для высокой производительности, не имеет большого смысла.
theotherreceive
Спасибо за добавление этого заявления. ОП не админ, поэтому мы должны быть ясны.
deploymonkey
1

У меня были серьезные проблемы с Apache mod_proxy на различных платформах в разных средах за последние пару лет. Время от времени он просто перестает работать, и, похоже, единственное лекарство - перезапуск сервера Apache.

Лично я бы не спрашивал «nginx vs Apache», а «nginx vs lighttpd» - и это гораздо более сложный вызов!

Пн.
источник
Допустимый аргумент, но в прошлый раз, когда я проверял, lighttpd все еще имел длинные ошибки и был признан за утечки памяти. Это было рекомендовано для развертывания производства администраторами. Это изменилось?
deploymonkey
Он имеет предостережений, конечно (особенно там , где служит очень больших файлов), но это значительно более стабилен , чем Apache в качестве прокси - у меня не было никаких реальных проблем в нескольких развертываний в течение последних шести месяцев
Мо
Я списал lighttpd из списка кандидатов по какой-то забытой причине :)
mhd