Montag, 28. Juni 2010
Python über FastCGI als CGI ausführen
Etwas, das mir des öfteren böse aufstößt,ist der Umstand, dass wir neben PHP keine weiteren Skripting-Sprachen im Webhosting anbieten. Zwar nicht oft, aber ab und zu wird halt danach gefragt und dann mit "Nein" zu antworten halte ich fast schon für Interessenten-Abschreckung 
Es gibt so einige Gründe, warum wir z.B. Python bisher nicht angeboten haben. Zwei davon wären: Skriptsprachen dürfen bei uns nicht innerhalb des Webservers laufen, sondern explizit mit den Rechten des jeweiligen Kunden. CGI scheidet aber aus Performance-Gründen aus, FastCGI ist Pflicht.
Nun mag man behaupten, dass Python ja FastCGI könne, doch ich verneine dies gerne, denn Python kann FastCGI nur dann, wenn das ausgeführte Skript es explizit kann. Hält man PHP nun dagegen, so ist dem Skript vollkommen egal, ob es nun eine Apache- oder IIS-SAPI, CLI, CGI- oder FastCGI-Schnittstelle ist, es funktioniert transparent. Diesen Zustand würde ich als "Python kann FastCGI" gelten lassen. Et voila:
In unserer Sandbox ist nun ein bisher voll funktionsfähiger (unentdeckte Fehler nicht mit eingeschlossen) Python-nach-FastCGI-Wrapper. Im Wesentlichen ist es ja nur ein FastCGI-Verbindung annehmen, Python-Interpreter vorbereiten, Ein- und Ausgabe umleiten und Skript ausführen. Dennoch: Es hat lange bis hier hin gedauert.
Und jeder der sich jetzt schon freut: Es wird auch noch ein bisschen dauern. Erst müssen wir noch weiter testen und fehlende Funktionalität, wie z.B. PHP's openbase_dir, nachrüsten.
Hier bietet sich das WSGI-Protokoll an, dass von eigentlich allen wichtigen Python-Webframeworks unterstützt wird. Der Apache lernt es über mod_wsgi.
Ich bin mir auch sicher, viele Leute würden Rails-Hosting gut finden. Dies geht zum Beispiel gut mit Phusion Passenger. Derzeit wird auch hier eine WSGI-Unterstützung eingebaut, sodass man Untersytützung für beides aus einer Hand bekommen kann.
Bei FastCGI-Support in der Applikation und nicht im Interpreter wäre das einzig Interessante Daten zwischen den Requests vorzuhalten. Das verkompliziert sich aber schon wieder, wenn mehrere FastCGI-Server parallel laufen bzw. kann dann auch gleich so gelöst werden, dass "stateless Applications" diese Informationen auch erhalten (siehe z.B. den Session-Grusel bei PHP).
Ich verstehe auch überhaupt nicht diesen Wirbel, der dort um WSGI herum gemacht wird. Da wird das Rad neu erfunden, wo es schon genügend andere funktionierende Schnittstellen gibt. Damit spaltet Python sich in einer Art Elite-Club erst einmal von der restlichen Welt ab. (Wenn Ruby auch WSGI unterstützen will ist das schmückend für das Projekt Ruby, der Rest bleibt unangetastet).
Ich wette fast, dass sowohl Django wie auch Turbogears im CGI-Modus laufen. Soweit ich weiß ist der zumindest nicht so unterschiedlich zu mod_python.
Was die ganzen Module für den Apachen angeht, so versuchen wir hier die Auswahl recht gering zu halten und alles über etablierte Schnittstellen von außen her anzubinden. Das macht in Sachen Wartung und Analyse wesentlich weniger Aufwand. Von den Problemen mit den Zugriffsrechten ganz zu schweigen
Bei deiner Lösung klingt es ein bisschen wie CGI mit FastCGI-Aufsatz. Die Idee bei FastCGI war damals doch explizit, dass du nicht mehr für jeden Request den Interpreter laden und die Anwendung initialisieren muss. Bei größeren Anwendungen ist das teilweise schon eine Menge Zeit. Deine Lösung klingt für mich eher danach, dass du jedesmal den Interpreter neu startest...
Um FastCGI (oder jeden anderen Ansatz mit persistenten Serverprozessen) korrekt zu implementieren kommst du also um Unterstützung in der Anwendung nicht wirklich herum, wenn du nicht viele der Vorteile verspielen willst.
Allerdings habe ich auch ein grundsätzliches Problem mit FastCGI, weil es als Protokoll extrem over-engineered ist. Die App-Server in der Java- und Ruby-Welt finde ich da wesentlich freundlicher
Der Clou ist, dass der Interpreter bei unserer Lösung "nur" zurückgesetzt wird, d.h. er ist die ganze Zeit bereits geladen und wartet nur darauf einen Skript zum Ausführen zu bekommen.
Dementsprechend sollte es genau so schnell wie jede andere FastCGI-Implementierung sein zzgl. der Zeit, die die eigentliche Python-Applikation zum "booten" braucht. Im Zweifel ist letzteres vernachlässigbar und in so einem "unspezifischen" Setup wie wir es betreiben scheint mir das die beste Lösung.
Ich habe mir WSGI allerdings nochmal auf die Liste gesetzt und wir werden wohl mal die wesentlichen Unterschiede herausarbeiten. Scheint ja auch einen WSGI-nach-FastCGI-Wrapper für Python zu geben
Aber: WSGI bei uns macht Fortschritte. Bei Python führt da wohl kein Weg dran vorbei.
Suche
Read this blog!
Kategorien
Blog abonnieren
Buttons
