Nginx vs 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 проти Nginx.

Хтось перейшов на Nginx і був "здутий" різницею, яку він зробив порівняно з Apache? Навіть для високооптимізованих середовищ, які вже використовують APC, Memcache та агресивне кешування, як Varnish, коли єдина змінна, що змінюється, замінює Apache на Nginx, робить достатньо різниці і сама по собі, щоб заслужити інвестиції в цю нову альтернативну технологію ?

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

Строго кажучи, це не відповідає на запитання, яке ви задаєте. Я сподіваюся, що це все одно корисно.

Apache / Nginx / Lighttpd / інший веб-сервер. Чи має значення, яку я вибираю? Словом, ні .

Значно довша відповідь:

Якщо і тільки якщо, у вас дуже великий відсоток користувачів, які ввійшли в систему, якщо ви взагалі переймаєтесь роботою вашого веб-сервера. Якщо ваші користувачі анонімні, будь-яка різниця, яку ви можете теоретично отримати від оптимізації на цих шарах абсолютних блідих в порівнянні з тим, щоб зробити ваші ресурси краще кешованими. Якщо у ваших файлах css є відповідні заголовки кешу, UA навіть не запитає їх удруге. Це має значення. Якщо ви можете кешувати свої сторінки в Varnish або подібному програмному рішенні, то розміщення цієї сторінки - це питання провести хеш-пошук, а потім повернути великий фрагмент даних безпосередньо з оперативної пам'яті. Це має значення. В обох цих сценаріях демон HTTP ніколи навіть не бере участь, PHP не викликається. Drupal не завантажується. Великий набір модулів не повинен завантажуватися в оперативну пам’ять, не вимагаються багато часу запити до бази даних.

Коли ви виконуєте повне завантаження сторінки, із холодного кешу, для користувача, який увійшов, на складній сторінці; багато чого відбувається. Так, веб-сервер бере участь у розгляді вхідного запиту, встановленні деяких заголовків і передачі відповіді назад. Але час, який забирає, навіть не є актуальним у контексті того, що Drupal виконує повний завантажувальний запуск та видає свою відповідь. Можуть виконуватися сотні запитів до бази даних. Високо складна логіка в PHP оцінюється парсером. Багато модулів завантажуються в оперативну пам'ять. Поліпшення продуктивності будь-якої з цих речей набагато більше шансів зробити серйозний внесок у результативність.

Для аргументу: Скажімо, ви витратили багато часу на оптимізацію всього іншого.

1. Ви запускаєте APC (або оптимізатор + ) та останню та найшвидшу версію PHP.
2. БД-запитів небагато.
3. Логіка PHP знижена.
4. Ви кешуєте, що можете в лаку.
5. Ви переструктурували весь свій сайт, щоб ви могли кешувати багато клієнтської сторони і робити багато важких підйомів в ECMAScript .

Якщо у вас багато користувачів, які ввійшли в систему, і ви розібралися з усім вищезазначеним, ви, ймовірно, можете змінити, але налаштування продуктивності або заміна вашого веб-сервера. Однак вгадайте, що. Ваш сайт настільки складний, а моделі використання ваших конкретних користувачів унікальні . Загальної відповіді немає. Вам потрібно буде встановити всі різні веб-сервери за балансиром навантаження та подивитися, як вони поводяться за вашим сценарієм .

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

Деякі інші примітки:

1. Під час виступу у Копенгагені DrupalCon , автор 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 разом із The Dream Team , де якраз виникло це питання. Усі відповіді щодо того, який вибрати, не мали відношення до продуктивності. Такі речі, як "Який із них ви вже знаєте, як налаштувати" та "Який із них дозволить вам створити найпростіший стек технологій", були однією з причин, про які йдеться вище. Виступ не ввійшов у картину.

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

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

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

І хоча сервер на основі процесів (наприклад, Apache) може виконувати більш-менш нарівні з асинхронним сервером на основі подій (наприклад, nginx) при невеликих навантаженнях, при більш великих навантаженнях, наприклад, одночасно 10'0000 запитів, nginx використовує лише декілька мегабайт оперативної пам’яті, тоді як Apache вимагає декількох сотень мегабайт лише для веб-сервера (не включаючи веб-додаток, який потребує набагато більшої кількості ресурсів), якщо він взагалі може це зробити.

Тож при більш важких навантаженнях ви побачите, що Apache споживає набагато більше оперативної пам’яті, що не дивно погіршує продуктивність.

Більш істотно, що більший обсяг оперативної пам’яті означає, що Apache може обслуговувати менше запитів на одне і те ж обладнання, ніж nginx, а значить, Apache вимагає більше апаратного забезпечення для тієї ж кількості користувачів, що означає, що ви маєте більш високий TCO (загальна вартість володіння) з Apache, ніж з nginx, що зменшує рентабельність інвестицій (рентабельність інвестицій).

Загальна пам'ять, що використовується X одночасними з'єднаннями (менше краще)

Запити, які можна подавати в секунду при X паралельних з'єднаннях на 1 комплект апаратних засобів (більше краще)

Джерело: ApacheBench, автор dreamhost.com

Дивіться також цей цифровий запис в океані .
Мабуть, це залежить від архітектури обробки з'єднань, яку ви вибрали для Apache.

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

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

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)

Апач

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 з кешем і прискоренням

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

Ви повинні використовувати конфігурацію perusio 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%.

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

тут є навантаження тестування результатів для Друпал , які працюють на тому ж обладнанні , але з різними веб - серверами. (nginx і apache)

ось висновок цього тесту:

при великому трафіку з тими ж апаратними ресурсами, nginx працює краще, ніж апаш.