Nginx vs Apache - Gibt es aktuelle Verwendungsvergleiche und Statistiken?

Ich habe einen neuen Server zum Spielen und starre auf eine leere Leinwand. Ich kann alles drauflegen, was ich will. Obwohl ich mit Apache vertraut bin, höre ich immer wieder, wie Nginx mit so viel mehr Verkehr als Apache um den Faktor 10, 100 und noch mehr umgehen kann. Nicht nur, dass es "viel viel schneller" ist.

Wenn ich nach Artikeln suche, kann ich viele Dinge finden, die nichts mit Drupal zu tun haben. Oder wenn ich auf einen Drupal-Artikel stoße, ist dies entweder 1) die Konfigurationsdatei eines anderen Benutzers mit einem schnellen Versuch, die Einrichtung zu erklären, oder 2) jemand, der sagt: "Nein, verwende kein Nginx, geh mit PHP zu Apache fcgid ", aber es gibt keine Erklärung dafür, warum.

Was ist hier die Realität, wenn es um Drupal geht?

Als Beispiel suche ich etwas in diesem 2bits.com- Artikel. Hier hat der Autor Apache mod_php vs Apache mit fcgid unter Abwägung der Vor- und Nachteile ausführlich untersucht und eine Fallstudie zur Veranschaulichung der Auswirkungen in der realen Welt vorgelegt. In diesem Artikel sind genügend Informationen enthalten, damit ich eine fundierte Entscheidung treffen kann, welcher Ansatz für meine Situation am besten geeignet ist.

Während dieser Autor mod_php mit fcgid vergleicht, suche ich nach der gleichen Art von umfassendem, realem Blick auf Apache vs Nginx.

Hat jemand zu Nginx gewechselt und wurde von dem Unterschied zu Apache "umgehauen"? Selbst in hochoptimierten Umgebungen, in denen bereits APC, Memcache und aggressives Caching wie Varnish verwendet werden, reicht es aus, Apache durch Nginx zu ersetzen, um einen Unterschied zu machen und in diese neuere, alternative Technologie zu investieren ?

Die Site, die auf diesem Server geschaltet wird, erhält durchschnittlich 2 Millionen PV pro Monat. LAMP-Stack mit Cent OS 6. 4-Kern-CPU mit 8 GIGS RAM. Memcached und APC werden Teil der Mischung sein. Nichts besonderes an der Drupal-Installation - im Grunde Vanilla 7 mit etwa 50 Modulen.

Genau genommen beantwortet dies nicht die Frage, die Sie stellen. Ich hoffe es ist trotzdem hilfreich.

Apache / Nginx / Lighttpd / anderer Webserver. Ist es wichtig, welches ich wähle? Kurz gesagt, nein .

Die viel viel längere Antwort:

Wenn und nur wennHaben Sie einen sehr großen Prozentsatz Ihrer Benutzer angemeldet, sollten Sie sich überhaupt um die Leistung Ihres Webservers kümmern. Wenn Ihre Benutzer anonym sind, ist jeder Unterschied, den Sie theoretisch aus der Optimierung auf diesen Ebenen ableiten können, verblasst im Vergleich dazu, dass Ihre Ressourcen besser zwischengespeichert werden können. Wenn Ihre CSS-Dateien über richtige Cache-Header verfügen, werden Sie beim zweiten Mal nicht einmal von der UA gefragt. Das zählt. Wenn Sie Ihre Seiten in Varnish oder einer ähnlichen Softwarelösung zwischenspeichern können, müssen Sie für die Bereitstellung dieser Seite einen Hash-Lookup durchführen und anschließend eine große Datenmenge direkt aus dem RAM zurückgeben. Das zählt. In beiden Szenarien ist der HTTP-Daemon nicht einmal beteiligt, PHP wird nicht aufgerufen. Drupal bootet nicht. Es müssen keine großen Mengen von Modulen in den Arbeitsspeicher geladen werden, und es werden keine zeitaufwendigen Datenbankabfragen ausgeführt.

