Es gibt eine Reihe von MPM - Module (Multi-Processing - Module), aber mit Abstand die am weitesten verbreitete (zumindest auf * nix - Plattformen) sind die drei wichtigsten sind: prefork, workerund event. Im Wesentlichen repräsentieren sie die Entwicklung des Apache-Webservers und die verschiedenen Arten, wie der Server aufgebaut wurde, um HTTP-Anforderungen innerhalb der zeitlichen Recheneinschränkungen über die lange (softwaremäßig) Historie hinweg zu verarbeiten.
mpm_preforkist .. na ja .. es ist mit allem kompatibel. Es werden mehrere untergeordnete Prozesse für die Bearbeitung von Anforderungen ausgelagert, und die untergeordneten Prozesse bearbeiten jeweils nur eine Anforderung. Da der Serverprozess dort sitzt, einsatzbereit ist und sich nicht mit Thread-Marshalling befassen muss, ist er tatsächlich schneller als die moderneren Thread-MPMs, wenn Sie nur eine einzelne Anforderung gleichzeitig bearbeiten. da sie in der Schlange warten müssen, bis ein Serverprozess frei ist. Wenn Sie versuchen, die Anzahl der untergeordneten Prefork-Prozesse zu erhöhen, können Sie außerdem problemlos ernsthaften RAM-Speicher auslaugen.
Es ist wahrscheinlich nicht ratsam, Prefork zu verwenden, es sei denn, Sie benötigen ein Modul, das nicht threadsicher ist.
Verwenden Sie, wenn: Sie Module benötigen, die brechen, wenn Threads verwendet werden, z mod_php. Ziehen Sie auch dann die Verwendung von FastCGI und in Betracht php-fpm.
Nicht verwenden, wenn: Ihre Module beim Einfädeln nicht abbrechen.
mpm_workerverwendet Threading - das ist eine große Hilfe für die Parallelität. Worker spinnt einige untergeordnete Prozesse ab, die wiederum untergeordnete Threads abspalten. Ähnlich wie bei Prefork werden einige Ersatz-Threads bereitgehalten, um eingehende Verbindungen zu bedienen. Dieser Ansatz schont den Arbeitsspeicher erheblich, da die Thread-Anzahl keinen direkten Einfluss auf die Speichernutzung hat, wie dies bei der Server-Anzahl in Prefork der Fall ist. Parallelität wird auch viel einfacher verarbeitet, da die Verbindungen nur auf einen freien Thread (der normalerweise verfügbar ist) warten müssen, anstatt auf einen Ersatzserver in Prefork.
Verwenden Sie diese Option, wenn Sie mit Apache 2.2 oder 2.4 arbeiten und hauptsächlich SSL verwenden.
Verwenden Sie nicht, wenn: Sie wirklich nichts falsch machen können, es sei denn, Sie benötigen Prefork für die Kompatibilität.
Beachten Sie jedoch, dass die Treads an Verbindungen und nicht an Anforderungen angehängt sind. Dies bedeutet, dass bei einer Keep-Alive-Verbindung ein Thread immer gehalten wird, bis er geschlossen wird (dies kann je nach Konfiguration lange dauern). Welches ist, warum wir haben ..
mpm_eventist Arbeiter strukturell sehr ähnlich; In Apache 2.4 wurde der Status von "experimentell" auf "stabil" geändert. Der große Unterschied besteht darin, dass ein dedizierter Thread für die Verwaltung der Verbindungen verwendet wird und Anforderungen nur dann an untergeordnete Threads weitergegeben werden, wenn tatsächlich eine Anforderung gestellt wurde (sodass diese Threads sofort nach Abschluss der Anforderung wieder freigegeben werden können). Dies ist ideal für die gleichzeitige Verwendung von Clients, die nicht unbedingt alle gleichzeitig aktiv sind, sondern gelegentlich Anforderungen stellen und bei denen die Clients möglicherweise ein langes Keep-Alive-Timeout haben.
Die Ausnahme hiervon sind SSL-Verbindungen. In diesem Fall verhält es sich wie ein Worker (eine bestimmte Verbindung mit einem bestimmten Thread verbinden, bis die Verbindung geschlossen wird).
Verwenden Sie diese Option, wenn: Sie mit Apache 2.4 arbeiten und Threads mögen, aber keine Threads auf inaktive Verbindungen warten möchten. Jeder mag Themen!
Verwenden Sie diese Option nicht, wenn: Sie nicht mit Apache 2.4 arbeiten oder aus Kompatibilitätsgründen Prefork benötigen.
In der heutigen Welt von Slowloris , AJAX und Browsern, die 6 TCP-Verbindungen (natürlich mit Keep-Alive) zu Ihrem Server multiplexen möchten , ist die Parallelität ein wichtiger Faktor für die Skalierung und Skalierung Ihres Servers. Die Geschichte von Apache hat diesbezüglich Abhilfe geschaffen, und obwohl es in Bezug auf die Ressourcennutzung oder -skalierung immer noch nicht mit Nginx oder Lighttpd vergleichbar ist, ist es klar, dass das Entwicklerteam daran arbeitet, einen Webserver aufzubauen, der immer noch relevant ist in der heutigen Welt mit hohen Anforderungen und Parallelität.