Nginx vs Apache - Czy istnieją jakieś faktyczne porównania użycia i statystyki?

Mam nowy serwer do zabawy i patrzę na puste płótno. Mogę umieścić na nim wszystko, co chcę. Chociaż czuję się dobrze z Apache, wciąż słyszę, jak nginx może obsłużyć o wiele większy ruch niż Apache, przy współczynnikach 10, 100, a nawet więcej. Nie tylko, że jest „znacznie szybszy”.

Kiedy szukam artykułów, mogę znaleźć wiele rzeczy niezwiązanych z Drupalem. Lub gdy natknę się na artykuł związany z Drupalem, to albo 1) czyjś plik konfiguracyjny z szybką próbą wyjaśnienia, jak go skonfigurować, albo 2) to ktoś mówi „nie, nie używaj nginx, idź z Apache z PHP fcgid ", ale nigdy nie ma wyjaśnienia, dlaczego.

Jeśli chodzi o Drupala, jaka jest tutaj rzeczywistość?

Jako przykład szukam czegoś podobnego do tego artykułu 2bits.com . Tutaj autor rzucił obszerne spojrzenie na Apache mod_php vs Apache z fcgid, ważąc zalety i wady każdego z nich, i przedstawił studium przypadku ilustrujące wpływ na rzeczywisty świat. W tym artykule jest wystarczająco dużo informacji, aby podjąć świadomą decyzję, które podejście byłoby najlepsze w mojej sytuacji.

Podczas gdy autor ten porównuje mod_php do fcgid, szukam tego samego rodzaju kompleksowego, rzeczywistego spojrzenia na Apache vs. Nginx.

Czy ktoś zmienił się na Nginx i został „oszołomiony” różnicą, którą zrobił w porównaniu z Apache? Nawet w wysoce zoptymalizowanych środowiskach, które już korzystają z APC, Memcache i agresywnego buforowania, takiego jak Varnish, gdy jedyną zmienną, która się zmienia, zastępuje Apache Nginx, sama w sobie robi wystarczającą różnicę, aby zasługiwać na inwestycję w tę nowszą, alternatywną technologię ?

Witryna, która będzie dostępna na tym serwerze, otrzyma średnio 2 miliony PV miesięcznie. Stos LAMP z systemem Cent OS 6. 4-rdzeniowy procesor z 8 GIGS pamięci RAM. Memcached i APC będą częścią miksu. Nic specjalnego w instalacji Drupal - w zasadzie wanilia 7 z około 50 modułami.

Ściśle mówiąc, to nie odpowiada na pytanie, które zadajesz. Mam nadzieję, że i tak jest to pomocne.

Serwer WWW Apache / Nginx / Lighttpd / inny. Czy to ważne, który wybrać? Krótko mówiąc, nie .

Znacznie dłuższa odpowiedź:

Jeśli i tylko jeśli, masz bardzo duży odsetek zalogowanych użytkowników, jeśli w ogóle zależy Ci na wydajności serwera. Jeśli Twoi użytkownicy są anonimowi, wszelkie różnice, które teoretycznie możesz czerpać z optymalizacji na tych warstwach, są absolutnie bledne w porównaniu z lepszym buforowaniem zasobów. Jeśli twoje pliki css mają odpowiednie nagłówki pamięci podręcznej, UA nawet nie poprosi o nie po raz drugi. To się liczy. Jeśli możesz buforować swoje strony w Varnish lub podobnym rozwiązaniu programowym, wyświetlenie tej strony jest kwestią sprawdzenia skrótu, a następnie zwrócenia dużej ilości danych bezpośrednio z pamięci RAM. To się liczy. W obu tych scenariuszach demon HTTP nawet się nie angażuje, PHP się nie wywołuje. Drupal nie uruchamia się. Do pamięci RAM nie wolno ładować dużego zestawu modułów, nie są wykonywane czasochłonne zapytania do bazy danych.

