Prinzipielle Fragen zu den Python Application Servern

[leoel]

Hallo!

Ich habe da mal eine prinzipielle Frage:

Habe früher mal PHP programmiert und das war es eben so, dass bei jedem Request das entpsrechende File geparst, die Objekte generiert und evtl. ein paar Session-Daten aus des Session-Files geholt wurden. (d.h. persistente Daten im Speicher gab es nicht, nur auf File bzw. DB-Ebene)

Hab jetzt in letzter Zeit wenig gemacht und will wieder mal was web-lastiges machen

Wie funktionieren eigentlich die Web-App-Server bzw. Frameworks von Python (Zope, CherryPy, Django, TurboGears etc.) im Prinzip? Wie werden da die persistenten Daten gehalten? Wird da auch bei jedem Request das komplette File geparst und die entsprechenden Objekte generiert oder hält das der Application- bzw. Framework-Server im Speicher?

Vielen Dank, Leo

[jens]

Eine kleine Übersicht liefert der Punkt "Ich möchte Python in Webseiten nutzen." aus der FAQ
Ein Übersicht über die vorhanden Web-Frameworks bietet http://www.pythonwiki.de/PythonWeb

[leoel]

Hallo Jens!

Danke für die Links, die kenne ich schon. Mir geht es v.a. darum Business-Logik und Darstellung zu trennen. Und der PHP-Ansatz (parse immer alles ein und generiere deine Objekte neu) gefällt mir gar nicht, die Persistenz ist auf Datenebene, und nicht auf Objekt-Ebene (okay, ich könnte "pickle" verwenden).

Jetzt wollte ich eben fragen, wie die oben genannten Server-Lösungen prinzipiell funktionieren (ohne dass ich mich durch 1000 Seiten Doku / SourceCode) kämpfe.

Weil wenn die ähnlich funktioneren, dann bau ich mir einen Pyro-Server, habe meine Business Objects persistent im Speicher (die Applikation ist nicht geschäftskritisch, Daten werden regelmäßig als XML-File gespeichert) und die Websteiten (denke zur Zeit an Myghty) setzen Pyro-Calls ab

==> Hab jetzt keine Ahnung, ob das wirklich die beste Lösung ist, aber ich machs v.a. aus Spass.#

Warum ich so auf Speicher-Resitenz poche:
die Daten, die inhaltlich von den Benutzer bearbeitet werden, sind XML-Dateien und ich will nicht mit jedem Request (siehe PHP) mir den gesammten DOM-Tree aufbauen.

Stelle mir daher vor, dass ich pro Session eben einen (und nur einen) DOM-Tree im Speicher habe und via Pyro auf die entsprechenden persistenten Sessions zugreife.

[jens]

Also ich kenn bisher nur CGI, da wäre pickle eine Lösung. Nur ist die Frage ob es sich von der Preformance sich überhaupt lohnen würde. Also ob das picklen immer schneller als das neu einlesen des XML ist...

Ich denke echte persistenten Sessions bietet erst fast_CGI oder mod_python. Aber die direkt zu benutzten ist IMHO nicht empfehlenswert... Deswegen hab ich auf http://www.pythonwiki.de/PythonWeb verwiesen. Da gibt es fertige Frameworks, die das leben leichter machen sollten...

Aber hast du überhaupt ein Preformance problem mit deinem jetztigen Programm, oder interessiert es dich nur so?

[leoel]

nein, ich habe noch kein Performance-Problem, weil ich noch am Planen bzw. an den Grundlangen bin und deshalb interessiert es mich einfach so.

Bzgl. mod_python:
HAb gar nicht gewusst, dass mod_python persistente Sessions hat, aber warum ist das nicht empfehlenswert?

Was spricht eigentlich gegen mod_python?

[jens]

Also ich bin mir da auch nicht so sicher. Wie gesagt, ich kenn eigentlich nur CGI...
Kann auch sein, das es ehr ein Feature der Frameworks ist... Keine Ahnung...

Hier im Forum wurde des öfteren von mod_python abgeraten, kannst du ja einfach mal suchen, oder hier... Über fast_CGI wurde bisher nicht viel geredet...

Das alles ist aber gerade ein recht interessantes, aktuelles Thema. Blackbird hatte ja angefangen mit WSGIarea, hat es aber nun zu gunsten von pythonpaste aufgegeben...

Ich dachte eigentlich ich setzte auch auf WSGI... Nun weiß ich allerdings nicht, ob pythonpaste was für mich ist, mal sehen...

[gerold]

Wie funktionieren eigentlich die Web-App-Server bzw. Frameworks von Python (Zope, CherryPy, Django, TurboGears etc.) im Prinzip? Wie werden da die persistenten Daten gehalten? Wird da auch bei jedem Request das komplette File geparst und die entsprechenden Objekte generiert oder hält das der Application- bzw. Framework-Server im Speicher?

Hi Leo!

Also bei Zope läuft das so:

Zope baut komplett auf die Objekt-Datenbank ZODB auf. ZODB hält die Daten in einer Datenbankdatei. Man kann das System auch mit mehreren Datenbankdateien aufpeppen, aber das ist jetzt nicht wichtig.

Wenn du in Zope eine Datei anlegst, dann wird diese in die ZODB gespeichert. Damit Zope nicht jedes mal beim REQUEST die Daten von der Festplatte lesen muss, hat es eine recht ausgeklügeltes Cache-System eingebaut. Man kann statische Teile der Website ständig im Speicher halten, oder auch dynamisch generierte Teile so lange im Speicher halten, bis sich wieder mal etwas am Ergebnis der dynamischen Seite geändert hat. Natürlich gibt es bei Zope auch eine zeitabhängige Rotation. Man kann also einstellen, wie lange eine Seite im Cache bleiben soll.

Sogar Datenbankabfragen können kontrolliert gechached werden. Dabei kann Zope aber nur nach der Zeit gehen. Es prüft nicht, ob sich etwas an der Datenbank geändert hat, sondern cached die Abfrage so lange, bis die Zeit abgelaufen ist. Ob und wie lange eine Datenbankabfrage gechached werden soll, ist natürlich einstellbar.

Wenn man also einen Computer mit viel Speicher hat, kann man Zope mehr von diesem zur Verfügung stellen. Auch die Anzahl der Threads kann frei eingestellt werden. Bei Zope gilt also "Viel Speicher bringt viel."

mfg
Gerold

[Leonidas]

Wie funktionieren eigentlich die Web-App-Server bzw. Frameworks von Python (Zope, CherryPy, Django, TurboGears etc.) im Prinzip? Wie werden da die persistenten Daten gehalten? Wird da auch bei jedem Request das komplette File geparst und die entsprechenden Objekte generiert oder hält das der Application- bzw. Framework-Server im Speicher?

Also Zope hat ja gerold schon erklärt und da CherryPy eine Untermenge von TurboGears ist kann ich dir ein wenig von TG und Django erzählen. Zuerst Django, da ich das vor TG probiert habe:

Django wird meist in Apache mit mod_python eingebunden. Wie genau es funktioniert, ob es persistent ist, weiß ich nicht genau, aber da es auf vielen Seiten im Produktiveinsatz läuft, würde ich sagen, dass es Persistent ist. Ein Session-Handling hat es, du hast eine ganze Menge Dateien, davon eine, die die URLs auf Python-Funktionen mappt (mit Regexes). Das sieht so aus, dass wenn ein Request kommt, wird diese Datei ausgewertet und dann die passende Funktion aufgerufen. Also wenn du Geschwindigkeit brauchst ist Django wohl empfehlenswert, es hat auch Cache-Features, so dass die Funktionen nicht immer neue aufgerufen werden müssen.

Allerdings hat mir der Do-it-yourself Ansatz nicht besonders gefallen hat (und der Charakter von Adrian Holovaty etwas an Theo de Raadt erinnert, "wir sind die besten, die anderen haben doch keine Ahnung") habe ich TurboGears angeschaut. Dieses nutzt CherryPy als HTTP-Server (man kann CherryPy auch in den Apachen einbinden) und somit läuft es persistent. Im SVN für Version 0.9 ist auch eine Identity-Funktionalität eingebaut, so kannst du Sessions verwalten. Es sieht so aus, dass der CherryPy-Server läuft und je nach Request eine passende Funktion aus der Datei controllers.py aufruft, ähnlich wie Django nur ohne Regex. Ist zwar weniger flexibel, dafür fühlt es sich irgendwie pythonischer an. Diese Funktion arbeitet ihren Code ab und gibt einen Rückgabewert. Dieser wird dann an das passende Templete geschickt, dieses wird dann ausgefüllt und zum Client als Response geschickt.

Allerdings ist sowohl im Django als auch im TurgoGears-Lager sehr viel los, so sind die Änderungen in TG von 0.5 auf 0.8 klein, die von 0.8 auf das bald zu erwartende 0.9 phänomenal.

[mitsuhiko]

Django wird meist in Apache mit mod_python eingebunden.

Django hat aber auch eine WSGI Bridge.

[jens]

Django hat aber auch eine WSGI Bridge.

TurboGears aber nicht, oder?

[Leonidas]

TurboGears aber nicht, oder?

Nein. Aber CherryPy und somit kann auch TG die nutzen.

[leoel]

Okay, dann vielen Dank. Bin ein bisschen schlauer geworden (aber noch nicht ganz schlau) und bin auch spannend was zwischen Django und TurboGears rauskommt..

thanks a lot
lg Leo

[jens]

Wenn du neues weist, dann schreib es bitte! Vielleicht sollte man das Wiki mal ein wenig in der Richtung ausarbeiten...