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

45

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.

blue928
źródło
2
Jeśli chcesz dostroić określoną witrynę pod kątem wydajności, lepiej jest uruchomić własne testy niż polegać na pracy innych osób. Na przykład głównym czynnikiem jest połączenie anonimowych i zalogowanych użytkowników. Jeśli spojrzysz na statystyki wydajności witryny, która generuje głównie anonimowy ruch, a twój nie jest taki, równie dobrze możesz nie zawracać sobie głowy. Ale jeśli twoja strona ma w dużej mierze anonimowy ruch, to z mojego doświadczenia wynika, że ​​umieszczenie Varnish na swoim serwerze internetowym ma znacznie większą różnicę niż serwer, za którym prowadzisz.
Alfred Armstrong,

Odpowiedzi:

60

Ś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.
Letharion
źródło
4
Nie zapomnij o CDN, aby zapobiec trafianiu się większości serwerów CSS, JS i obrazów do serwera WWW.
mpdonadio
Doskonały punkt! Myślę, że w pewnym momencie będę musiał ponownie napisać na drupal.stackexchange.com/questions/24180/... Dyskusja na temat Apache / Nginx nie wydaje się optymalnym miejscem do stworzenia kompleksowej listy optymalizacji wydajności.
Letharion
1
To świetna odpowiedź. Tylko jeden nitpick: nie powinieneś używać zamiennie „ECMAScript” i „JavaScript”. JavaScript to o wiele więcej niż ECMAScript.
Mówisz, że pamięć podręczna jest o wiele ważniejsza niż szybkość serwera WWW. Zgadnij co? Jeśli serwer WWW zużywa mniej pamięci niż drugi, możesz użyć więcej pamięci RAM do buforowania. Możemy więc powiedzieć, że ważne jest prawidłowe dostrojenie serwera tak, aby nie zjadł całej pamięci RAM, prawda?
pqnet
Dostosowanie serwera do mniejszej ilości pamięci RAM jest absolutnie w porządku, ale jeśli próbujesz wejść na terytorium o wysokiej wydajności, prawdopodobnie uruchomisz lakier na serwerze dedykowanym, więc twój serwer http i pamięć podręczna nie będą konkurować o tę samą pamięć.
Letharion
32

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)

Zużycie pamięci

Żą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)

Liczba żądań na sekundę

Ź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.

Kłopot
źródło
6
Trafiłeś w sedno słowem „... nie tak szybko, jak mogą obsłużyć żądanie, ale ile żądań mogą obsłużyć na tej samej ilości sprzętu ...” Rzeczywiście, chcę uzyskać największy huk za moją złotówkę . Biorąc pod uwagę maszynę o dokładnie takim samym sprzęcie i inne zmienne, jeśli mogę obsłużyć 1 000 000 użytkowników dziennie z nginx, gdzie apache może obsłużyć tylko 200 000, to z pewnością najlepszym wyborem z perspektywy kosztów jest nginx. Biorąc pod uwagę pewną konfigurację sprzętową, czy zauważyłeś dużą różnicę między tym, co potrafi nginx w porównaniu z Apache?
blue928
2
Obecna wersja Apache 2.4 ma model oparty na zdarzeniach: httpd.apache.org/docs/current/mod/event.html
Greg
1
Również dla tych, którzy mówią, że to nie ma znaczenia, ponieważ „wszystko będzie w porządku, dopóki będziesz buforować rzeczy”: wiesz, co musisz zrobić, aby buforować? Potrzebujesz DARMOWEJ RAM.
pqnet
Często widzę te ogólne twierdzenia, że ​​„Nginx jest bardziej niesamowity”, jednak rzadko (kiedykolwiek?) Ktoś popiera to solidnymi dowodami. Zawsze jest to: „Moja wysoce skonfigurowana instancja nginx pobiła zapasowy serwer apache, więc teraz udowodniłam, że jestem fajna, ponieważ używam nginx jak innych fajnych dzieciaków”. Nginx może być znacznie lepszy od Apache'a, o ile wiem, ale jeszcze nie widziałem, żeby ktokolwiek naprawdę pokazał, że tak jest.
Letharion
@Letharion: Gotowe (przez dreamhost.com) i dodane zgodnie z twoją prośbą. Jak widać w wynikach testu, nginx jest wyraźnie bardziej wydajny pod względem pamięci. Prawdopodobnie też: moja instancja stock-nginx pokonała moją instancję-Apache-instancję w tym samym teście porównawczym na tym samym komputerze.
Quandary
16

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

flokondetyl
źródło
Jak działał Apache, preforma, FCGI itp.? Czy konfiguracja Apache była jak najbardziej zoptymalizowana po uruchomieniu tych testów? Czy działało dokładnie to samo środowisko PHP?
mpdonadio
Środowisko PHP (5.3) było dokładnie takie samo. Apache działał na mpm_prefork, a konfiguracja apache (maxclient, MaxSpareServers, MaxRequestsPerChild itp.) Była dokładnie taka sama jak PHP5-FPM
flocondetoile
4
To są dobre liczby, ale nie jestem pewien, czy to prawdziwe porównanie. Apache + FastCGI vs Apache + FCGI + PHPFPM vs Nginx + PHPFPM lepiej pokazałyby różnice między Apache i Nginx.
mpdonadio
Jak wskazuje MPD, nie jest to prawdziwe porównanie. Musisz mieć php-fpm na obu, aby uzyskać prawdziwy obraz.
1
Myślę, że Nginx to dobry wybór dla kont VPS o ograniczonej pamięci RAM. Ponieważ może działać wygodnie z mniejszą powierzchnią pamięci RAM niż Apache - zwłaszcza jeśli nie musisz odinstalowywać niepotrzebnych modułów - pozostało więcej pamięci RAM do uruchomienia pamięci podręcznej opcode (wbudowana OpCache APC lub PHP 5.5), daj serwer MySQL / Postgres zdemontuj duży bufor i inne optymalizacje, które słusznie wskazuje Letharion, są również ważne.
Garrett Albright
0

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.

Sokole Oko
źródło
0

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.

wathmal
źródło