Podczas pełnego ładowania strony z zimnej pamięci podręcznej dla zalogowanego użytkownika na złożonej stronie; dzieje się wiele rzeczy. Tak, serwer WWW jest zaangażowany w obsługę przychodzącego żądania, ustawianie niektórych nagłówków i przekazywanie odpowiedzi z powrotem. Ale czas, który zajmuje, nie jest nawet istotny w kontekście Drupala, który uruchamia pełny bootstrap i wyświetla swoją odpowiedź. Mogą być wykonywane setki zapytań do bazy danych. Wysoce złożona logika w PHP jest analizowana przez parser. Wiele modułów jest ładowanych do pamięci RAM. Poprawa wydajności którejkolwiek z tych rzeczy może znacznie przyczynić się do poprawy wydajności.

Dla argumentu: powiedzmy, że poświęciłeś dużo czasu na optymalizację wszystkiego innego.

1. Używasz APC (lub Optimizer + ) i najnowszej i najszybszej wersji PHP.
2. Kwerend DB jest niewiele.
3. Logika PHP została zmniejszona.
4. Buforujesz co możesz w Lakier.
5. Zrestrukturyzowałeś całą swoją witrynę, abyś mógł buforować wiele stron po stronie klienta i wykonywać wiele ciężkich operacji w ECMAScript .

Jeśli masz wielu zalogowanych użytkowników i zajmujesz się wszystkimi powyższymi kwestiami, prawdopodobnie możesz zrobić różnicę, ale dostrajając wydajność lub wymieniając serwer WWW. Zgadnij co. Twoja witryna jest tak złożona, a wzorce użytkowania poszczególnych użytkowników są wyjątkowe . Nie ma ogólnej odpowiedzi. Będziesz musiał skonfigurować wszystkie różne serwery WWW za modułem równoważenia obciążenia i zobaczyć, jak się zachowują w twoim scenariuszu .

Powyższe było próbą logicznego wyciągnięcia wniosku, że poświęcenie czasu na optymalizację serwera WWW jest prawdopodobnie złym wykorzystaniem czasu. Chciałbym, aby ktoś wybrał dziury w powyższym, prawdopodobnie nauczyłbym się z tego czegoś nowego. :)

Inne uwagi:

1. Podczas keynote DrupalCon w Kopenhadze twórca PHP Rasmus Lerdorf , korzystając z samego Nginxa, mówiąc na temat wydajności Drupala, powiedział: „Ludzie zawsze pytają mnie o serwery sieciowe ... to naprawdę nie ma znaczenia, serwer internetowy jest praktycznie nieistotny” . (Mniej więcej o 26:30 na filmie)
2. Facebook spędził niezliczone godziny na pisaniu Hiphopu , bazy kodu znacznie większej niż sam Drupal, do przyspieszania kodu PHP o „nędznie” 100%. Przebadałem $ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1Hiphopa i znalazłem, że składa się z 1.512.481 linii kodu. To absolutnie szalona ilość pracy włożonej w poprawę szybkości PHP. Zgaduję, że to dlatego, że szybkość PHP ma dla nich ogromne znaczenie.
3. Czy wspominałem, że dobre buforowanie będzie miało znacznie większy efekt niż dostrojenie serwera WWW?
4. Wraz z wydaniem Apache 2.4 Jim Jagielski zasadniczo twierdzi, że Apache 2.4 jest szybszy niż serwery oparte na zdarzeniach .
5. Zwróciłem uwagę na wydajność Drupala i skalowalność w zespole Dream , gdzie właśnie pojawiło się to pytanie. Wszystkie odpowiedzi, które wybrać, nie były związane z wydajnością. Takie rzeczy jak „Który już wiesz, jak skonfigurować” i „Który pozwoli ci zbudować najprostszy stos technologii”, były jednymi z wymienionych powodów, aby wybrać inny. Wydajność nie pojawiła się na zdjęciu.

OK, chociaż na to pytanie już udzielono odpowiedzi, jeszcze raz nekromantuję, przede wszystkim dlatego, że nie podoba mi się implikacja tych odpowiedzi, że to nie robi różnicy, a ponieważ jako twórca stron internetowych nienawidzę buforowania z pasją .

Różnica między Apache a nginx polega na tym, że nie tyle „jak szybko mogą obsłużyć żądanie”, ale ile żądań mogą obsłużyć na tej samej ilości sprzętu (szczególnie przy ograniczonych zasobach), co jest nieco inną rzeczą.

