FastCGI

Ein Kunde betreibt auf einem Shared-Webhosting-Paket bei uns eine auf Typo3 basierende Website, welche in den letzten Tagen massive Zugriffszahlen verzeichnen konnte. Schön für den Kunden, schlecht aber für den Webserver: die dadurch entstandene Last war wirklich erheblich. Schließlich wird bei uns aus Sicherheitsgründen PHP als CGI ausgeführt, d.h. bei jedem Seitenzugriff wird der komplette PHP- und Typo3-Kram geladen, geparsed und ausgeführt.
Da nicht abzusehen ist wann oder ob die Zugriffszahlen wieder sinken werden, und ein Umzug auf einen anderen Hostingserver das Problem langfristig auch nicht beseitigen würde, wurde der Kunde gestern Abend kurzfristig auf FastCGI umgestellt, und gleichzeitig noch eAccelerator aktiviert.
Mit dem Apache-Modul mod_fastcgi bleiben PHP-Prozesse nach Ablauf des Scripts im Speicher vorhanden; bei erneutem Aufruf entfällt somit das Starten der PHP-Laufzeitumgebung, und dank eAccelerator auch das Parsen und Compilieren der Scripte. Der Geschwindigkeitsvorteil ist erheblich:

Webserver-Last

Wir werden allerdings weiterhin FastCGI nur für “spezielle” Kunden aktivieren; schließlich lohnt es sich nicht für nur minimal besuchte Websites eigene dedizierte PHP-Prozesse im Hintergrund laufen zu lassen.

Im Rahmen dieser Aktion sind aber gleich noch ein paar andere Ideen für die Integration in unser neues Verwaltungstool entstanden. :-)

7 Bemerkungen zu “FastCGI”

  1. Morty

    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?

  2. Klaus Keppler

    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.

  3. 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

  4. Klaus Keppler

    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.

  5. Morty

    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. :-)

  6. Klaus Keppler

    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. :)

  7. Jtb

    Gibt es einen Grund, dass mod_fastcgi verwendet wurde und nicht mod_fcgid?

Einen Kommentar schreiben