Python im Massenhosting - CGI pur oder Framework?

deamon · Montag 13. Oktober 2008, 14:34

Hallo,

für eine kleine Internetauftritte bieten sich die typischen Webhosting-Angebote mit ein paar MB-Speicherplatz, einer Datenbank und der Möglichkeit Skripte auszuführen, an. Soweit ich den Markt überblicke wird bei diesem sogenannten Shared Hosting, bei dem sich viele Kunden einen Server teilen, Python nur als CGI angeboten.

Wie würdet ihr in so einem Fall bei einer wirklich überschaubaren Anwendungen (max. ein paar hundert Zeilen Code) mit Python arbeiten? Mit CGI direkt? Oder mit WSGI und einem Framework?

Wenn Framework: welches?

CherryPy übernimmt ja z. B. auch die Sitzungsverwaltung und müsste dank WSGI auch mit CGI laufen, aber geht das wirklich? Müsste dazu nicht permanent ein Python-Prozess laufen? Oder werden die Sitzungen als Dateien gespeichert? Oder wäre für etwas kleines webpy besser? Einen besonders tollen Eindruck macht das auf mich eigentlich nicht.

Gruß
Christian

veers · Montag 13. Oktober 2008, 17:21

Wenn es wirklich nur 2, 3 Zeilen sind würde ich wohl einfach ein CGI schreiben. Wenn das nicht reicht würde ich mich nach einem passenderen Angebot umsehen, wo ich eigene Prozesse starten kann und diese dann über einen Proxy o.ä. betreiben.

http://djangohosting.ch/ bietet so etwas zum Beispiel an.

Wenn du etwas Erfahrung im Umgang mit Servern hast kannst du dir auch einfach einen VServer mieten. Dann bist du frei zu tun und lassen was du willst

lunar · Montag 13. Oktober 2008, 23:00

Ich würde selbst bei kleinen Anwendungen nie auf ein WSGI-Toolkit wie Werkzeug oder Paste und eine gute Templating-Engine verzichten. Wenn man darauf verzichten, dann implementiert man das automatisch selbst, weil es eben nötig ist, und macht sich so das Leben unnötig schwer.

Auf größere Frameworks wie Django oder Pylons kann man dagegen verzichten, wenn man deren Funktionalität nicht benötigt.

Leonidas · Montag 13. Oktober 2008, 23:47

lunar hat geschrieben:Ich würde selbst bei kleinen Anwendungen nie auf ein WSGI-Toolkit wie Werkzeug oder Paste und eine gute Templating-Engine verzichten. Wenn man darauf verzichten, dann implementiert man das automatisch selbst, weil es eben nötig ist, und macht sich so das Leben unnötig schwer.

Tendenziell würde ich auch in die Richtung gehen. CGI ist für wirklich kleine Sachen vielleicht nett, aber spätestens wenn man es irgendwie für irgendetwas was nicht mit einem simplen Datenbankquery erledigt ist einsetzen will schießt man sich auf mittellange Sicht gesehen in den Fuß mit CGI. Ich denke auch nicht, dass eine simple WSGI-Applikation so viel komplizierter ist als eine CGI-Applikation.

jens · Dienstag 14. Oktober 2008, 07:10

Ich nehme django

Zum Thema Webspace: [wiki]Python Webspace[/wiki]am besten ein Anbieter der fast_CGI hat.

veers · Dienstag 14. Oktober 2008, 08:14

Django über CGI zu verwenden ist abartig (langsam).

Y0Gi · Dienstag 14. Oktober 2008, 11:50

CherryPy über CGI sollte möglich sein, halte ich ähnlich wie Django und auch für kleine Anwendungen aber für keine gute Idee.

Werkzeug passt durch seine schlanke Linie dagegen sehr gut zu der Einfacheit von CGI und ist daher meine Empfehlung. Gegenüber dem ``cgi``-Modul der Standardbibliothek bringt es hübsche ``Request``- und ``Response``-Klassen mit, für dessen Genuss man früher noch ``mod_python`` nutzen wollte.

Nicht zu vergessen: Ein CGI-Script lässt sich zwar durch direkten Aufruf lokal einigermaßen ansprechen (lesend; mit Input wirds da schon deutlich schwieriger), doch lange nicht so komfortabel wie eine lokal "HTTP-geservte" WSGI-Anwendung, mit der man direkt über den Browser kommunizieren kann.

jens · Mittwoch 15. Oktober 2008, 15:44

Bitte mal bei [wiki]Web-Frameworks#WelchesFrameworkFrWen[/wiki] den Punkt "Welches Framework für wen" durchlesen

