Warum funktioniert das Apache Event MPM schlecht?

Question

Das Ereignis MPM ist nicht genau das gleiche Design wie Nginx, aber es wurde eindeutig entworfen, um Keepalives haltbarer zu machen und statische Dateien schneller zu senden. Mein Verständnis ist, dass das Ereignis MPM ist ein wenig irreführend, weil:

1. Obwohl die Verbindung kqueue geführt wird/epoll,
2. einige sehr wichtige Module wie mod_gzip und mod_ssl blockieren/verbrauchen einen Thread, bis die Antwort ist, getan
3. und das ist ein Problem für große Dateien, aber wahrscheinlich nicht für PHP-generierten HTML-Dokumente, etc.

Leider hält Apache Marktanteil zu verlieren, und die meisten Benchmarks für die Veranstaltung sind vernichtend MPM. Sind die Benchmarks fehlerhaft, oder schneidet das Event MPM gegen Nginx wirklich schlecht ab? Selbst unter diesen Einschränkungen sollte es im normalen Datenverkehr (nicht bösartig) und in kleineren Dateien mit Nginx konkurrieren. Zum Beispiel sollte es wettbewerbsfähig sein, PHP-generierte Dokumente über php-fpm auf langsamen Verbindungen zu bedienen, weil das Dokument gepuffert (auch wenn es ssl'd und gzip ist) und asynchron gesendet wird. Sowohl SSL- als auch Nicht-SSL-Verbindungen, die mit Komprimierung arbeiten oder nicht, sollten nicht wesentlich anders funktionieren als in Nginx bei einer solchen Arbeitslast.

Warum glänzt es nicht in verschiedenen Benchmarks? Was stimmt damit nicht? Oder was stimmt nicht mit den Benchmarks? Ist eine große Website es als Appell an die Autorität, die es ausführen kann?

Answer 1

Für mich sind die dominierenden operativen Unterschiede sind, dass in Fall:

• Handler (Plug-ins für die Erzeugung der Antwort) sind synchron - wenn sie entweder Berechnung durchführen oder I/O werden sie binden ein Gewinde
• der Kern muss verkanten Schlösser verwenden Schlüsseldatenstrukturen zu schützen, weil es so viele dieser synchronen Anforderungen multi-threaded ist

aus diesem Grunde bei sehr hohen Volumen-Servern wie nginx (oder Apache Traffic zu unterstützen Serv oder irgendein moderner kommerzieller/Hochleistungs-Proxy) kommt in der Regel voraus.

IMO Die Kugeln in Ihrer Frage sind ein wenig daneben, SSL und deflate tragen nicht wirklich viel zu den Unterschieden hier bei, da sie beide Filter nicht wirklich zu Skalierbarkeitsproblemen beitragen oder sogar httpd zu seinem traditionellen binden API garantiert den Lebenszyklus einer Anfrage oder Verbindung. Filter wie diese (vs. Handler oder der Kernfilter, der für die Low-Level-I/O verantwortlich ist) sind wahrscheinlich die wenigsten Dinge, die an das Verarbeitungsmodell gebunden sind.

Aber ich denke auch nicht, dass es im Vergleich für alle bis auf die extremsten Arbeitslasten oder extrem eingeschränkte Systeme so schlecht ist. Die meisten Benchmarks, die ich gesehen habe, sind aus dem einen oder anderen Grund von extrem schlechter Qualität.

Ich glaube, dass die meisten Leute wollen, was sie einen Webserver heute als Proxy für einen anspruchsvolleren Anwendungsserver (Java EE, PHP, etc) und einen Server bezeichnen, der E/A effizient umwandelt, ohne API-Gepäck zu haben die Kante haben.

Answer 2

Es ist langsamer als nginx, weil Apache mit dem Ereignis MPM (sehr) ungefähr einem ereignisgesteuerten HTTP-Proxy (nginx, lack, haproxy) vor Apache mit dem Worker-MPM entspricht.Ereignis ist Worker, aber anstatt jede neue Verbindung zu einem Thread für seine Lebensdauer zu übergeben, übergeben das Ereignis MPM-Threads die Verbindung zu einem sekundären Thread, die es in eine Warteschlange schiebt oder schließt, wenn Keep-Alive deaktiviert ist oder abgelaufen ist.

Der wirkliche Vorteil von Ereignis über Arbeiter ist die Ressourcennutzung. Wenn 1.000 gleichzeitige Verbindungen aufrechterhalten werden müssen, benötigt das Worker-MPM 1.000 Threads, während das Ereignis MPM mit 100 aktiven Threads und 900 inaktiven Verbindungen, die in der Ereigniswarteschlange verwaltet werden, auskommen kann. Das Ereignis MPM wird einen Bruchteil der Ressourcen des Worker MPM in diesem hypothetischen verwenden, aber der Nachteil ist immer noch da: jede dieser Anfragen wird von einem separaten Thread behandelt, der vom Kernel geplant werden muss und als solcher die Kosten von Kontext wechseln.

Auf der anderen Seite haben wir Nginx, die das Ereignismodell selbst als Scheduler verwendet. Nginx verarbeitet einfach so viel Arbeit an jeder Verbindung wie möglich, bevor es zur nächsten übergeht. Es ist kein zusätzlicher Kontextwechsel erforderlich. Der einzige Anwendungsfall, in dem das Event-MPM wirklich glänzt, ist die Handhabung eines Setups, bei dem eine umfangreiche Anwendung in Apache ausgeführt wird. Um die Ressourcen von Threads zu erhalten, die während Keep-Alive inaktiv sind, würden Sie einen Proxy bereitstellen (http://go.microsoft.com/fwlink/?LinkId=8907). wie nginx) vor Apache. Wenn Ihr Frontend keinem anderen Zweck diente (z. B. statischer Inhalt, Proxyserver für andere Server usw.), verarbeitet das Ereignis MPM diesen Anwendungsfall wunderschön und beseitigt die Notwendigkeit für einen Proxy.