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
Python im Massenhosting - CGI pur oder Framework?
- veers
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
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
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
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
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.
Auf größere Frameworks wie Django oder Pylons kann man dagegen verzichten, wenn man deren Funktionalität nicht benötigt.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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.
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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Oh, die Seite habe ich ganz vergessen. Da könnte man auch etwas aktualisieren.jens hat geschrieben:Bitte mal bei [wiki]Web-Frameworks#WelchesFrameworkFrWen[/wiki] den Punkt "Welches Framework für wen" durchlesen
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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
Die GAE-Programmierung könnte man z.B. mit Django vereinfachen - andere Webrahmenwerke sollen aber auch möglich sein.
Stefan
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.sma hat geschrieben:Dafür kostet die GAE nur das Vertrauen in Google und mal spart somit vielleicht ein paar Euros.
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 ...
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
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
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.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 ...
Nein, im Gegensatz zu einem Servlet-Container musst du das selbst machen - oder einem Rahmenwerk oder eine entsprechenden Bibliothek überlassen.deamon hat geschrieben:Eine andere Frage, die ich mir im Zusammenhang mit WSGI stellt, ist, wie Sitzungsdaten gespeichert werden. Deckt WSGI das überhaupt ab?
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
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.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.
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.
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.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?
Btw, für eine "schlanke" Anwendung ist ein Servlet wohl kein gutes Beispiel, hängt es doch von einem dicken Anwendungsserver ab.
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.lunar hat geschrieben:Vertrauen in Google ist aber für manche Menschen doch ein hoher Gegenwert.
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
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Mein Lieblingszitat dazu ist jalunar hat geschrieben:Von Exoten wie web.py würde ich die Finger lassen.
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.<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.
Edit (Leonidas): Restliche Diskussion in "Welches Framework?" abgetrennt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice