Nginx против Apache. Существуют ли какие-либо фактические сравнения использования и статистика?

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

Когда я ищу статьи, я могу найти много вещей, не связанных с Drupal. Или, когда я сталкиваюсь со статьей, связанной с Drupal, это либо 1) чей-то конфигурационный файл с быстрой попыткой объяснить, как его настроить, либо 2) кто-то говорит «нет, не используйте nginx, переходите на Apache с PHP fcgid ", но никогда не бывает объяснений, почему.

Итак, когда дело доходит до Drupal, какова здесь реальность?

В качестве примера, я ищу что-то похожее на эту статью 2bits.com . Здесь автор довольно подробно рассмотрел Apache mod_php против Apache с помощью fcgid, взвесив все за и против каждого из них, и предоставил пример для иллюстрации воздействия в реальном мире. В этой статье достаточно информации, чтобы я мог принять обоснованное решение о том, какой подход лучше всего подходит для моей ситуации.

Хотя этот автор сравнивает mod_php с fcgid, я ищу тот же тип всестороннего реального взгляда на Apache vs Nginx.

Кто-нибудь переключился на Nginx и был «поражен» различием, которое он сделал по сравнению с Apache? Даже для высокооптимизированных сред, в которых уже используются APC, Memcache и агрессивное кэширование, например, Varnish, когда единственная изменяемая переменная - это замена Apache на Nginx, она сама по себе достаточно для того, чтобы вложить средства в эту более новую альтернативную технологию. ?

Сайт, который будет работать на этом сервере, получает в среднем 2 миллиона PV в месяц. Стек LAMP под управлением Cent OS 6. 4-ядерный процессор с 8 ГБ оперативной памяти. Memcached и APC будут частью микса. Ничего особенного в установке Drupal - в основном vanilla 7 с около 50 модулями.

Строго говоря, это не отвечает на вопрос, который вы задаете. Я надеюсь, что это все равно полезно.

Apache / Nginx / Lighttpd / другой веб-сервер. Имеет ли значение, какой я выберу? Короче нет .

Гораздо более длинный ответ:

Если и только если, у вас очень большой процент пользователей, вошедших в систему, если вы вообще заботитесь о производительности вашего веб-сервера. Если ваши пользователи являются анонимными, любое различие, которое вы теоретически можете получить из оптимизации абсолютных значений на этих слоях, по сравнению с улучшением кэширования ваших ресурсов. Если ваши CSS-файлы имеют надлежащие заголовки кэша, UA даже не будет запрашивать их во второй раз. Это важно Если вы можете кэшировать свои страницы в Varnish или аналогичном программном решении, то для обслуживания этой страницы нужно выполнить поиск по хешу, а затем вернуть большой кусок данных непосредственно из ОЗУ. Это важно В обоих этих сценариях демон HTTP даже не задействован, PHP не вызывается. Drupal не запускается. В ОЗУ не нужно загружать большой набор модулей, не требуются длительные запросы к базе данных.

Когда вы выполняете полную загрузку страницы из холодного кэша для зарегистрированного пользователя на сложной странице; много чего происходит. Да, веб-сервер занимается обработкой входящего запроса, установкой некоторых заголовков и передачей ответа обратно. Но время, которое требуется, даже не имеет значения в контексте Drupal, запускающего полную загрузку и выводящего его ответ. Могут выполняться сотни запросов к базе данных. Очень сложная логика в PHP оценивается парсером. Многие модули загружаются в оперативную память. Улучшение производительности любой из этих вещей, гораздо более вероятно, внесет серьезный вклад в производительность.

Ради аргумента: допустим, вы потратили много времени на оптимизацию всего остального.

1. Вы запускаете APC (или Optimizer + ) и самую последнюю и самую быструю версию PHP.
2. БД-запросов немного.
3. Логика PHP была уменьшена.
4. Вы кешируете, что можете в Varnish.
5. Вы реструктурировали весь свой сайт, так что вы можете кэшировать большое количество клиентской части и выполнять тяжелую работу в ECMAScript .

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

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

