Почему стоит переходить на использование nginx?

[@nps]

>Есть много “за” и “против”.
Так давайте и второе перечислите, для большей объективности)

[@akeepaki]

Как-то очень поверхностно. И даже не указано, с чего стоит переходить на nginx =). С каким веб-сервером хоть сравниваете? :)

[@rapaman]

Статься абстрактная, критикуйте, и я дополню, я не претендую написать книгу по этому вопросу ;)

[@rapaman]

Это не сравнение, иначе бы было указано в заголовке.

[@n1mnul]

> снизить потребление bandwith, за счет сжатия контента (кому критично вписаться в лимиты хостинга)

zomfg, сбейте меня камнем.

[@rapaman]

а что такое zomfg, если не секрет?

[@Regis]

JFGI

[@Regis]

Если вы противопоставляете nginx апачу — то это заведомо неправильный подход. Это просто разные вещи.

Другое дело, если преподносить это как «не используйте Apache там, где то же самое может лучше делать nginx», тогда да, я с вами соглашусь. Но в этом случае думаю стоило бы привести цифры, чтобы «повпечатлялись и осознали». А так… Пока статья не вызывает горячего желания что-либо менять :)

[@tshaoni]

Можете сбить и меня палкой, но nginx'у я предпочту lighttp. Там и FastCGI есть, и по производительности он не хуже nginx…

[@barbuza]

а в нгинксе по вашему нет fastcgi ?)

[@vosi]

а еще php-fpm

[@Rusan]

А зачем не хуже, когда есть лучше?

[@yuretsz]

Ну хорошо, что лучше?

[@Rusan]

не-не-не Девид Блейн, я не поведусь на эту разводку на holy war — Лучшее, это то что для данной задачи будет лучшим. Хотите выяснить — читайте интернет или проводите собственные перфоманс тесты (ну или что там важнее для вашей задачи — например надёжность тесты).

[@mgyk]

Это не замена апачу (огромное количество модулей для которого позвоняет использовать его практически с любым окружением), а специализированный вебсервер которого в некоторых случаях вполне достаточно.
Вот список того, что лично я использую в nginx
1) Nginx умеет проксирование и балансировку трафика между несколькими бэкэнд серверами с приоритетами и кэшированием ответов.
2) Умеет напрямую забирать данные из memcached
3) Ограничение полосы пропускания для пользователей
4) Очень быстрая раздача статики. Возможность раздачи через X-Accel-Redirect, то есть когда контроль доступа к фаилу работает на строне приложения.
5) По сравнению с lighttpd — вменяемый конфиг

[@elanc]

Хотелось бы заметить, что использование .htaccess само по себе зло, ведь это приводит к регулярному чтению этого файла при каждой обращении к странице. Понятно, что перезапускать сервер после каждого изменения слишком накладно, но… Так что этот пункт скорее относится к полуминусам.
А насчет перехода — лично я считаю, что nginx хорош для обратного проксирования/кеширования, но как backend мне он не кажется самодостаточным. Хотя можно выделить fastcgi…

[@mgyk]

Совершенно согласен по поводу .htaccess. Текущая тенденция в фреймворках, когда все реврайты выносятся в конфиг фреймворка (rails/django) очень радует.
Насчет использования в качестве бэкэнда: используется сейчас вместе с php через fastcgi. Впечатления очень положительные.

[@yuretsz]

Хотелось бы увидеть сравнение nginx с lighttpd, с апачем-то все давно понятно.

[@yuretsz]

Ну не двухгодичной же давности.

[@rapaman]

как перестанут загонять мои значения в «минус», так я и смогу писать что-то новое, а иначе — не могу, не позволяет habr.