[php] AW: [php] Daten im Hauptspeicher, File oder DB schneller?

[Kar-Wing Lau]

Hallo Juri,

>Das verstehe ich jetzt nicht ganz. Was ist ein Apache-Prozess in dem
>Fall?
>Ist's der WebServer? Falls nicht, dann wohl ein Apache-SubProzess, der
>von Apache gestarted wird, wenn man z.B. eine PHP Seite aufruft.
>Korrekt?

Also eigentlich beschreibt es Kristian Köhntopp mit seinem Artikel am
besten:

	"Webserver verstehen und tunen" von Kristian Köhntopp
	http://www.koehntopp.de/kris/artikel/webtune/

So wie es scheint, stellt ein Webserverchild, bzw. ein Apacheprozess in
diesem Falle ein sog. "Bearbeitungsprozess" dar. Es handelt sich also nicht
um den Webserver selbst, sondern, wie Du bereits beschrieben hast, um so
etwas wie "SubProzesse", welche die einzelnen Requests bearbeitet.

>Falls von diesem SubProzess aus ein weiterer Apache SubProzess (?) zu
>MySQL (pconnect) gestarted wird, was passiert nach dem Beenden des
>PHP SubProzesses? Bleibt der pconnect noch bestehen? Wenn ja, dann
>soll doch dieser pconnect-SubProzess von anderen PHP-SubProzessen
>geshared werden (falls User/Passwort/DB-Host-Tripel indentisch ist),
>sonst hat pconnect ja keinen Sinn.

Des weiteren steht im Artikel, dass PHP als .CGI abei Request von Skripten
ein PHP-Interpreterprozess gestartet wird, der am Ende der Seite alle
Datenbankverbindungen schliesst. Da bei der Modulversion von PHP,

"der Interpreter als Modul Bestandteil des Bearbeiterprozesses des
Webserverrs ist, kann dieser die Verbindung auch nach dem Ende der Webseite
offenhalten."
	-- Zitat "Webserver verstehen und tunen" von Kristian Köhntopp

Also scheinen pconnects nur bei der Modulversion was zu bringen. Ansonsten
werden die Prozesse nach dem Ende einer Webseite immer geschlossen. Ist auf
jeden Fall ein sehr empfehlenswerter Artikel.

In der Tat zeigen unsere ersten Erfahrungen mit schnell mal selbst
hingeschmierten, unrepresentativen Benchmarks, dass unser interner Celeron
500 NT-Server mit .CGI wegen des Prozessors bei statischen Seiten um Faktor
2 schneller ist als unser K6 Cobalt RaQ3. Kommt aber eine persistente
MySQL-Verbindung hinzu (PHP.CGI sucht dann automatisch eine normale
Connection) ist die normalerweise langsamere RaQ auf einmal  um Faktor 4
schneller.

Merkwürdig ist das schon, da alle mir bisher sagten, dass MySQL so schnell
ist, dass man es kaum bemerken würde. Das dachte ich auch, als wir Tests
fuhren und diese einen winzig kleinen Tick schneller waren. Erst später habe
ich das mit der .CGI- und der Modul-Version gelesen. Also waren das
anscheinend nur zufällige Streuungen. Anscheinend profitieren unsere Skripte
durch einen einzigen verwendeten MySQL-Tripel  derart enorm, so dass es zu
solch drastischen Ergebnissen kommt.

Nochmalige Betonung: dies ist nicht bereinigt (Konfigurationen, usw.) und
nicht repräsentativ und daher nur sehr schwer vergleichbar. Auch ist die
Ursache noch nicht vollständig geklärt (muss auch mal ins Bett... ;).

Gruss,
Kar-Wing