Некоторые другие заметки:

1. Во время выступления на DrupalCon Copenhagen создатель PHP Расмус Лердорф , используя сам Nginx, говоря о производительности Drupal, сказал: «Люди всегда спрашивают меня о веб-серверах ... это действительно не имеет значения, веб-сервер в значительной степени не имеет значения» , (Примерно в 26:30 на видео)
2. Facebook потратил бесчисленные часы на написание Hiphop , кодовой базы значительно большей, чем сам Drupal, для ускорения PHP-кода на «жалкие» 100%. Я изучил Hiphop $ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1и обнаружил, что он состоит из 1,512,481 строк кода. Это абсолютно безумный объем работы по улучшению скорости PHP. Я предполагаю, что это потому, что скорость PHP очень важна для них.
3. Я упоминал, что хорошее кэширование будет иметь гораздо больший эффект, чем настройка веб-сервера?
4. С выпуском Apache 2.4 Джим Ягельски утверждает, что Apache 2.4 работает быстрее, чем серверы на основе событий .
5. Я обратил внимание на производительность и масштабируемость Drupal с командой Dream Team , где и возник этот вопрос. Все ответы о том, что выбрать, не имели отношения к производительности. Такие вещи, как «Какую из них вы уже знаете, как настроить» и «Какая из них позволит вам создать простейший технологический стек», были среди упомянутых причин, чтобы выбрать другую. Спектакль не вошел в картину.

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

Разница между Apache и nginx заключается не в том, «насколько быстро они могут обслуживать запрос», а в том, сколько запросов они могут обслуживать на одном и том же количестве оборудования (особенно при ограниченных ресурсах), что несколько иное.

Apache - это сервер на основе процессов. Это означает, что процесс разветвляется на каждый запрос. Nginx - это сервер, основанный на событиях, то есть он использует (асинхронный) цикл событий вместо процессов или потоков.

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

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

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

Общий объем памяти, используемый X одновременными подключениями (чем меньше, тем лучше)

Запросы, которые можно обслуживать в секунду при одновременных подключениях X на 1 наборе оборудования (чем больше, тем лучше)

Источник: ApacheBench, автор dreamhost.com

Смотрите также это цифровое океанское издание.
Очевидно, это зависит от архитектуры обработки соединений, которую вы выбираете для Apache.

Я перешел с Apache на Nginx / PHP-FPM несколько месяцев назад.

Я сделал несколько тестов на сайте drupal и протестировал несколько вариантов использования. На VPS-сервере с 1 ЦП и 512 МО оперативной памяти

Друпал только с кешем

Nginx

