apache2.0.50 MPM

[Andreas Korthaus]

Hi Eddi!

danke - das war sehr aufschlußreich, aber, da ich um Datenbanken, wo ich nur kann, einen Bogen mache,

Wieso? Kommt halt auf die Anwendung an, aber ich mache online eigentlich fast nichts ohne DB ;-)

adererseits auch kaum mit --with-[res] (bz2 & curlwrappers schon noch) arbeiteen möchte, stellt sich nun mein Grundproblem ein:

Default für Unix ist prefork.
                    Worker wäre auch wählbar.

In http://httpd.apache.org/docs-2.0/new_features_2_0.html und ../mod/ werden die einzelnen Erweiterungen beschrieben. Letzentlich entnehme ich den Beschreibungen -wenn apache2, dann mit MPM, sonst macht es keinen Sinn 2.x überhaupt zu verwenden-.

MPM heißt "Multi-Processing Module", und ohne sowas funktioniert kein Apache2. Du kannst Dir halt das Modul auswählen, es gibt Module für spezielle Architekturen optimiert, wie z.B. Win32, und für Unix stehen eigentlich vor allem prefork und worker zur Auswahl, die anderen sien AFAIK noch nicht stabil. Per default wird auf Unix prefork-MPM verwendet, dieses entspricht in der Funktionsweise dem Apache 1.3, man kann alternativ das worker-MPM verwenden, welches ebenfalls mehrere Prozesse verwendet, allerdings auch mehrere Threads pro Prozess. Das ist bei statischen Inhalten kein Problem, daher würde ich in dem Fall durchaus dieses MPM wählen. Bei dynamischen Inhalten muss sichergestellt sein, dass sämtliche verwendeten Bibliotheken threadsafe sind, da es sonst zu diesen seltsamen Fehlern kommt.

Du kannst mit ldd nachsehen welche Bibliotheken Dein mod_php.so verwendet, siehe http://httpd.apache.org/docs-2.0/developer/thread_safety.html#commonlibs

Jetzt musst Du für jede der verwendeten Bibliothek sicher sein, dass sie Threadsafe ist.

PostgreSQL war nur ein Beispiel, das hat nicht prinzipiell was mit Datenbanken zu tun, das kann jede Bibliothek sein.

Jedenfalls stimmt für mich hier nicht das Verhältnis von Kosten/Risiko zum Nutzen, denn es wird sich auch kaum bemerkbar machen - es ist nicht so dass der Apache dann auf einmal doppelt so schnell PHP-Scripte ausliefert, und scon gar nicht mit der Thread-Implementierung des 2.4er Linux Kernels.

Ich sehe es allerdings nicht so hart mit Apache_2.0-prefork vs. Apache 1.3.
Natürlich, Apache 1.3 und mod_php haben sich Millionenfach bewährt, und laufen wirklich sehr stabil zusammen. Auf der anderen Seite, der Apache 2 wurde ja nicht zum Spaß entwickelt, sindern ist eine Weiterentwicklung, eine Verbesserung mit den Erfahrungen aus 1.3.

Wenn ich mir mal die Zeitpunkte der alten Releases ansehe: http://archive.apache.org/dist/httpd/old/

1. Alpha  03/2000
1. Beta   11/2001
1. Stable 04/2002

Das heißt da stecken jetzt weit über 4 Jahre Entwicklung drin, das Entwickler-Team ist so groß wie nie, seit über 2 Jahren gibt es eine stabile Version, und wenn ich das grob richtig abschätze:

http://www.securityspace.com/s_survey/data/200407/servers.html

wird Apache2 inzwischen auf über 1 Mio Webservern produktiv eingesetzt.

Das heißt, ich würde bei einer neuen Installation inzwischen auf Apache2 setzen, für statische Inhalte mit Worker-MPM, für dynamische mit Prefork-MPM.

Ich gebe zu, es ist nur eine theoretische Überlegung. Es werden in meinem home.net keine 300 Anfragen pro Sekunde anfallen, die dann auch noch mit PHP bedient werden. Also werde ich es mal mit worker versuchen.

Ich würde versuchen lokal möglichst ähnliche Software/Konfigurationen zu verwenden, wie auf dem produktiven System. Für Deine Ansprüche ist das relativ egal, da kann vermutlich die Thread-unsicherste Bibliothek verwendet werden, und es würde sicher nichts passieren. Würdest Du die selbe Konfiguration auf einem großen produktiven System verwenden, sieht die Sache auf einmal ganz anders aus. Ich würde defintiv Prefork empfehlen.

Interessieren würde es micht doch, welche Variante auf einem produktivem System (wovon noch abgeraten wird) bevorzugt einzusetzen ist.

Bei besonders kritischen Sachen vielleicht noch Apache 1.3, aber prinzipiell würde ich inzwischen immer Apache 2.0 mit Pefork-MPM verwenden. Und wie gesagt würde ich Test- und produktiv-System so ähnlich wie möglich konfigurieren. Gerade bei Thread-Problemen bringt Dir das herzlich wenig das erstmal auf dem Testsystem auszuprobieren, da die Fehler erst unter Last, also später im Live-Betrieb auftreten.

Grüße
Andreas