Апач против Nginx


29

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

Я провел некоторые поиски, но нет никакого определенного сравнения между ними, и мне было интересно, может ли кто-то здесь высказать свое мнение о различиях между ними.

Мои сегодняшние знания позволяют мне понять, что mod_php быстрее и безопаснее, чем fastcgi, однако Apache намного хуже, когда речь идет об одновременных подключениях и потреблении памяти.

Мой сайт использует много длинных опросов, но имеет не AJAX веб-базу (то есть Apache с длинным опросом сверху).

Моим первоначальным решением проблем с памятью Apache было отправить длинный опрос через node.js, а затем заставить node.js обращаться к Apache каждые 2 секунды, в этом случае у Apache не будет открытого соединения, а вместо этого будет node.js. Я пришел к выводу, что это может быть недостаточно хорошо, и я смотрю на различные решения. Мне все еще интересно, сработала ли моя оригинальная идея.

Так что же лучше для современного Интернета? Apache или Nginx?

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

Я отметил ответ Мартина Ф. с тех пор, как он дал такой четкий и полный ответ на мои вопросы, что я чувствую, что он заслуживает оценки, однако все три ответа были хорошими и обоснованными и наиболее определенно рассмотрят возможность использования обратного прокси-сервера для другого моего сайта. поскольку я только что нашел что-то очень-очень-очень хорошее, что Nginx может сделать в прокси.

Благодарность,

Ответы:


28

Похоже, у вас есть несколько заблуждений, которые я считаю нужными устранить.

Прежде всего, mod_php работает лишь незначительно, все мои тесты показали, что разница настолько незначительна, что ее не стоит учитывать. Я также сомневаюсь, что аспект безопасности важен для вас, поскольку вы, похоже, смотрите на выделенный сервер и На самом деле mod_php имеет преимущество только в общей среде - фактически, в выделенной среде php-fpm будет иметь преимущество, так как PHP и ваш веб-сервер теперь работают как разные процессы, и это даже не учитывает великолепные параметры ведения журналов в php- fpm, такие как медленный журнал.

Если бы мир был черно-белым, я бы сказал, что нужно просто установить nginx и скомпилировать php с php-fpm. Более реалистично, если у вас уже работает Apache, тогда сделайте nginx обратным прокси-сервером для Apache, и вы можете сэкономить несколько часов времени на настройку, и разница в производительности будет крошечной.

Но давайте предположим, что мир на секунду черно-белый, потому что это делает его намного более удивительным. Вы делаете nginx + php-fpm для своего веб-сервера. Для решения загрузки вы используете модуль загрузки и модуль загрузки для nginx. Это означает, что ваш веб-сервер принимает загрузку и передает путь к файлу на PHP, когда это будет сделано, поэтому файл не нужно передавать между nginx и PHP по протоколу fastcgi, сладкий. (У меня есть это в живой настройке, и это прекрасно работает, кстати!)

Для загрузки пользователей вы используете функцию x-send-file-nginxs, называемую x-accel-redirect, по сути, вы выполняете аутентификацию в PHP и устанавливаете заголовок, который nginx обнаруживает и начинает передавать этот файл. PHP заканчивает выполнение, и ваш веб-сервер обрабатывает передачу, милый! (Опять же, у меня есть это в живой настройке, и она отлично работает)

Для распределения файлов по серверам или других длительных операций мы понимаем, что PHP на самом деле не подходит для этого лучше всего, поэтому мы устанавливаем gearman, который является сервером заданий, который может распределять задания между работниками на разных серверах, эти работники могут быть записаны на любом язык. Поэтому вы можете создать дистрибутивный работник и создать 5 из них, используя в общей сложности 200 КБ памяти вместо 100 МБ, которые PHP использовал бы. Милая. (У меня также есть это работает вживую, так что все это на самом деле возможно)

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

Я очень рекомендую nginx, но я также думаю, что вам следует поискать другие варианты решения других проблем: если у вас проблемы с масштабированием или производительностью, напишите мне. Я не знаю, можете ли вы отправлять здесь сообщения, но в противном случае напишите мне по адресу martin@bbtn.us, так как я не преследую ошибку сервера для всего, что не помечено nginx. :)


