Kommentare zu: FastCGI http://www.rackblogger.de/2009/01/03/fastcgi/ We love to HOST you. :-) Fri, 18 May 2012 06:02:46 +0000 http://wordpress.org/?v=2.0.9 Von: Jtb http://www.rackblogger.de/2009/01/03/fastcgi/#comment-14009 Sun, 04 Jan 2009 11:16:33 +0000 http://www.rackblogger.de/2009/01/03/fastcgi/#comment-14009 Gibt es einen Grund, dass mod_fastcgi verwendet wurde und nicht mod_fcgid? Gibt es einen Grund, dass mod_fastcgi verwendet wurde und nicht mod_fcgid?

]]> Von: Klaus Keppler http://www.rackblogger.de/2009/01/03/fastcgi/#comment-14000 Sun, 04 Jan 2009 00:34:42 +0000 http://www.rackblogger.de/2009/01/03/fastcgi/#comment-14000 Yo, und was ausgelagert wird, soll wohl auch irgendwann mal wieder eingelagert werden. Ein Prozess, der Speicher angefordert hat, muss dann ggf. darauf warten bis ein anderer Prozess Seiten ausgelagert hat. Swapping will nach Möglichkeit vermieden werden. :) Yo, und was ausgelagert wird, soll wohl auch irgendwann mal wieder eingelagert werden. Ein Prozess, der Speicher angefordert hat, muss dann ggf. darauf warten bis ein anderer Prozess Seiten ausgelagert hat.
Swapping will nach Möglichkeit vermieden werden. :)

]]> Von: Morty http://www.rackblogger.de/2009/01/03/fastcgi/#comment-13999 Sun, 04 Jan 2009 00:14:58 +0000 http://www.rackblogger.de/2009/01/03/fastcgi/#comment-13999 Wenn ich das richtig sehe ist die RSS aber nur die eingelagerte Speichermenge. Wenn ich das richtig versthehe heißt dies nicht, dass bei Bedarf nicht weitere Seiten ausgelagert werden. Wobei ich einsehe, dass bei 40 MB ein Raid 0 ganz Sinnvoll sein kann. :-) Wenn ich das richtig sehe ist die RSS aber nur die eingelagerte Speichermenge. Wenn ich das richtig versthehe heißt dies nicht, dass bei Bedarf nicht weitere Seiten ausgelagert werden. Wobei ich einsehe, dass bei 40 MB ein Raid 0 ganz Sinnvoll sein kann. :-)

]]> Von: Klaus Keppler http://www.rackblogger.de/2009/01/03/fastcgi/#comment-13998 Sat, 03 Jan 2009 23:39:20 +0000 http://www.rackblogger.de/2009/01/03/fastcgi/#comment-13998 Hallo Dominik, schon klar, ich meinte auch nicht pro Virtual Host, sondern pro Prozess. Beim Prefork-MPM können durchaus mehrere FastCGI-Server-Instanzen gestartet werden (sieht man z.B. in der Prozessliste unter http://www.rackblogger.de/wp-content/uploads/2009/01/fcgi.jpg). Ein "reifer" PHP-Prozess (mit Typo3 und einigen Extensions) kann dabei durchaus mal 40 MB groß werden - in dem Screenshot sieht man z.B. schon eine Instanz mit 22 MB. Ich will damit nur zum Ausdruck bringen, dass für das "Massenhosting" FastCGI meiner Meinung nach nur bedingt geeignet ist; bei sehr selten besuchten Sites dürfte die normale CGI-Ausführung ressourcensparender sein. Etwas sauberer ist die Kombination aus Worker-MPM (statt Prefork) mit FastCGI, da hier durch die entkoppelte CGI-Schnittstelle verschiedene Prozesse auf den selben FastCGI-Server eines Users zugreifen können. Hallo Dominik,

schon klar, ich meinte auch nicht pro Virtual Host, sondern pro Prozess. Beim Prefork-MPM können durchaus mehrere FastCGI-Server-Instanzen gestartet werden (sieht man z.B. in der Prozessliste unter http://www.rackblogger.de/wp-content/uploads/2009/01/fcgi.jpg).

Ein “reifer” PHP-Prozess (mit Typo3 und einigen Extensions) kann dabei durchaus mal 40 MB groß werden - in dem Screenshot sieht man z.B. schon eine Instanz mit 22 MB.

Ich will damit nur zum Ausdruck bringen, dass für das “Massenhosting” FastCGI meiner Meinung nach nur bedingt geeignet ist; bei sehr selten besuchten Sites dürfte die normale CGI-Ausführung ressourcensparender sein.

Etwas sauberer ist die Kombination aus Worker-MPM (statt Prefork) mit FastCGI, da hier durch die entkoppelte CGI-Schnittstelle verschiedene Prozesse auf den selben FastCGI-Server eines Users zugreifen können.

]]> Von: Dominik http://www.rackblogger.de/2009/01/03/fastcgi/#comment-13996 Sat, 03 Jan 2009 23:01:38 +0000 http://www.rackblogger.de/2009/01/03/fastcgi/#comment-13996 Hallo Klaus, irgend etwas habt Ihr da falsch verstanden... Bei fastcgi wird nicht für jeden Kunden (VirtualHost) immer ein PHP-Prozess gestartet, sondern nur bei Bedarf - und genauso werden sie auch wieder beendet. D.h. es gibt wesentlich weniger PHP-Prozesse als Vhosts. Und ein inaktiver PHP-Prozess verbraucht auch keine 40-50MB Ram. Meine Erfahrung spricht eher von ca, 8MB (natürlich immer abhängig von den installierten Erweiterungen, aber die Größenordnung ist auf jeden Fall eine andere als 50MB). Falls das bei Euch doch wesentlich anders aussieht, vermute ich eher Probleme in der Konfiguration. Viele Grüße, Dominik Hallo Klaus,

