Fast-CGI – was steckt dahinter?

PHP als Modul des Apache nutzt – wie andere Scriptsprachen auch (beispielsweise Perl oder ASP) – das CGI, um Anfragen an einen Webserver zu senden und das Ergebnis an den Client zurück zu schicken. Für jede Anfrage muss dabei ein neuer Prozess angelegt werden, der nach der abgeschlossenen Bearbeitung des Scripts wieder beendet wird. Das Problem dabei ist, dass das Starten und Initialisieren sehr viel länger dauert als das eigentliche Ausführen des Scripts – es entsteht also ein großer Overhead. Hinzu kommt noch, dass für jedes Script ein eigener Interpreter in den Speicher geladen werden muss – dieser ist also mitunter mehrmals im Speicher präsent.
An dieser Stelle fragen sie sich wahrscheinlich, weshalb ständig neue Prozesse mit neuen Interpretern für jeden Request angelegt werden und warum nicht ein Interpreter-Prozess für alle Anfragen genutzt werden kann. Gute Frage. Ich sehe, sie denken mit 😉

FastCGI kann dabei helfen diesen angesprochenen Overhead massiv zu verringern (ganz eliminieren nicht, aber dazu später mehr). FastCGI kann man sich als große Endlos-Schleife vorstellen, die ständig auf Requests wartet. Der Prozess läuft also ständig und ist sofort einsatzbereit, wenn eine Anfrage an den Server ankommt. Die genaue Funktionsweise von FastCGI (unabhängig von PHP) ist bei Wikipedia beschrieben.

Wie genau kommt nun aber der Geschwindigkeitsvorteil von FastCGI gegenüber PHP als Apache-Modul zustande? Es ist nicht nur, dass der Interpreter nur ein mal geladen werden muss, sondern es kommen weitere beschleunigende Argumente hinzu.
FastCGI hat neben der großen Schleife auch die Eigenschaft alles zu cashen, was ihm zwischen die Finger kommt. Auf der Projektwebsite sind die Gründe für den Performance-Zuwachs übersichtlich geschildert, ich möchte es aber nochmal übersetzen und erläutern.
Weil das „übliche“ API für PHP für jede Anfrage einen neuen Prozess startet, können die Scripte sich Speicherinhalte auch nicht teilen – jeder Prozess hat seinen eigenen Speicherbereich und den kann er nutzen. Über den Tellerrand hinaus wird nicht geschaut, ob der gesuchte Wert eventuell bereits im Speicher vorhanden ist.
Der Interpreter als FastCGI kann ebenfalls mehrere Kindprozesse anlegen. Diese empfangen die Anfragen und – jetzt kommt der entscheidende Punkt – leiten sie an den FastCGI Application Server weiter. Dieser verwaltet einen Cache innerhalb des Speichers und kann den einzelnen Prozessen somit die nötigen Daten zuspielen. Das bedeutet weniger Redundanz im Speicher und dadurch natürlich auch insgesamt weniger Speicherbedarf bei Scripten, auf die viele parallele Zugriffe erfolgen.

Um die Zugriffe weiter zu beschleunigen werden Sessions gecacht. Das bedeutet, dass die Anfrage eines Users, der über eine bestimmte Session-ID eindeutig identifizierbar ist, genau auf den Kindprozess geleitet wird, wo die Daten des Users sich bereits im Cache befinden. Alle Anfragen des Users werden also immer auf den gleichen Kindprozess geroutet. Natürlich wird je User der Kindprozess ausgewählt, der im Moment am wenigsten ausgelastet ist, denn es hilft ja wenig, wenn alle User dem gleichen Kindprozess zugeteilt werden, während sich andere Kindprozesse langweilen. Diese Vorgehnsweise bezeichnet man als Session Affinity.

Toll ist auch, dass unter den Prozessen die Datenbank-Verbindung gecached wird. Das bedeutet, dass nicht ständig eine neue Verbindung zur Datenbank erstellt und wieder geschlossen werden muss. Dieses Feature ähnelt einer persistenten Datenbankverbindung, die über mysql_pconnect() erzeugt werden kann.

Das Kompilieren von PHP als Fast-CGI ist also durchaus sinnvoll, wenn man Wert auf performante und ressourcenschonende PHP-Verarbeitung legt. Wie genau bei der Installation vorzugehen ist, dem sei das Tutorial zur PHP5-Installation als FastCGI ans Herz gelegt.

Jan hat 157 BeitrÀge geschrieben

6 Kommentare zu “Fast-CGI – was steckt dahinter?

  1. Wanja sagt:

    Wenn man PHP als Fast-CGI verwenden möchte, sollte man sich mal mit dem Lighttpd Webserver ausseinander setzen. Ich benutze mittlerweile keinen einzigen Apache mehr 😉

  2. Tim sagt:

    Genau. Ich benutze inzwischen auch kein Apache mehr. Einziger Nachteil: Es werden keine .htaccess Dateien unterstützt. Das muss man alles in der Konfigurationsdatei einstellen. Neil Dökkalfar hat im LightTPD Forum gefragt, ob er ein .htaccess-kompatibles Plugin schreiben solle. Die meisten waren (leider) gegen ein solches Plugin. Ich habe dort auch meine Meinung gepostet. Allerdings hat er noch nicht geantwortet.
    Hier der Link zum Thread:
    http://forum.lighttpd.net/topic/1195

  3. jantar sagt:

    Bitte berichtigen, daß solange man keine FastCGI-Lizenzgebühren zahlen muß, FastCGI Inhalte ‚cachen‘ kann. Cashen hätte einen bitteren Beigeschmack.
    Sonst sehr informativ.

Eine Antwort schreiben

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert mit *

You may use these HTML tags and attributes: <a href=""> <blockquote cite=""> <pre lang=""> <b> <strong> <i> <em>