Das deutsche Python-Forum

Hallo,

benutzt hier jemand Amazon AWS und dynamoDB ?

Ich muss mich nämlich für ein Framework entscheiden.
Ich liebe lightweight Frameworks wie zB webapp2.

Das Problem was ich momentan habe ist, das manche Frameworks nicht kompatible mit dynamoDB sind.
zB Tornado -> da gibt es ein opensource Projekt - asyncdynamo - das scheint aber outdated zu sein.
Laut ein paar "Foren" beiträgen schein Tornado momentan das schnellste WSGI zu haben. Gibt es noch andere gleich schnelle alternativen ?

Welche Frameworks stehen mir zur auswahl ?

Hallo,

Laut ein paar "Foren" beiträgen schein Tornado momentan das schnellste WSGI zu haben. Gibt es noch andere gleich schnelle alternativen ?

Welche Zugriffszahlen erwartest du denn? Vielen (private) Webseiten bzw. Internet-basierte Dienste haben gar nicht so viel Traffic, dass man sich ernsthaft Gedanken über die Ausführungsgeschwindigkeit sein Applikation Gedanken machen muss. Abgesehen davon, dass deine Applikation bei DB-Zugriffen oft auf die DB warten muss.

Zu Python + Amazon habe ich gerade auf die schnelle http://boto.readthedocs.org/en/latest/index.html gefunden. Kenne ich selber aber nicht.

Gruß, noisefloor

noisefloor hat geschrieben:Hallo,

Laut ein paar "Foren" beiträgen schein Tornado momentan das schnellste WSGI zu haben. Gibt es noch andere gleich schnelle alternativen ?

Welche Zugriffszahlen erwartest du denn? Vielen (private) Webseiten bzw. Internet-basierte Dienste haben gar nicht so viel Traffic, dass man sich ernsthaft Gedanken über die Ausführungsgeschwindigkeit sein Applikation Gedanken machen muss. Abgesehen davon, dass deine Applikation bei DB-Zugriffen oft auf die DB warten muss.

Zu Python + Amazon habe ich gerade auf die schnelle http://boto.readthedocs.org/en/latest/index.html gefunden. Kenne ich selber aber nicht.

Gruß, noisefloor

Wir erwarten recht viel Traffic deswegen machen wir uns sorgen um Zugriffszeiten etc. Allerdings wird unsere Database garnicht so stark belastet.
Btw boto (soweit ich weiß) ist nur ein Interface für die Amazon features, kein Framework.

Ich denke tornado sieht ganz vielversprechend aus, leider kann ich es noch nocht testen da ich für amazon erst eine kreditkarte benötige :/.

tornado hat mit WSGI nix zu tun. Bzw. wenn man tornado als WSGI-applikation betreibt verliert man exakt das, weswegen man tornado ueberhaupt einsetzte: die Asynchronizitaet.

http://www.tornadoweb.org/documentation ... pplication

Wenn ihr also WSGI einsetzt, dann nehmt gleich bottle oder flask oder was auch immer.

Und boto ist so out-of-the-box auch nicht asynchron. Da waere es besser, das mittels des asynchronen httpclient von tornado nochmal selbst zu re-implementieren. Ist ja nicht wirklich soooo schwer, bzw. vielleicht kommt ein nettes FOSS-projekt bei rum, boto asynchron zu machen

deets hat geschrieben:tornado hat mit WSGI nix zu tun. Bzw. wenn man tornado als WSGI-applikation betreibt verliert man exakt das, weswegen man tornado ueberhaupt einsetzte: die Asynchronizitaet.

http://www.tornadoweb.org/documentation ... pplication

Wenn ihr also WSGI einsetzt, dann nehmt gleich bottle oder flask oder was auch immer.

Und boto ist so out-of-the-box auch nicht asynchron. Da waere es besser, das mittels des asynchronen httpclient von tornado nochmal selbst zu re-implementieren. Ist ja nicht wirklich soooo schwer, bzw. vielleicht kommt ein nettes FOSS-projekt bei rum, boto asynchron zu machen

Ich bin gerade richtig verwirrt.

Okay tornado hat eine eigene server soltuion die async funktioniert. WSGI ist nicht async, dh WSGI kann nicht so viele gleichzeitige Zugriffe haben wie tornado, sehe ich das richtig ?

So was ist denn jetzt mit nginx ?
Wenn ich über nginx lese ist es manchmal ein Webserver und manchmal ein Loadbalancer.

Hier zb ist es ein Webserver
http://icesquare.com/wordpress/nginx-vs ... benchmark/

Hier ist nginx ein loadbalancer
http://www.tornadoweb.org/documentation ... production