Leonidas · Mittwoch 15. Oktober 2008, 18:14

jens hat geschrieben:Bitte mal bei [wiki]Web-Frameworks#WelchesFrameworkFrWen[/wiki] den Punkt "Welches Framework für wen" durchlesen

Oh, die Seite habe ich ganz vergessen. Da könnte man auch etwas aktualisieren.

sma · Freitag 17. Oktober 2008, 09:00

Ich würde für eine kleinere Anwendung die Google App Engine mit in die Auswahl einbeziehen, insbesondere wenn "Massenhosting" bedeutet soll, dass mit einer großen Nutzung gerechnet wird. Die GAE benutzt ein API, welches an CGI erinnert, garantiert aber eine bessere Performance als wahrscheinlich jeder Shared-Hosting-Anbieter oder Dedicated Server. Man erkauft sich das Versprechen auf "unbeschränkte Skalierbarkeit" allerdings mit einem aufwendigeren und ungewohnten Persistenzmodell (der Datenspeicherung), welches man für eine Anwendung mit geringerer Nutzung basierend auf einer relationalen Datenbank wie MYSQL nicht benötigt. Dafür kostet die GAE nur das Vertrauen in Google und mal spart somit vielleicht ein paar Euros.

Die GAE-Programmierung könnte man z.B. mit Django vereinfachen - andere Webrahmenwerke sollen aber auch möglich sein.

Stefan

lunar · Freitag 17. Oktober 2008, 09:21

sma hat geschrieben:Dafür kostet die GAE nur das Vertrauen in Google und mal spart somit vielleicht ein paar Euros.

Vertrauen in Google ist aber für manche Menschen doch ein hoher Gegenwert. Ich persönlich zahle lieber vier Euro für gutes Shared Hosting, bei dem ich normale WSGI-Anwendungen laufen lassen kann, anstatt micht mit einer unportable GAE-Anwendung an Google zu binden.

deamon · Freitag 17. Oktober 2008, 09:29

Vielen Dank für eure Anworten!

Zusammenfassend sehen eure Empfehlungen für mich so aus:

* CGI nur für Anwendungen der Hallo-Welt-Liga
* WSGI dringend empfehlenswert
* Große Frameworks wie Django sind nicht empfehlenswert, wenn unter WSGI nur CGI läuft
* Bei WSGI über CGI sollte man nur ein kleines Web-Framework wie web.py verwenden.

Mir stellt sich allerdings die Frage, was an Frameworks noch "klein" ist. CherryPy erscheint mir auch recht schlank, dafür aber etwas ausgereifter als web.py. Im Gegensatz zu großen Frameworks verzichtet CherryPy auf wichtige Teile wie Persistenzschicht und Templates - ich wüsste also nicht, warum es so ein schlechtes Laufzeitverhalten haben sollte. Ganz abgesehen davon, braucht man immer irgendwie Templates.

Eine andere Frage, die ich mir im Zusammenhang mit WSGI stellt, ist, wie Sitzungsdaten gespeichert werden. Deckt WSGI das überhaupt ab? Im Hinterkopf habe ich das Java Servlet API, das sich um diese ganzen Details kümmert. Man kann sich darauf verlassen, dass ein Serlvet-Container die Sitzungen schon richtig verwalten wird. Wie ist das aber nun bei WSGI, das ja im Fall von CGI nicht einfach Sitzungsdaten im Hauptspeicher halten kann?

Ganz allgemein grübele ich, ob es derzeit überhaupt eine gute Idee, Python dort zu verwenden, wo PHP verwendet wird - beim Allerwelts-Webhoster. Denn da gibt es anscheinend nur CGI und dass das perfomance-mäßig nicht der Hit ist, ist ja schon mindestens 10 Jahre bekannt ...

Hyperion · Freitag 17. Oktober 2008, 09:35

deamon hat geschrieben: Ganz allgemein grübele ich, ob es derzeit überhaupt eine gute Idee, Python dort zu verwenden, wo PHP verwendet wird - beim Allerwelts-Webhoster. Denn da gibt es anscheinend nur CGI und dass das perfomance-mäßig nicht der Hit ist, ist ja schon mindestens 10 Jahre bekannt ...

Wieviele hundert parallelen Zugriffe erwartest Du denn?

Mal im Ernst: Die Performance ist doch bei geringen Zugriffen kein wirkliches Problem. Mir wäre da eine gute Strukturierung des Codes und der Daten wichtiger - und gut strukturierten PHP-Code findet man nicht so häufig.

sma · Freitag 17. Oktober 2008, 09:41