Wenn Sie für einen angemeldeten Benutzer auf einer komplexen Seite eine vollständige Seite aus einem Cold-Cache laden; Viele Dinge sind im Gange. Ja, der Webserver ist an der Bearbeitung der eingehenden Anfrage beteiligt, setzt einige Header und leitet die Antwort zurück. Aber die Zeit, die benötigt wird, spielt keine Rolle, wenn Drupal einen vollständigen Bootstrap ausführt und seine Antwort ausgibt. Möglicherweise werden Hunderte von Datenbankabfragen ausgeführt. Hochkomplexe Logik in PHP wird vom Parser ausgewertet. Viele Module werden in den Arbeitsspeicher geladen. Eine Verbesserung der Leistung all dieser Dinge kann mit größerer Wahrscheinlichkeit einen ernsthaften Beitrag zur Leistung leisten.

Der Argumentation halber: Nehmen wir an, Sie haben viel Zeit damit verbracht, die Leistung für alles andere zu optimieren.

1. Sie führen APC (oder Optimizer + ) und die neueste und schnellste Version von PHP aus.
2. DB-Abfragen gibt es nur wenige.
3. PHP-Logik wurde reduziert.
4. Sie zwischenspeichern, was Sie in Lack können.
5. Sie haben Ihre gesamte Site neu strukturiert, sodass Sie eine Menge clientseitiger Daten zwischenspeichern und viel in ECMAScript arbeiten können .

Wenn Sie viele angemeldete Benutzer haben und sich mit all dem Obenstehenden befasst haben, können Sie wahrscheinlich einen Unterschied machen, außer die Leistung zu optimieren oder Ihren Webserver zu ersetzen. Aber raten Sie mal was. Ihre Website ist so komplex und die Verwendungsmuster Ihrer bestimmten Benutzer sind einzigartig . Es gibt keine generische Antwort. Sie müssen alle verschiedenen Webserver hinter einem Lastenausgleich einrichten und deren Verhalten in Ihrem Szenario überprüfen .

Das oben Gesagte war ein Versuch, logisch zu der Schlussfolgerung zu gelangen, dass die Optimierung des Webservers durch Zeitaufwand wahrscheinlich eine schlechte Zeitnutzung darstellt. Ich würde gerne jemanden haben, der Löcher in das Obige pickt, ich würde wahrscheinlich etwas Neues daraus lernen. :)

Einige andere Hinweise:

1. Während der DrupalCon Copenhagen Keynote sagte der PHP-Entwickler Rasmus Lerdorf unter Verwendung von Nginx selbst zum Thema Drupal-Performance: "Die Leute fragen mich immer nach Webservern ... es ist wirklich egal, der Webserver ist so ziemlich irrelevant." . (Ungefähr um 26:30 im Video)
2. Facebook hat unzählige Stunden damit verbracht, Hiphop zu schreiben , eine Codebasis, die deutlich größer ist als Drupal selbst, um PHP-Code um "schlappe" 100% zu beschleunigen. Ich habe Hiphop mit untersucht $ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1und festgestellt, dass es aus 1.512.481 Codezeilen besteht. Das ist eine absolut verrückte Menge an Arbeit, um die Geschwindigkeit von PHP zu verbessern. Ich vermute, das liegt daran, dass die Geschwindigkeit von PHP für sie sehr wichtig ist.
3. Habe ich erwähnt, dass gutes Caching eine viel größere Auswirkung hat als das Optimieren des Webservers?
4. Mit der Veröffentlichung von Apache 2.4 behauptet Jim Jagielski grundsätzlich, dass Apache 2.4 schneller ist als ereignisbasierte Server .
5. Ich habe die Drupal-Leistung und Skalierbarkeit beim Dream-Team beachtet , wo genau diese Frage aufgeworfen wurde. Alle Antworten, die zur Auswahl standen, waren nicht von der Leistung abhängig. Dinge wie "Welche können Sie bereits konfigurieren?" Und "Welche ermöglichen es Ihnen, den einfachsten Technologie-Stack zu erstellen" waren unter anderem Gründe, die vor den anderen gestellt wurden. Performance ist nicht ins Bild gekommen.

OK, obwohl diese Frage bereits beantwortet wurde, bin ich wieder ein Nekromantiker, vor allem, weil mir die Implikationen dieser Antworten nicht gefallen, dass es keinen Unterschied macht, und weil ich als Webentwickler es hasse, leidenschaftlich zu cachen .

