Що не вистачає Nginx, що має Apache?


11

Кажуть, що Nginx набагато більш економічно використаний та простіший у налаштуванні, ніж Apache. Друг сказав мені, що "він не може робити те, що може зробити Apache, але мені це все одно не потрібно".

І все-таки мені цікаво: які речі може зробити Apache, що Nginx не може? Мені не потрібен вичерпний список, просто загальне уявлення про сценарії, де Apache був би кращим вибором.

Відповіді:


9

Я думаю, що найбільших фрагментів, які ще відсутні у Nginx, є повна підтримка WebDAV. В основному кожен інший аспект охоплюється або ядром, або стороннім модулем.

Nginx не підтримує такі речі, як mod_php за дизайном, тому я не впевнений, що ви можете сказати, що в Nginx відсутні ці частини. Це більше схоже на те, що Nginx досить наполегливо каже тобі, що використовувати це нерозумно.


+1 Хоча я не погоджуюся з тим, що кожне використання mod_php та подібних речей є "дурними", я згоден з рештою.
Кріс S

Це коментар до php-ненависників чи щось по-справжньому погано в моді_php? Посилання? Я прошу, тому що майже все, що у мене є, використовує mod_php .. і, будь ласка, мені все одно, що ви вважаєте, що краще, я хотів би просто знати, що не так з mod_php
Safado

3
mod_php не має нічого спільного з самим PHP. Це стосується того, як PHP взаємодіє з Apache. Проблема полягає в тому, що коли ви вбудовуєте PHP в Apache, процес, який обробляє PHP, і процес, який обробляє файл зображення 2 кб, - це той самий процес. Якщо кінцевий клієнт повільний, то ваш дуже дорогий процес може подавати невелике зображення протягом 2 секунд, це час, який він не може витратити на PHP.
Мартін Фьордвальд

+1 "Це більше схоже на те, що Nginx досить наполегливо каже вам, що використовувати це нерозумно".

4

У Apache є велика кількість модулів, які дозволяють використовувати деякі сценарії розгортання, які неможливі з Nginx.

Один із прикладів - mod_dav_svnрозміщення Subversion через HTTP. Він доступний лише для Apache. Інші відомі приклади речі , як mod_perlабо mod_php. Хоча більшість традиційних налаштувань також можна здійснити через FCGI (або WSGI, або пасажир), наявність фактичного перекладача в процесі може бути корисним, якщо вам потрібно, наприклад, реалізувати власні схеми аутентифікації всередині веб-сервера (наприклад, це робиться для хостингу git або svn за допомогою Redmine / ChiliProject).

Як правило, ваш друг правий: найчастіші сценарії розгортання також можна вирішити за допомогою nginx, але Apache все ж є більш гнучким, якщо вам доведеться створити ще якісь "спеціальні" речі.


3

Коротка версія історії полягає в тому, що в Apache є багато плагінів та спільноти, створеної навколо нього. Nginx, існує лише короткий час порівняно, тому він ще не має кодової бази спільноти.

Коли люди запитують мене, в чому різниця, Nginx - це стейк-нож, він хороший для різних цілей використання і робить деякі речі надзвичайно добре. Apache - це швейцарський армійський ніж, він має багато різних можливостей і робить їх усі досить добре.


Я думаю, що ви можете трохи застаріти в тому, що може зробити Nginx, в деяких областях це набагато універсальніше, ніж Apache. Не вистачає HTTP / 1.1, що підтримує доступ до WebDAV, я не можу придумати багато речей, яких йому не вистачає.
Мартін Фьордвальд

@MartinFjordvald Існує досить багато функцій, які Nginx навмисно вирішив не робити, ви не можете сказати, що вони "відсутні", але ви не можете стверджувати, що Nginx може робити все, що може Apache. Це компроміс, і я аплодую Nginx за зроблений ними вибір.
Chris S

Так як мій оригінальний коментар HTTP / 1.1 проксі тепер підтримується, тому ми перебуваємо на веб-хості та svn хостингу, які не підтримуються. Тобто, якщо ми не розглядаємо такі питання, як динамічно пов'язані модулі, це правда, що nginx вирішив поки що не робити.
Мартін Фьордвальд

1

Для запуску багато модулів та встановлену вишукану базу. Але не зовсім те, що має Apache , на що слід дивитись, це те, що робить Apache : він працює набагато краще, щоб обслуговувати динамічний контент, як PHP, Python, Perl, Java тощо.

Звичайно, ви можете це зробити і з Nginx (але це трохи хакерський IMHO), але рішення є набагато більш перевіреними та зрілими, що працюють на Apache, ніж на NginX, що, в свою чергу, набагато краще, ніж Apache при обслуговуванні великих навантажень і чудово переписувач / зворотний проксі.

Для кожної роботи - правильний інструмент!


Можливо, це було правдою до 2008 року, коли я вперше розгорнув nginx на виробничому веб-сервері, але зараз це здається не таким. Я хотів би розширити, чому ви вважаєте, що модель Apache щодо включення перекладачів на веб-сервер краща.
Майкл Хемптон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.