deamon hat geschrieben:Eine andere Frage, die ich mir im Zusammenhang mit WSGI stellt, ist, wie Sitzungsdaten gespeichert werden. Deckt WSGI das überhaupt ab?

Nein, im Gegensatz zu einem Servlet-Container musst du das selbst machen - oder einem Rahmenwerk oder eine entsprechenden Bibliothek überlassen.

Du könntest versuchen, alles clientseitig in (verschlüsselten) Cookies zu halten oder die Daten in einem versteckten Formular immer wieder mitzuschicken. Oder du musst dir etwas mit temporären Dateien oder eben einer Datenbank-gestützten Lösung überlegen. Bei der letzteren musst du auch noch irgendwie die abgelaufenen Sitzungen wieder loswerden, etwa mit einem Cron-Job.

Stefan

lunar · Freitag 17. Oktober 2008, 09:44

deamon hat geschrieben:Mir stellt sich allerdings die Frage, was an Frameworks noch "klein" ist. CherryPy erscheint mir auch recht schlank, dafür aber etwas ausgereifter als web.py. Im Gegensatz zu großen Frameworks verzichtet CherryPy auf wichtige Teile wie Persistenzschicht und Templates - ich wüsste also nicht, warum es so ein schlechtes Laufzeitverhalten haben sollte. Ganz abgesehen davon, braucht man immer irgendwie Templates.

Zu den nennenswerten "kleinen" Frameworks würde ich Werkzeug, Paste und CherryPy zählen. Von Exoten wie web.py würde ich die Finger lassen.

Meine Empfehlung tendiert wohl zu Werkzeug. Paste wäre ebenfalls eine Überlegung wert, allerdings benötigt man da ein bisschen länger, bis man durchblickt. Dafür bietet Paste imho die besseren Ansätze zum Deployment. CherryPy kenne ich nicht.

Für Datenhaltung und Templating musst du dann auf externe Module zurückgreifen, SQLAlchemy und Jinja2 wären da meine Präferenz.

Eine andere Frage, die ich mir im Zusammenhang mit WSGI stellt, ist, wie Sitzungsdaten gespeichert werden. Deckt WSGI das überhaupt ab? Im Hinterkopf habe ich das Java Servlet API, das sich um diese ganzen Details kümmert. Man kann sich darauf verlassen, dass ein Serlvet-Container die Sitzungen schon richtig verwalten wird. Wie ist das aber nun bei WSGI, das ja im Fall von CGI nicht einfach Sitzungsdaten im Hauptspeicher halten kann?

WSGI ist nur ein Kommunikationsprotokoll zwischen Webserver und Anwendung, mehr nicht. Alles andere ist Sache des Anwendungsentwicklers. Für Session-Management gibt es allerdings fertige Middleware-Module, einfach mal im Cheeseshop suchen.

Btw, für eine "schlanke" Anwendung ist ein Servlet wohl kein gutes Beispiel, hängt es doch von einem dicken Anwendungsserver ab.

sma · Freitag 17. Oktober 2008, 09:51

lunar hat geschrieben:Vertrauen in Google ist aber für manche Menschen doch ein hoher Gegenwert.

Nun, du musst dafür deinem Hoster trauen, dass er weder deine Daten missbraucht, weitergibt, noch durch Untätigkeit oder Unvermögen dazu beiträgt, dass er die Dienstleistung auch störungsfrei anbietet, nicht einfach aufgibt, dich nicht bei der Abrechnung betrügt, dich wechseln lässt (da hatte ich mal großen Ärger) und kontinuierlich gut erreichbar ist.

Für mich liegen die Kosten der GAE eher darin, dass man für ein spezielles Persistenzmodell entwickeln muss. Dieses kann man aber wohl inzwischen auch auf Django simulieren...

Stefan

Leonidas · Freitag 17. Oktober 2008, 12:24

lunar hat geschrieben:Von Exoten wie web.py würde ich die Finger lassen.

Mein Lieblingszitat dazu ist ja

<Chairos> it's funny... the bigger my webapp becomes, the fewer web.py features I use. because I'm replacing those "features" with other modules that actually work.

Gibt es denn überhaupt einen Google Businessplan? Weil ansonsten bietet GAE nur ein Versprechen von Skalierbarkeit, keine Skalierbarkeit an sich. Wenn das Freilimit übrschritten wird, also an dem Punkt wo man über Skalierbarkeit nachdenken müsste, bekommt man nämlich mit dem Umsonst-Account nämlich Probleme wie die Bandwidth Exceeded-Meldungen von Geocities und Co aus lang vergangenen Tagen.

Edit (Leonidas): Restliche Diskussion in "Welches Framework?" abgetrennt.