Der Unterschied zwischen Apache und nginx ist nicht so sehr, "wie schnell sie eine Anfrage bearbeiten können", sondern wie viele Anfragen sie auf derselben Hardwaremenge (insbesondere mit begrenzten Ressourcen) bearbeiten können, was etwas anders ist.

Apache ist ein prozessbasierter Server. Das heißt, es wird ein Prozess für jede Anforderung abgefragt. Nginx ist ein ereignisbasierter Server, dh es wird eine (asynchrone) Ereignisschleife anstelle von Prozessen oder Threads verwendet.

Und während ein prozessbasierter Server (wie Apache) bei geringer Auslastung mehr oder weniger mit einem asynchronen ereignisbasierten Server (wie nginx) mithalten kann, verwendet nginx bei hoher Auslastung wie z. B. 10'0000 gleichzeitigen Anforderungen nur wenige Megabyte RAM, wohingegen Apache allein für den Webserver mehrere Hundert Megabyte benötigt (ohne die Webanwendung, die viel mehr Ressourcen selbst benötigt), wenn es überhaupt dazu in der Lage ist.

Unter höheren Lasten verbraucht Apache also viel zu viel RAM, was die Leistung überraschenderweise erheblich beeinträchtigt.

Ein höherer RAM-Verbrauch bedeutet, dass Apache weniger Anforderungen auf derselben Hardware bedienen kann als Nginx. Dies bedeutet, dass Apache mehr Hardware für dieselbe Anzahl von Benutzern benötigt, was bedeutet, dass Sie eine höhere Gesamtbetriebskosten (TCO) haben. mit Apache als mit Nginx, was Ihren ROI (Return on Investment) reduziert.

Gesamter Speicher, der von X gleichzeitigen Verbindungen verwendet wird (weniger ist besser)

Anforderungen, die pro Sekunde bei gleichzeitigen X-Verbindungen auf einem Hardwaresatz bedient werden können (mehr ist besser)

Quelle: ApacheBench, von dreamhost.com

Siehe auch diese digitale Ozeanbeschreibung.
Anscheinend hängt dies von der Verbindungsbehandlungsarchitektur ab, die Sie für Apache ausgewählt haben.

Ich bin vor ein paar Monaten von Apache zu Nginx / PHP-FPM gewechselt.

Ich habe Benchmarck mit einer Drupal-Website erstellt und mehrere Anwendungsfälle getestet. Auf einem VPS-Server mit 1 CPU und 512 Mo RAM

Drupal mit nur Cache

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 mit Cache und 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

Benchmark für authentifizierte Benutzer (Seitenaufruf)

Nginx

Page load times : 2.85 s

Apache

Page load times : 5.4 s

Die Stärke von Nginx ist jedoch das Cache-System

Drupal ohne Boost und Nginx mit aktiviertem Cache-System

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

Sie sollten die perusio Konfiguration Nginx für Drupal verwenden

Hier ist ein Leistungstest für zehn Webserver / -varianten (zB Apache, Nginx, lighttpd, Lightspeed, Hiawatha, Cherokee). Drei der Tests beziehen sich auf Drupal.

Ich denke, Hiawatha könnte die beste Wahl sein. Es wird angenommen, dass es über vollständige Drupal-Kompatibilität verfügt. Der Schwerpunkt liegt auf der Sicherheit (DoS, XSS, CSRF, Verhinderung von SQL-Injektionen) und einer Geschwindigkeit und einem Footprint, die denen von Nginx ähneln.

In zwei der drei Drupal-Tests übertreffen sowohl Hiawatha als auch Nginx Apache um etwa 150%, aber im statischen Drupal-Test übertrifft Apache Nginx geringfügig, während Hiawatha die Packung um etwa 10% übertrifft.

Ich würde meinen Hut bei keinem dieser Tests aufhängen, aber es gibt einen Überblick über die Leistung in verschiedenen Nutzungssituationen. Ich denke, Leistung allein sollte nicht die einzige Überlegung sein. Stabilität und Sicherheit können die wichtigsten Faktoren sein.

Hier sehen Sie die Ergebnisse eines Auslastungstests für Drupal, das auf derselben Hardware, jedoch mit unterschiedlichen Webservern ausgeführt wird. (Nginx und Apache)

Hier ist das Fazit dieses Tests:

Bei einem großen Datenverkehr mit denselben Hardwareressourcen schneidet Nginx deutlich besser ab als Apache.