ab -n 100 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.775 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2529500 bytes
HTML transferred:       2490200 bytes
Requests per second:    36.04 [#/sec] (mean)
Time per request:       832.394 [ms] (mean)
Time per request:       27.746 [ms] (mean, across all concurrent requests)
Transfer rate:          890.28 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 48.946 s

Connection rate: 2.0 conn/s (489.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 470.6 avg 489.5 max 522.2 median 488.5 stddev 9.5
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 10.000

Request rate: 20.4 req/s (48.9 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 20.0 avg 20.4 max 20.8 stddev 0.2 (9 samples)
Reply time [ms]: response 46.8 transfer 2.1
Reply size [B]: header 450.0 content 24902.0 footer 2.0 (total 25354.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.50 system 17.58 (user 13.3% system 35.9% total 49.2%)
Net I/O: 507.3 KB/s (4.2*10^6 bps)

апаш

ab -n 100 -c 30 xxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   28.364 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25346000 bytes
HTML transferred:       24902000 bytes
Requests per second:    35.26 [#/sec] (mean)
Time per request:       850.918 [ms] (mean)
Time per request:       28.364 [ms] (mean, across all concurrent requests)
Transfer rate:          872.66 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 52.261 s

Connection rate: 1.9 conn/s (522.6 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 499.0 avg 522.6 max 591.0 median 518.5 stddev 19.4
Connection time [ms]: connect 0.6
Connection length [replies/conn]: 10.000

Request rate: 19.1 req/s (52.3 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 18.2 avg 19.2 max 19.6 stddev 0.5 (10 samples)
Reply time [ms]: response 46.9 transfer 5.3
Reply size [B]: header 453.0 content 24902.0 footer 2.0 (total 25357.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.80 system 18.88 (user 13.0% system 36.1% total 49.1%)
Net I/O: 475.2 KB/s (3.9*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Друпал с кешем и бустом

Nginx

ab -n 10000 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   2.275 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      253780000 bytes
HTML transferred:       250020000 bytes
Requests per second:    4395.52 [#/sec] (mean)
Time per request:       6.825 [ms] (mean)
Time per request:       0.228 [ms] (mean, across all concurrent requests)
Transfer rate:          108934.95 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 5.971 s

Connection rate: 167.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 13.0 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 5024.0 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 5017.2 avg 5017.2 max 5017.2 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.79 system 2.56 (user 13.2% system 42.9% total 56.1%)
Net I/O: 125016.7 KB/s (1024.1*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

апаш

ab -n 1000 -c 30 xxxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   0.753 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25291000 bytes
HTML transferred:       25002000 bytes
Requests per second:    1327.92 [#/sec] (mean)
Time per request:       22.592 [ms] (mean)
Time per request:       0.753 [ms] (mean, across all concurrent requests)
Transfer rate:          32797.26 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 1.148 s

Connection rate: 87.1 conn/s (11.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 6.2 avg 11.5 max 14.1 median 11.5 stddev 1.3
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 10.000

Request rate: 870.8 req/s (1.1 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 1.1 transfer 0.1
Reply size [B]: header 260.0 content 25002.0 footer 0.0 (total 25262.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.13 system 0.57 (user 11.1% system 49.5% total 60.6%)
Net I/O: 21544.9 KB/s (176.5*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

тест для аутентифицированного пользователя (загрузка страницы)

Nginx

Page load times : 2.85 s

апаш

Page load times : 5.4 s

Но сила Nginx в системе кеша

Drupal без Boost и Nginx с включенной кеш-системой

Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.437 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      252670000 bytes
HTML transferred:       249020000 bytes
Requests per second:    4103.34 [#/sec] (mean)
Time per request:       7.311 [ms] (mean)
Time per request:       0.244 [ms] (mean, across all concurrent requests)
Transfer rate:          101248.99 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 6.044 s

Connection rate: 165.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 11.7 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 4963.7 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 4970.1 avg 4970.1 max 4970.1 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.72 system 2.68 (user 12.0% system 44.3% total 56.3%)
Net I/O: 123516.8 KB/s (1011.8*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Вы должны использовать конфигурацию Perginio Nginx для Drupal

Вот тест производительности для десяти веб-серверов / вариантов (например, Apache, Nginx, lighttpd, Lightspeed, Hiawatha, Cherokee). Три из тестов относятся к Drupal.

Я думаю, что Hiawatha может быть лучшим выбором. Предполагается, что он полностью совместим с Drupal , уделяет особое внимание безопасности (DoS, XSS, CSRF, предотвращение SQL-инъекций) и скорости и занимаемой площади, аналогичной Nginx.

В двух из трех тестов Drupal и Hiawatha, и Nginx превосходят Apache примерно на 150%, но в статическом тесте Drupal Apache незначительно превосходит Nginx, тогда как Hiawatha превосходит пакет примерно на 10%.

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

Вот результаты нагрузочного тестирования для drupal, работающего на том же оборудовании, но на разных веб-серверах. (nginx и apache)

вот заключение этого теста:

при большом трафике с теми же аппаратными ресурсами nginx работает лучше, чем apache.