irgend etwas habt Ihr da falsch verstanden… Bei fastcgi wird nicht für jeden Kunden (VirtualHost) immer ein PHP-Prozess gestartet, sondern nur bei Bedarf - und genauso werden sie auch wieder beendet. D.h. es gibt wesentlich weniger PHP-Prozesse als Vhosts. Und ein inaktiver PHP-Prozess verbraucht auch keine 40-50MB Ram. Meine Erfahrung spricht eher von ca, 8MB (natürlich immer abhängig von den installierten Erweiterungen, aber die Größenordnung ist auf jeden Fall eine andere als 50MB). Falls das bei Euch doch wesentlich anders aussieht, vermute ich eher Probleme in der Konfiguration.

Viele Grüße, Dominik

]]> Von: Klaus Keppler http://www.rackblogger.de/2009/01/03/fastcgi/#comment-13987 Sat, 03 Jan 2009 13:16:12 +0000 http://www.rackblogger.de/2009/01/03/fastcgi/#comment-13987 Erstmal wird nicht der komplette Prozess ausgelagert (sieht man im 'ps'-Befehl in der Spalte 'RSZ' (resident set size)), das sind auch beim einem Idle-FastCGI-Kunden noch rund 40-50 MB. Vor allem aber wird das ganze Servermanagement unübersichtlicher, wenn neben 100 Apache-Prozesse noch tausende FastCGI-Prozesse laufen. Schließlich startet bei der Prefork-MPM im dümmsten Fall jeder Apache-Prozess einen eigenen FastCGI-Server pro Endkunden -> wird also ziemlich schnell ziemlich voll. Worker-MPM kommt derzeit nicht in Frage (längere Geschichte...). Bei seltenen Aufrufen gibt es über FastCGI auch keinen so deutlichen Performancevorteil mehr, dass sich dieser ganze Mehraufwand lohnen würde. Erstmal wird nicht der komplette Prozess ausgelagert (sieht man im ‘ps’-Befehl in der Spalte ‘RSZ’ (resident set size)), das sind auch beim einem Idle-FastCGI-Kunden noch rund 40-50 MB. Vor allem aber wird das ganze Servermanagement unübersichtlicher, wenn neben 100 Apache-Prozesse noch tausende FastCGI-Prozesse laufen. Schließlich startet bei der Prefork-MPM im dümmsten Fall jeder Apache-Prozess einen eigenen FastCGI-Server pro Endkunden -> wird also ziemlich schnell ziemlich voll. Worker-MPM kommt derzeit nicht in Frage (längere Geschichte…).
Bei seltenen Aufrufen gibt es über FastCGI auch keinen so deutlichen Performancevorteil mehr, dass sich dieser ganze Mehraufwand lohnen würde.

]]> Von: Morty http://www.rackblogger.de/2009/01/03/fastcgi/#comment-13985 Sat, 03 Jan 2009 12:30:07 +0000 http://www.rackblogger.de/2009/01/03/fastcgi/#comment-13985 Wo genau ist das Problem Prozesse im Hintergrund laufen zu haben? Wenn nichts passiert müsste der Prozess doch recht schnell ausgelagert werden und auf ein Signal warten. Die zusätzliche Rechenzeit bei der Verarbeitung von Signalen ist, denke ich, vernachlässigbar. Und wenn ich das richtig überschlage ist auch die CPU-Last auf 1/6 runter. Was sich sicher erhöht ist der I/O Durchsatz zur Festplatte. Ich kann mir aber nicht vorstellen, dass dieser die Zugriffszeiten merklich beeinflusst. Oder übersehe ich da etwas? Wo genau ist das Problem Prozesse im Hintergrund laufen zu haben? Wenn nichts passiert müsste der Prozess doch recht schnell ausgelagert werden und auf ein Signal warten. Die zusätzliche Rechenzeit bei der Verarbeitung von Signalen ist, denke ich, vernachlässigbar. Und wenn ich das richtig überschlage ist auch die CPU-Last auf 1/6 runter. Was sich sicher erhöht ist der I/O Durchsatz zur Festplatte. Ich kann mir aber nicht vorstellen, dass dieser die Zugriffszeiten merklich beeinflusst. Oder übersehe ich da etwas?

]]>