FastCGI
aus Wikipedia, der freien Enzyklopädie
| FastCGI | |
|---|---|
| Entwickler: | Fast CGI Team |
| Aktuelle Version: | 2.4.2; (23. November 2003) |
| Betriebssystem: | Windows, Linux, Mac OS X |
| Kategorie: | Common Gateway Interface |
| Lizenz: | Eigene |
| Deutschsprachig: | nein |
| Website: | www.fastcgi.com |
FastCGI ist ein Standard für die Einbindung externer Software zur Generierung dynamischer Webseiten in einem Webserver. FastCGI ist damit vergleichbar zum Common Gateway Interface (CGI), wurde jedoch entwickelt, um dessen Performance-Probleme zu umgehen.
Inhaltsverzeichnis |
[Bearbeiten] Unterschied zu CGI
Beim Aufruf einer auf CGI basierenden Webseite wird vom Webserver ein Prozess des CGI-Programms gestartet und am Ende des Requests wieder beendet. Weil CGI-Programme häufig in einer Skriptsprache wie Perl geschrieben sind, bedeutet das, dass pro Seitenaufruf der oft recht umfangreiche Interpreter geladen werden muss, was einen großen Overhead bedeutet (das Laden des Interpreters dauert bei einfachen CGI-Programmen länger als die eigentliche Programmausführung). Zudem braucht jeder Request einen eigenen Interpreter, d. h. bei mehreren parallelen Requests befinden sich entsprechend mehrere Kopien des Interpreters im Arbeitsspeicher des Servers. CGI hat zwar durch seine Einfachheit, Unabhängigkeit von der Programmiersprache und weitreichende Unterstützung durch praktisch alle Webserver eine sehr weite Verbreitung gefunden, jedoch führt der erwähnte Overhead zu einer hohen Latenzzeit und bei stark ausgelasteten Servern schnell zu einer Überlastung.
Im Unterschied dazu wird bei FastCGI das auszuführende Programm (incl. Interpreter, falls nötig) nur einmal geladen und steht dann für mehrere Requests zur Verfügung – egal ob vom selben Client oder von unterschiedlichen Clients. Die Kommunikation mit dem Webserver erfolgt dabei nicht durch Umgebungsvariablen und Standardein-/ausgabe, sondern über Unix Domain Sockets oder TCP-Netzwerkverbindungen, d. h. das Programm kann sogar auf einem anderen Rechner laufen.
Programmiertechnisch lässt sich der Unterschied zu CGI- Programmen daran festmachen, dass ein FastCGI Programm eine zentrale Schleife hat, die Requests entgegennimmt und durchaus solange laufen kann wie der Webserver:
use FCGI;
$var = 'foo';
while (FCGI::accept () >= 0) {
... http-Request bearbeiten ...
}
Während des Durchlaufens dieser Schleife bleiben Variablen im Speicher erhalten, was einerseits weitere Optimierungsmöglichkeiten gegenüber CGI- Programmen ermöglicht, andererseits eine sorgfältigere Programmierung erfordert, um Speicherlecks (memory leaks) zu vermeiden.
[Bearbeiten] Funktionsweise
Die Kommunikation mit dem Webserver erfolgt paketorientiert und verbindungslos. Ein Datenpaket enthält im Header die FastCGI-Protokollversion, den Nachrichtentyp, eine Request-ID und die Länge der folgenden Daten. Der Nachrichtentyp entspricht dabei weitgehend den aus CGI bekannten Datenquellen – ein Paket kann u. a. die CGI-Umgebungsvariablen, den Inhalt der Standardeingabe (für POST) oder der Standardausgabe (für die Ausgabe an den Client) transportieren. Mehrere Clients können gleichzeitig bedient werden, da sie sich anhand der Request-ID unterscheiden lassen; darum ist im Unterschied zu CGI nur eine Programminstanz nötig, um viele Clients bedienen zu können.
[Bearbeiten] Heutige Bedeutung
FastCGI hat trotz deutlicher Vorteile nie annähernd die Bedeutung von CGI zur Erzeugung dynamischer Webseiten gewonnen, vor allem weil sich gleichzeitig einfacher zu handhabende Lösungen etabliert haben, wie PHP, Active Server Pages oder JavaServer Pages. Diese sind als Modul im Webserver eingebunden und vermeiden dadurch ebenfalls, dass bei jedem Aufruf ein Interpreter geladen werden muss; zudem kann deren Performance durch automatische Kompilierung und Caching des Programmcodes gesteigert werden, so dass sie in ähnliche Geschwindigkeitsbereiche kommen wie externe FastCGI-Programme.
Diese Interpretersprachen haben gegenüber CGI/FastCGI den Vorteil, dass man den Programmcode direkt in die HTML-Seiten einbinden kann; dies ist bequemer und vermeidet Probleme mit falsch gesetzten Zugriffsrechten für ausführbare Dateien. Zudem stehen fertige Funktionen zur Verfügung, mit denen z.B. auf URL-Parameter oder Session-Daten zugegriffen werden kann, während ein CGI- oder FastCGI-Programm diese Funktionen selber implementieren bzw. über eine passende Programmbibliothek einbinden muss.
CGI und FastCGI bieten jedoch den Vorteil, die Programmiersprache selbst wählen zu können (was für hardware- oder systemnahe Anwendungen wichtig sein kann); außerdem kann man bei einem externen Programm dessen Dateiberechtigungen beliebig restriktiv einstellen, es unter einem anderen Benutzer-Account und/oder auf einem anderen Rechner laufen lassen (Letzteres nur bei FastCGI); ein Webserver-Modul einer Interpreter-Sprache läuft dagegen immer auf dem Webserver mit dessen Berechtigungen.
Aus diesen Gründen wird FastCGI mit kompilierten Programmen selten eingesetzt, weil andere Lösungen einfacher zu handhaben sind bei vergleichbarer Performance. Es ist jedoch recht verbreitet, den Interpreter einer Skriptsprache als FastCGI-Programm zu betreiben, weil man dadurch wenig Overhead hat (der Interpreter muss nur einmal geladen werden, nicht bei jedem Request) und trotzdem die Berechtigungen des Interpreters viel genauer einstellen kann als beim Betrieb als Webserver-Modul. Daher wird dies von Providern beispielsweise für PHP oft genutzt.