Kann mich jemand aufklären?

tornado *ist* ein server, das ist sein hauptsaechlicher Daseinszweck. WSGI anzubieten ist eher eine convenience.

Und nginx ist eben sowohl als auch. Es ist ein webserver fuer statische Inhalte, und bindet zB tornado-apps (oder rails oder oder oder) via proxying ein, und damit kann er dann auch gleichzeitig als loadbalancer fungieren.

Vielleicht sollte ich mich mal fuer euch als Consultant verdingen... wo bald so viel Last draufsteht, muss ja Geld hinter sein

Und nochmal zu dem WSGI: das ist per Definition synchron. Das heisst jetzt nicht per se, dass es weniger performant ist. Sondern einfach nur, dass es sich fuer bestimmte Techniken wie COMET/Long-Poll nicht eignet, weil es sehr resourcenintensiv ist, viele Verbindungen *offenzuhalten*. Wirklich mehr gleichzeitige User abgehandelt bekommt man auch mit tornado/Node.js & Co nicht. Nur effizienter Verbindungen verwaltet.

Es kommt also schlicht auf euer eigentliches Anwendungsszenario an. Wenn ihr eigentlich nur kleine Teile asynchron braucht, dann wuerde sich zB ein Dienstleister wie pusher anbieten, oder eine Mischapplikation aus WSGI und zB tornado, mit einer DB oder ZeroMQ oder aehnlichem als vermittelnder Schicht dazwischen. Denn asynchrone Programmierung ist nicht trivial, und vor allem wie du schon gemerkt hast kommen auch nicht alle DBs und so mit entsprechenden Schnittstellen daher.

deets hat geschrieben:tornado *ist* ein server, das ist sein hauptsaechlicher Daseinszweck. WSGI anzubieten ist eher eine convenience.

Und nginx ist eben sowohl als auch. Es ist ein webserver fuer statische Inhalte, und bindet zB tornado-apps (oder rails oder oder oder) via proxying ein, und damit kann er dann auch gleichzeitig als loadbalancer fungieren.

Vielleicht sollte ich mich mal fuer euch als Consultant verdingen... wo bald so viel Last draufsteht, muss ja Geld hinter sein

Wir sind einfach nur zwei Informatik Studenten die sich wie Webdevelopment interessieren. Wir wollen ein streaming Projekt auf die beine stellen. Uns ist dabei völlig Bewusst das es nicht einfach und wahrscheinlich auch nicht erfolgreich wird.

Trotzdem möchten wir nicht einfach ins kalte Wasser springen, sondern uns gründlch informieren. Ich suche momentan verzweifelt nach Informationen

Wir hatten mit Google App Engine angefangen, aber dann gemerkt das AWS besser für unser Projekt geignet ist.

Und nochmal zu dem WSGI: das ist per Definition synchron. Das heisst jetzt nicht per se, dass es weniger performant ist. Sondern einfach nur, dass es sich fuer bestimmte Techniken wie COMET/Long-Poll nicht eignet, weil es sehr resourcenintensiv ist, viele Verbindungen *offenzuhalten*. Wirklich mehr gleichzeitige User abgehandelt bekommt man auch mit tornado/Node.js & Co nicht. Nur effizienter Verbindungen verwaltet.

Es kommt also schlicht auf euer eigentliches Anwendungsszenario an. Wenn ihr eigentlich nur kleine Teile asynchron braucht, dann wuerde sich zB ein Dienstleister wie pusher anbieten, oder eine Mischapplikation aus WSGI und zB tornado, mit einer DB oder ZeroMQ oder aehnlichem als vermittelnder Schicht dazwischen. Denn asynchrone Programmierung ist nicht trivial, und vor allem wie du schon gemerkt hast kommen auch nicht alle DBs und so mit entsprechenden Schnittstellen daher.

Achso okay danke, das habe ich mir nämlich schon gedacht. Eigentlich brauchen wir für unser Project kein async. Ich denke das ist dann für Anwedungen wie Facebook mit realtime updates eher geignet. (was wir nicht haben)


Ich denke wir werden dann einfach bei unserem momentanen Framework "webapp2" bleiben.

Was heisst genau "streaming projekt"? Das koennte dann naemlich schon interessant sein fuer async. Denn damit bist du effizienter, wenn du zB ein neues Datenpaket mit einem Frame oder was auch immer an eine ganze Reihe von Clients verteilst.

deets hat geschrieben:Was heisst genau "streaming projekt"? Das koennte dann naemlich schon interessant sein fuer async. Denn damit bist du effizienter, wenn du zB ein neues Datenpaket mit einem Frame oder was auch immer an eine ganze Reihe von Clients verteilst.

