nginx vs apache vs ...

модераторам: в толкс, потому как вопрос не совсем технический, но если что не так, переносите по вашему усмотрению

суть в том, что мне его выдал админ

Это и есть обоснование. А дальше накручиваешь корпоративные политики безопасности, обновления, администрирования и тд.

Если ты сразу начнешь писать про хайлоад в этом пункте, не факт, что твой проект настолько уж хайлоадный. Но упомянуть стоит и об этом.

Ну и поговори с одмином, чо, он тебе наговорит...

Чтобы не было оверхеда. nginx же так и так нужен (статику отдавать).

Это и есть обоснование.

Завкаф не считает такое обоснование обоснованием, к сожалению

nginx же так и так нужен (статику отдавать).

apache этого не умеет?

Сам в этой теме как свинья в апельсинах, пардон.
У них совершенно разная архитектура, apache на каждого клиента создает отдельный процесс или поток, на выбор. Это создает проблемы в случае клиентов с медленными каналами, когда создаются дофига процессов/потоков, которые по факту ничего не делают, только память отжирают. Nginx использует более совершеный способ работы с сетью, когда один поток может работать с несколькими соединениями, плюс в периоды с вот такими медленными клиентами он просто спит, используя процессор по минимуму. Была хорошая статья, забыл, где, ну вот хотя бы такая http://www.slashroot.in/how-is-nginx-different-from-apache
Ещё можешь сослаться на отчеты неткрафта о бурном росте популярности nginx.

Apache выступает как сервер приложений.
В качестве web сервера apache плохо подходит для большого количества одновременных пользователей.

Тут надо сразу определиться, что под apache обычно понимают prefork модель, где каждый запрос обрабатывается отдельным процессом в операционной системе. При такой схеме каждый процесс апача обрастает уникальными от других процессов буферами и использует довольно много памяти при одновременной обработке нескольких тысяч запросов.
Т.к. процессорных ядер довольно мало по сравнению с предельным количеством одновременных запросов то возникают два решения:
1) обрабатывать все запросы одновременно и получать большие накладные расходы по переключеню контекста задач
2) поместить все «лишние» соединения в backlog. В этом случае есть шанс что 100 медленных клиентов на модеме рано или поздно все воркеры забиваются и все клиенты получают ответы со скоростью модема (за 15-60 секунд, даже если процессоры/диски/БД не загружены).

Ситуация не так печальна с thread моделью апача, особенно если мы отключим неиспользуемые модули и проблемы с Keep-Alive можно решить с event-mpm. На практике многопотоковый апач практически не используется, потому что качество кода языков под апач не позволяет работать без постоянных sigsegv под нагрузкой.


nginx выступает как промежуточное звено между приложением и клиентами, обеспечивая:

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

Где можно получить преимущества?
- VPS, потому что мало памяти, экономим на тарифе
- большой shared хостинг, потому что это как очень нагруженный сайт с большим количеством медленных клиентов

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

Где здесь подвох?
- nginx плохо проксирует большие файлы: вместо того чтобы по-тихому в апача через sendfile отдавать файл на несколько гигабайт, файл надо не только считать с диска но ещё и записать во временную папку и потом опять считать. Проблема решается только при изменении приложения через X-Accel-Redirect
- Дополнительное звено в обработке, лишний парсинг HTTP, мы как бы обрабатываем два http запроса вместо одного со всеми проверками и сетевыми/«сетевыми» задержками. Чтобы решить и эту проблему используют fastcgi/uwsgi. На практике приложения настолько тормозные, что эта задержка не заметна. Если приложение работает на libevent или подобных, то смысла в дополнительной задержки в виде nginx нет (ну разве что мы не уверены в приложении, а nginx на безопасность много народу тестируют).

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

спасибо большое за подробный ответ.

Он делает это гораздо медленнее.

Выбором национального продукта а не продукта вероятного противника?

Скорее уточнение вышеотписавшихся ораторов: Nginx способен решить проблему C10k из-за использования epoll (Linux)/kqueue (FreeBSD).

Подробнее про проблему C10k («10 000 одновременных коннектов») — здесь http://www.kegel.com/c10k.html или здесь (http://www.opennet.ru/base/faq/prog_faq.txt.html см. вопрос «Как писать сервера»).

Поэтому обычно на фронтэнд ставят Nginx, который отдает статику, спокойно держит over9000 соединений, защищает бэкэнд от медленных пиров и ещё является failover'ом, раскидывая запросы по разным бэкэндам.

на каждого клиента создает отдельный процесс или поток, на выбор

От платформы зависит, ЕМНИП. На венде создаёт потоки, на линуксе — процессы.

интересно, почему Apache этого не умеет. Они же таких сложных штук понаписали, а пул для стратики пофиксить не могут?

А что бы написали вы, обосновывая выбор nginx перед apache?

легкий, быстрый, фичастый. на одном и том же железе nginx + php-fpm обрабатывает в разы больше запросов чем apache + любой-php. про статику уже сказали.

подозреваю, что из-за htaccess.
это для nginx всё то статика, что явно не динамика. а в апаче можно положить в какой-нибудь каталог со статикой htaccess, который заворачивает все запросы на какой-нибудь пыхпых, который генерит thumbnail и выдает ответом на запрос. в этом плане гибкость апача конечно бывает полезна, но значительно усложняет обработку запроса.
чтобы убедиться сколько *уиты выполняет апач на каждый запрос - достаточно включить server-info и посмотреть секцию Request Hooks. смотрел я сорцы апача, обработка htaccess сделана жутко непонятным образом.

Умеет, но только для keep-alive в многопоточной модели: http://httpd.apache.org/docs/2.4/mod/event.html

Sendfile для статики тоже умеют: http://httpd.apache.org/docs/2.4/mod/core.html#enablesendfile

Посылка файлов может происходить без переключения контекста на процесс/поток апача и переключение контекста становится не таким страшным.
nginx sendfile в нагруженных случаев не может использовать, потому что sendfile может блокироваться на время IO операции в linux, поэтому nginx будет работать через aio и чтение в буфер.
Т.е. проблема не такая яркая как кажется и что с nginx что без nginx примерно до 60-80к уников в сутки апач справляется если памяти достаточное количество даже в prefork, а так же требует не так много памяти в worker/event mpm.
Nginx так же не едиственный http сервер решающий c10k, ещё до появления nginx был lighttpd. lighttpd воспринимался как решение для совсем огромных сайтов, потому что на ab и hello world преимуществ не давал, а больше 100к уников могли похвастаться только считанные сайты в рунете.

А что бы написали вы, обосновывая выбор nginx перед apache?

nginx легче и производительней.

А что бы написали вы, обосновывая выбор nginx перед apache?

А ровно ничего. Если хоть что-то написать на тему «почему не Apache», то за это будут цепляться и на защите завалят. Тут IMHO будет правильнее показать, что Apache и Lighttpd тоже подошли бы (только предварительно проверить на localhost'е), и свести выбор к очевидному вопросу «взять готовый HTTP-сервер со статикой и приложениями, или написать свой велосипед».

От платформы зависит, ЕМНИП. На венде создаёт потоки, на линуксе — процессы.

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

Как раз давеча читал это. Боян, но для объяснительной сойдет.

но ведь это далеко не всегда работает -

nginx - это ведь только для отдачи картинок, и больше ничего, а вот Apache - проверенное временем решение.