[Python-de] select.epoll() vs async framework (PostgreSQL)
Sven R. Kunze
srkunze at mail.de
Fr Jan 19 11:33:53 EST 2018
On 18.01.2018 23:50, Achim Domma wrote:
>> - *was wäre eigentlich die Zielsetzung?*
> Gute Frage, die man natürlich vorher klären sollte. Die Zielsetzung
> könnte aber z.B. sein, 100k Websocketconnections mit möglichst wenig
> Resourcen bedienen zu wollen.
Das wäre doch mal ein sinnvoller Ansatz, und darauf wollte ich hinaus.
WSGI und asyncio sind für mich nur Werkzeug und da bin ich vollkommen
emotionslos und bewerte nach objektiven Kriterien.
>> - wie stellt man sicher, dass nicht 1 fehlerhaft implementierter View
>> (das ist das Ding, was für einen Request eine Response erarbeitet), alle
>> anderen 100 Anfragen blockiert - await vergessen, oder so?
> Wie stellt man sicher, daß Software keine Bugs hat? ;-) Ja, das kann
> passieren, zeigt sich meiner Erfahrung nach aber ziemlich schnell.
Eher ungünstig, wenn eine kleine neue unbedeutende Seite in den Untiefen
einer komplexen Web-Applikation plötzlich hunderttausendfach am Tag
genutzte Uraltseiten zerstört.
Es geht mir nicht um Bugfreiheit, sondern darum, dass der eine Benutzer
nicht mit den Folgen der Abbarbeitung eines Requests eines anderen
Benutzers sieht/merkt. Aus meiner Sicht lässt sich nur so ein halbwegs
vernünftiges produktiv eingesetztes Produkt erweitern/pflegen ohne, dass
uns die Kunden pausenlos aufs Dachsteigen.
Man könnte auch sagen, sie sind daran gewöhnt, dass es bei neuen Sachen
noch im Getriebe knirscht, aber der Rest stabil weiterläuft.
>> Die Nachteile kooperativen Multitaskings bleiben bestehen, auch wenn
>> diese totgeschwiegen werden. ;-)
> Keine Ahnung, ob die totgeschwiegen werden. Ich bleibe da bei meinem
> bodenständigen "man sollte wissen, was man tut".
Was prinzipiell dasselbe ist. ;-)
Aber ich lass das mal so stehen.
> Vermutlich wird niemand
> eine GUI basierend auf asyncio entwickeln wollen.
Kannst du erläutern, wieso nicht?
> Massiv paralleles IO
> für Batchprozesse ist jetzt in der Regel nicht soooo komplex und ich
> bezweifle, daß es eine ähnlich einfache Lösung gibt, die gleiche
> Performance auf Multicoremaschinen zu erreichen.
Ich kann dir hier nicht ganz folgen.
>> Aber die meisten Web-Anwendungen, die Geschäftslogiken abbilden, sind
>> dann doch eher ziemlich kompliziert/komplex und müssen ständig erweitert
>> werden, wo ich mir gut vorstellen kann, dass man sich mit kooperativen
>> Multitasking ziemlich sicher ins Knie schießt; auch je größer das Team
>> wird. Da fehlen mir die Sicherungsmaßnahmen, die man bei einem separaten
>> Prozess einfach hat.
> Natürlich. Aber warum sollte ich für sowas asyncio verwenden wollen?
Vielleicht verstehe ich dich hier falsch, aber wenn es eine Anwendung
gibt, die mit asyncio geschrieben wurde, dann ist die Entscheidung
(möglicherweise basierend auf der 100K Anforderung) bereits durch.
Dennoch wirft man doch nicht einfach alle möglichen
Engineering-Maßnahmen/Richtlinien aus dem Fenster, nur weil man sich für
Tool A und nicht für Tool B entschieden hat.
Wie sehe die Lösung also aus? Mir fehlt da bisschen der Ansatz außer
vielleicht am Ende doch wieder Prozesse zu verwenden, in denen dann eine
asyncio-Loop für 20K läuft.
> Aber bis dahin ist mein Verständnis, daß das, was du gerne hättest,
> ganz einfach nicht geht.
Schade. :-(
> Deswegen oben mein Verweis auf "power feature". Der durchschnittliche
> Entwickler wird nie einen Grund haben, asyncio zu verwenden. Viele
> werden es versuche, weil es möglich ist. Ähnlich wie bei meta classes.
> Daß ein Feature mißbraucht wird, macht es aber nicht per se schlecht.
Das kann ich nur so unterschreiben.
Daher auch mein Nachgefrage, ob und wann es denn sinnvoll ist asyncio
einzusetzen.
> Damit kann ich leben. ;-) Gerne höre ich mir auf der nächsten Europython
> deinen Vortrag darüber an, wie man's besser machen könnte. Das hätte
> quasi schon Tradition. :-)
Hehe, wenn ich's wüsste, würd ich hier nicht diskutieren. ;-)
Habe dort noch nie einen Vortrag gehalten.
> Hast
> du dir mal Lösungen in den anderen Web/Script-Sprachen angeschaut? Ruby,
> Php, ... Hast du da irgendwas gesehen, daß eleganter wäre, also das
> asyncio von Python?
Bei Ruby und PHP bin ich, ehrlich gesagt, komplett raus aus der Nummer
(aber aus anderen Gründen, die mit dem Sprachdesign und der Philosophie
zu tun haben).
Auch, wenn mich hier jetzt dafür wahrscheinlich einige steinigen, aber
ich persönlich finde die Events und Callbacks von JavaScript gar nicht
so schlecht. Und am Ende nimmt man halt wieder eine Bibliothek, die
einem das wegkapselt, was unangenehm ist, wie AngularJS.
Sven
Mehr Informationen über die Mailingliste python-de