Frage Wie wähle ich aus, welches Apache MPM verwendet werden soll?


Das ist ein Kanonische Frage über die Auswahl des richtigen Apache httpd MPM.

Ich bin ein wenig verwirrt zwischen den verschiedenen MPMs, die von Apache angeboten werden - "Arbeiter", "Ereignis", "Prefork" usw.

Was sind die Hauptunterschiede zwischen ihnen und wie kann ich entscheiden, welches für eine bestimmte Bereitstellung am besten ist?


243
2018-04-26 18:40


Ursprung


Wenn Sie mod_php unterstützen, dann machen Sie Prefork. - Zoredache
@Zoredache:? Sie hat PHP nie erwähnt, und selbst wenn sie es getan hätte, würde mod_php nur das Ereignis ausschließen. Oder klammern Sie sich noch an eine Bemerkung von RL vor 8 Jahren? Letzter Bug, der in PHP im Zusammenhang mit Threaded Apache geloggt wurde, war 2005. - symcbean
Entschuldigung - muss stimmen, um das zu schließen - ist viel zu weit eine Frage, um hier zu antworten. - symcbean
@symcbean Re: PHP und Threads - PHPs Kern ist Threadsafe in diesen Tagen, aber viele andere Sachen, die Leute finden, die darin kompilieren, sind nicht. Ich wurde erst letztes Jahr gebissen, also ist es sehr viel ein "Test (ausgiebig), bevor ich in der Produktion darauf vertraue" ... - voretaq7
Je nach verwendetem Betriebssystem sind möglicherweise nicht alle diese Optionen bei einer Standardinstallation verfügbar. - John Gardeniers


Antworten:


Es gibt eine Reihe von MPM-Module (Multi-Processing-Module), aber bei weitem am weitesten verbreitet (zumindest auf * nix-Plattformen) sind die drei wichtigsten: prefork, worker, und event. Im Wesentlichen repräsentieren sie die Evolution des Apache-Webservers und die verschiedenen Möglichkeiten, wie der Server aufgebaut wurde, um HTTP-Anforderungen innerhalb der Rechenzeitbeschränkungen seiner langen (in Softwarebegriffen) Geschichte zu bewältigen.


prefork

mpm_prefork ist .. gut .. es ist mit allem kompatibel. Es spinnt eine Anzahl untergeordneter Prozesse aus, um Anfragen zu bedienen, und die untergeordneten Prozesse bedienen jeweils nur eine Anfrage. Da der Serverprozess dort sitzt, einsatzbereit ist und sich nicht mit dem Thread-Marshalling befassen muss, ist es tatsächlich schneller als die moderneren MPMs mit Threads, wenn Sie nur eine einzige Anfrage gleichzeitig bearbeiten müssen - aber gleichzeitige Anfragen leiden, da sie so lange warten müssen, bis ein Serverprozess frei ist. Wenn Sie versuchen, die Anzahl der Prefork-Child-Prozesse zu erhöhen, werden Sie außerdem leicht ernsthaftes RAM in Anspruch nehmen.

Es ist wahrscheinlich nicht ratsam, Prefork zu verwenden, es sei denn, Sie benötigen ein Modul, das nicht Thread-sicher ist.

Verwenden Sie wenn: Sie benötigen Module, die bei der Verwendung von Threads abbrechen mod_php. Selbst dann sollten Sie FastCGI und php-fpm.

Verwenden Sie nicht, wenn: Ihre Module unterbrechen das Threading nicht.

worker

mpm_worker verwendet Threading - was eine große Hilfe für Nebenläufigkeit ist. Worker spinnt einige Kindprozesse ab, die ihrerseits Kindthreads ausgliedern; Ähnlich wie Prefork werden einige Ersatz-Threads bereit gehalten, wenn möglich, eingehende Verbindungen zu bedienen. Dieser Ansatz ist viel benutzerfreundlicher für RAM, da die Anzahl der Threads keinen direkten Einfluss auf die Speicherbelegung hat, wie es die Serveranzahl im Prefork tut. Es behandelt auch die Parallelität viel einfacher, da die Verbindungen nur auf einen freien Thread (der normalerweise verfügbar ist) warten müssen, anstatt auf einen Ersatzserver im Prefork.

Verwenden Sie wenn: Sie sind auf Apache 2.2 oder 2.4 und Sie betreiben hauptsächlich SSL.

Verwenden Sie nicht, wenn: Sie können wirklich nichts falsch machen, es sei denn, Sie benötigen Prefork für die Kompatibilität.

Beachten Sie jedoch, dass die Laufflächen befestigt sind Verbindungen und nicht Anfragen - was bedeutet, dass eine Keep-Alive-Verbindung immer einen Thread festhält, bis dieser geschlossen ist (was je nach Konfiguration sehr lange dauern kann). Deshalb haben wir ..

event

mpm_event ist dem Arbeiter strukturell sehr ähnlich; Es wurde gerade von "experimentell" in "stabil" in Apache 2.4 verschoben. Der große Unterschied besteht darin, dass ein dedizierter Thread verwendet wird, um die Keeped-Alive-Verbindungen zu verwalten, und Anforderungen nur dann an untergeordnete Threads übergeben werden, wenn eine Anforderung tatsächlich erfolgt ist (diese Threads können sofort nach Abschluss der Anforderung wieder freigegeben werden). Dies ist ideal für den gleichzeitigen Zugriff von Clients, die nicht notwendigerweise alle gleichzeitig aktiv sind, sondern gelegentliche Anforderungen und wenn die Clients eine lange Keep-Alive-Zeitüberschreitung haben.