Man könnte es grob mit putlocker.com vergleichen. Also ein "Filehoster"für Videos. Wenn ich async richtig verstanden habe dürfte es uns eigentlich garkeinen Vorteil bringen.

Edit:
ups..
Klar wenn mehrere User auf ein File zugreifen sollte das doch einen enormen Vorteil aufweisen.

Naja, dazu reicht dann wenn die dateien statisch sind ein NGINX. Wenn ihr die natuerlich irgendwo herholt zB aus ner DB, dann sollte man da schon asynchron arbeiten.

deets hat geschrieben:Naja, dazu reicht dann wenn die dateien statisch sind ein NGINX. Wenn ihr die natuerlich irgendwo herholt zB aus ner DB, dann sollte man da schon asynchron arbeiten.

Die Daten werden wohl statisch auf amazon s3 untergebracht.

Vielen dank
Ich werde mich mal in nginx einlesen.

kantaki hat geschrieben:Wir hatten mit Google App Engine angefangen, aber dann gemerkt das AWS besser für unser Projekt geignet ist.

Google App Engine kenne ich noch nicht. Allerdings habe ich auch mal AWS aufprobiert. Ich fand es allerdings sehr in-transparent was die Abrechnung anbelangt. Man weiß nicht wirklich was man zahlen muß.

Wenn die auf S3 liegen *und* davon ausgeliefert werden, dann habt ihr da ja eh nix mit am Hut, wie die ihre Verbindungen handhaben. Dann kannst du Framework-technisch nach Geschmack vorgehen.

deets hat geschrieben:Wenn die auf S3 liegen *und* davon ausgeliefert werden, dann habt ihr da ja eh nix mit am Hut, wie die ihre Verbindungen handhaben. Dann kannst du Framework-technisch nach Geschmack vorgehen.

Mal aus reiner Neugier. Welches Framework gefällt dir am 'besten'?

TurboGears 1 und 2 habe ich gerne mit gerabeitet. Die Verwendung von SQLAlchemy, das starke Bekenntnis zu WSGI, ToscaWidgets. Empfehlen kann man die aufgrund der schwindenden Community leider nicht mehr so recht. Und der "best-of-breed"-Ansatz hat so seine Tuecken, weil zB Projekte unmaintained sind usw.

Und mit AppEngine zB geht's nicht, wegen den vielen EGGs.


Django habe ich nicht viel mit gemacht, aber das was ich gesehen habe hat mir persoenlich weniger gut gefallen als TG. Es ist aber ganz bestimmt gut genug fuer alles im Web-Bereich (async mal aussen vor, das kann auch TG nicht, weil WSGI). Die Community mitsamt allem was dazugehoert (Doku, stabile Releases, Migrationen) ist das beste im Python-Bereich.

Pyramid ist ja quasi TG3, aber da auch da wieder dieselben Leute hinterstecken, die immer nach dem neuesten & tollsten schielen, statt Dinge zu pflegen, und auch den best-of-breed Ansatz verfolgen bin ich da skeptisch. Es soll besser dokumentiert sein. Vielleicht wirds ja diesmal was.

Und von den Micros hab' ich mir bottle & tornado angeschaut. Mag ich beide, aber ich pimpe dann zB bottle sofort mit ToscaWidgets, weil ich einfach so arbeiten mag, inklusiver der Validierung und re-populierung von Formularen. Da braucht man dann aber schon intime Kenntnisse - die ich als ehemaliger Committer natuerlich habe

Ich wuerde jedem, der nicht wirklich viel Ahnung von Webentwicklung hat oder 100000% weiss, dass ein Microframework ausreicht, daher zu Django raten.

Wir werden wahrscheinlich dynamoDB von amazon benutzen. (noSQL) Da fallen dann zb viele Frameworks raus zB Django.
Ich habe auch noch kein Framework gesehen das dynamoDB unterstützt, scheint recht neu zu sein. Wahrscheinlich weils ein amazon only Produkt ist.

Deswegen werden wir wahrscheinlich nur die very basics nutzen wie post, get, redirect etc.
Wir werden wahrscheinlich bei webapp2 bleiben.

Da wir ngnix nur für static verwenden würden, werden wir wohl besser amazon s3 verwenden (css,js und sontige static files).

Für nicht eingeloggte User werden wir die static seiten wahrscheinlich pre-computen. Jetzt ist nur die Frage sollten wir diese static sites auch in S3 speichern, oder in memcached ? Ich weiß nicht wie schnell man auf S3 zugreifen kann. Verändern dürften sich diese Files nicht all zu oft.