1
Черт, это действительно прояснило :) спасибо, это было объяснение, которое я искал. Я думаю, что я довольно продвинулся в изучении Nginx, так как Apache задохнется и умрет, используя мой сайт. К счастью, все выглядит очень просто. Я имею в виду, что люди в node.js говорят, что пишут большинство вещей в этом и опрашивают ваш сеансовый класс php, только если вам это действительно нужно (что я делаю, если только нет способа определить, когда пользователи закрывают свои окна: P). Да, я работаю на огромной серверной ферме, поэтому знание того, что угрозы безопасности нет, помогает тоннам, спасибо за отличное объяснение :)
Sammaye

Я смотрел на это: joeandmotorboat.com/2008/02/28/… и это: blog.webfaction.com/a-little-holiday-present, и это действительно заставило меня шутить при мысли о возможности долго опрос к содержанию моих сердец действительно. Ни одной проблемы с памятью в отличие от Apache :)
Sammaye

Подожди, ты сказал, что я мог бы сделать многопоточный рабочий в Java, и PHP может обойти это прекрасно? Я имею в виду, что самая большая проблема, которую я вижу, это сервер, так как у меня возникают серьезные проблемы с памятью в Apache с использованием длинного опроса, который является обычным ... ofc исправленным Nginx.
Саммайе

1
По сути, да, у меня есть работники по распространению файлов, написанные на C, с использованием расширения gearman для PHP. Я отправляю задание на распространение на сервер заданий gearman, и оно отправляет его работнику, который может быть написан на любом языке; PHP, Java, C и т. Д. Затем этот работник выполняет свою работу и сообщает о статусе механизму, который сообщает PHP. (если не было выбрано фоновое задание, в этом случае PHP заканчивается, не дожидаясь его)
Martin Fjordvald

2
Я знаю, что это старая публикация, но я должен сказать, что это одна из самых информативных публикаций, которые я нашел по теме nginx vs apache. Мартина, +1.
Akoi Meexx 21.12.12

5

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


Да, это то, что большинство людей, кажется, делают в атм, мне определенно придется посмотреть на это :)
Sammaye

1
Не забудьте установить mod_rpaf для Apache, чтобы вы могли проходить через клиентские IP-адреса для целей ведения журнала (в противном случае журналы Apache будут отображать все запросы как от 127.0.0.1), добавьте следующее в конфигурацию nginx: proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for;
Грег Аннандейл

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

1

Я не уверен, что mod_php быстрее, чем его альтернативы, где вы это прочитали? Я провел некоторые лабораторные испытания с nginx + php-fpm, и, насколько я понял, он превосходит все остальные настройки.

Взгляните на эту настройку: http://interfacelab.com/nginx-php-fpm-apc-awesome/

Я настроил его почти так же, за исключением того, что я использую пакеты PHP из http://www.dotdeb.org/ - которые включают пакет php-fpm и готовый к использованию скрипт init. Я не использую memecache или syck.


stackoverflow.com/questions/78108/… получил его отсюда, и я проверил руководство php, и там действительно говорится, что php_mod обеспечивает значительное преимущество перед версиями cgi. Ваша установка выглядит хорошо. Это выглядит очень просто. Я посмотрю на это :)
Sammaye

2
В нем говорится, что CGI намного медленнее, чем встроенный модуль - не FastCGI :)
pauska

1
Что ж, если вы беспокоитесь о том, что процесс PHP умирает (или время ожидания истекает), тогда FastCGI (или PHP-FPM) - это то, что вам нужно. Это может убить мертвых дочерних процессов, не прерывая другие действия.
Пауска

1
Да. Или, ну, это зависит. Сколько (максимальное) количество медленных запросов вы будете обрабатывать одновременно? Установите максимальное число потоков PHP FPM плюс количество «быстрых» cgi, которые вы хотите получить. Я слышал о людях, использующих 200 дочерних элементов PHP-FPM на сервере с 4 ГБ ОЗУ, поэтому я бы не стал сильно беспокоиться об этом на вашем месте. Следующая версия PHP (5.3.3) будет включать стандартную версию PHP-FPM, где также имеется механизм добавления - он будет масштабироваться в зависимости от того, сколько запросов вы ожидаете.
Пауска

1
Я бы легко работал на нескольких серверах (может быть, до 10), но если бы я мог разместить 200 запросов, которые можно долго опрашивать на сервере 4 ГБ, это должно было бы составить почти половину от 20 серверов, которые мне понадобились бы для работы Apache. хмммм ... мне нужно будет проверить это сегодня вечером
Sammaye
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.