Apache to serwer oparty na procesach. Oznacza to, że forsuje proces dla każdego żądania. Nginx to serwer oparty na zdarzeniach, co oznacza, że ​​używa (asynchronicznej) pętli zdarzeń zamiast procesów lub wątków.

I podczas gdy serwer oparty na procesach (jak Apache) może działać mniej więcej na równi z serwerem asynchronicznym opartym na zdarzeniach (jak nginx) przy niewielkich obciążeniach, przy większych obciążeniach, takich jak na przykład 10 000 000 jednoczesnych żądań, nginx wykorzystuje tylko kilka megabajtów pamięci RAM, podczas gdy Apache wymaga kilkuset megabajtów dla samego serwera WWW (nie wliczając aplikacji internetowej, która sama potrzebuje znacznie więcej zasobów), jeśli w ogóle mogłaby to zrobić.

Dlatego przy większym obciążeniu zobaczysz, że Apache zużywa o wiele za dużo pamięci RAM, co, co nie dziwi, znacznie obniża wydajność.

Co ważniejsze, wyższe zużycie pamięci RAM oznacza, że ​​Apache jest w stanie obsługiwać mniej żądań na tym samym sprzęcie niż nginx, co oznacza, że ​​Apache wymaga więcej sprzętu dla tej samej liczby użytkowników, co oznacza, że ​​masz wyższy całkowity koszt posiadania (całkowity koszt posiadania) z Apache niż z nginx, co zmniejsza ROI (zwrot z inwestycji).

Całkowita pamięć używana przez X równoczesnych połączeń (mniej znaczy lepiej)

Żądania, które mogą być obsługiwane na sekundę przy X równoczesnych połączeniach na 1 zestawie sprzętu (im więcej, tym lepiej)

Źródło: ApacheBench, przez dreamhost.com

Zobacz także to podsumowanie oceanu cyfrowego.
Najwyraźniej zależy to od architektury obsługi połączeń wybranej dla Apache.

Kilka miesięcy temu przełączyłem się z Apache na Nginx / PHP-FPM.

Zrobiłem test porównawczy na stronie drupala i przetestowałem kilka przypadków użycia. Na serwerze VPS z 1 CPU i 512 Mo RAM

Drupal tylko z pamięcią podręczną

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)

Apacz

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 z pamięcią podręczną i doładowaniem

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

Apacz

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

test porównawczy dla uwierzytelnionego użytkownika (ładowanie strony)

Nginx

Page load times : 2.85 s

Apacz

Page load times : 5.4 s

Ale mocą Nginx jest system pamięci podręcznej

Drupal bez wzmocnienia i Nginx z włączonym systemem pamięci podręcznej

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

Powinieneś użyć konfiguracji perusio Nginx dla Drupala

Oto test wydajności dla dziesięciu serwerów / wariantów (np. Apache, Nginx, lighttpd, Lightspeed, Hiawatha, Cherokee). Trzy testy dotyczą Drupala.

Myślę, że Hiawatha może być najlepszym ogólnym wyborem. Podobno ma pełną kompatybilność z Drupalem , kładzie nacisk na bezpieczeństwo (DoS, XSS, CSRF, zapobieganie wstrzykiwaniu SQL) oraz prędkości i ślad podobny do Nginx.

W dwóch z trzech testów Drupala zarówno Hiawatha, jak i Nginx przewyższają Apache o około 150%, ale w teście statycznym Drupal Apache nieznacznie przewyższa Nginx, podczas gdy Hiawatha przewyższa pakiet o około 10%.

Nie powiesiłbym kapelusza na żadnym z tych testów, ale daje to ogólny obraz wydajności w różnych sytuacjach użytkowania. Myślę, że sama wydajność nie powinna być jedynym czynnikiem. Ważniejsze czynniki to stabilność i bezpieczeństwo.

tutaj jest obciążenie testowania wyników dla drupal uruchomione na tym samym sprzęcie, ale z różnych serwerów internetowych. (nginx i apache)

oto zakończenie tego testu:

przy dużym ruchu z tymi samymi zasobami sprzętowymi, nginx działa znacznie lepiej niż apache.