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

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

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

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

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

Пока этот автор сравнивает mod_php с fcgid, я ищу тот же тип всеобъемлющего, реального взгляда на мир Apache vs Nginx.

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

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

46 голосов | спросил blue928 30 AMpTue, 30 Apr 2013 02:01:04 +040001Tuesday 2013, 02:01:04

5 ответов


60

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

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

Ответ гораздо длиннее:

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

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

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

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

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

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

Некоторые другие примечания:

  1. В DrupalCon Copenhagen keynote , создатель PHP Rasmus Lerdorf , используя сам 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 , где только этот вопрос возник. Все ответы о том, что выбрать, не были связаны с производительностью. Такие вещи, как «Какой из них вы уже знаете, как настроить», и «Какой из них позволит вам создать простейший технологический стек», былисреди упомянутых причин, чтобы выбрать другой. Производительность not вводит изображение.
ответил Letharion 3 Maypm13 2013, 17:53:37
31

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

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

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

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

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

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

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

 Использование памяти

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

 Запросы в секунду

Источник: ApacheBench, dreamhost. ком

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

ответил Quandary 3 J0000006Europe/Moscow 2013, 23:21:50
16

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

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

Drupal с кешем

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)

Apache

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

Drupal с кешем и boost

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

Apache

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

Apache

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

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

ответил flocondetoile 2 Maypm13 2013, 20:38:49
0

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

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

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

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

ответил Hawkeye 1 Maypm16 2016, 22:05:10
0

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

вот вывод этого теста:

  

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

ответил wathmal 30 Maypm16 2016, 22:55:48

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132