Die Ausnahme hier ist mit SSL-Verbindungen; In diesem Fall verhält es sich identisch mit worker (eine gegebene Verbindung zu einem bestimmten Thread wird angeklebt, bis die Verbindung geschlossen wird).

Verwenden Sie wenn: Sie sind auf Apache 2.4 und wie Threads, aber Sie möchten nicht, dass Threads auf inaktive Verbindungen warten. Jeder mag Fäden!

Verwenden Sie nicht, wenn: Sie sind nicht auf Apache 2.4 oder Sie benötigen Prefork für Kompatibilität.


In der heutigen Welt von Slowloris, AJAX und Browsern, die 6 TCP-Verbindungen (mit Keep-Alive, natürlich) zu Ihrem Server multiplexen möchten, ist Nebenläufigkeit ein wichtiger Faktor, um Ihren Server gut skalieren und skalieren zu lassen. Die Geschichte von Apache hat dies in dieser Hinsicht festgelegt, und obwohl es in Bezug auf Ressourcennutzung oder Skalierung den Anforderungen von nginx oder lighttpd noch nicht gewachsen ist, ist es klar, dass das Entwicklungsteam daran arbeitet, einen Webserver zu erstellen, der immer noch relevant ist in der heutigen High-Request-Concurrency-Welt.


396
2018-04-27 02:27



-1: IME, Worker reduziert die Größe des httpd-Footprints nur um etwa 15% (IIRC Linux meldet COW in RSS, was dazu führt, dass der Pre-Fork so aussieht, als würde er viel mehr Speicher verwenden als er). Es gibt kaum einen Unterschied zwischen dem Kernel-Footprint für einen Prozess und einem NPTL-Thread. Es ist weit weg von der Erderschütterung. Ich verstehe nicht, warum Sie denken, dass das Warten auf und das Zuweisen eines Threads beim Planen von Terminen effizienter ist als das Warten auf / Planen eines (vorgefertigten) Prozesses. Noch was du denkst, SSL hat im ganzen She-Bang. - symcbean
@symcbean Sie sagen also, dass 15% RAM-Nutzung nicht signifikant ist? Das ist in Ordnung, aber meine Meinung wäre anders. Concurrency-Leistungsansprüche sind nicht meine eigenen. Sehen Hier. Und die SSL-Differenz ist in der Dokumentation zum Event MPM klar formuliert: The improved connection handling does not yet work for certain connection filters, in particular SSL. For SSL connections, this MPM will fall back to the behaviour of the worker MPM and reserve one worker thread per connection. - Shane Madden♦
@ShaneMadden `und obwohl es in Bezug auf Ressourcennutzung oder Skalierung wirklich noch nicht mit Nginx oder Lighttpd mithalten kann, habe ich beide Systeme apache gemacht. - Kelly Elton
@ShaneMadden in Bezug auf das Problem mit SSL und dem Event MPM: Weißt du, ob nginx das deutlich besser beherrscht als Apache? - DASKAjA
Es scheint, dass, wenn Sie Apache 2.4 kompilieren, ohne über MPM-Module zu wissen, kommt es mit Modul namens Event mpm Modul und es arbeitet mit mod_php7 (gerade jetzt ich forsche mpm, weil Apache2.4 mysql Verbindungslimit überschreitet, während Apache 2.2 mit demselben mysql Server ist nicht) - BioHazard


Meistens hängt davon ab, welche Apache-Module Sie verwenden möchten. Ich denke, Arbeiter ist in der Regel die Standardwahl, aber einige (ältere) Module erfordern Forking und hängen von Prefork ab.

Wenn Sie keine Einstellungen haben, empfehle ich Ihnen, die bevorzugte Abhängigkeit von Ihrer Betriebssystemverteilung zu verwenden. Ubuntu zum Beispiel installiert standardmäßig mpm-worker, wenn Sie Apache2 installieren.


5
2018-04-26 19:32





Hier ist eine gute Erklärung, wie es mit Gifs funktioniert:

https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/

Kurz gesagt: wenn Sie auf 2.4 und du brauchst httpd als Reverse-Proxy (Dispatcher), also ist deine Wahl eine Ereignis-MPM


5
2018-06-21 13:10





Ab Februar 2018 besagt die Apache 2.4-Dokumentation für Event MPM, dass die Verwendung von Apache als Proxy die "verbesserte Verbindungsbehandlung" seit 2.4.24 nicht mehr wie geplant funktionieren lässt. Siehe die Einschränkungen Sektion.

Das Problem besteht darin, dass der Worker als Proxy nicht angeben kann, wo das Ende der Antwort liegt, und er muss warten, bis die gesamte Antwort angezeigt wird, bevor er die Kontrolle an den Listener zurückgibt.

Aus diesem Grund scheint die Verwendung des Worker-Modells für die Verwendung von Apache als Proxy am besten zu sein. Es ist mir nicht wirklich klar, ob das Ereignismodell in einer Proxy-Umgebung Vorteile hat, aber vielleicht gibt es das.


3
2018-02-14 15:01