Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: "Sven R. Kunze" <srkunze@mail.de>
Newsgroups: de.comp.lang.python
Subject: Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
Date: Fri, 19 Jan 2018 17:33:53 +0100
Lines: 108
Message-ID: <mailman.154.1516379626.2620.python-de@python.org>
References: <29ce1adc-0fea-e23c-e321-858e0d52dc1c@thomas-guettler.de> <a1669a00-b66c-6cce-8546-570a857e77aa@behnel.de> <71ab86cc-0e21-da2f-9577-8b6ccbe707ba@thomas-guettler.de> <2915505E-9237-40C4-A2BF-A4A22D00A216@web.de> <04ab7b73-e182-081c-74c7-976e3eac9b84@mail.de> <d1a40b67-1a37-7164-f980-85d473a0838e@behnel.de> <9ce770aa-b6dd-f709-1a95-f1e02f82f7f6@mail.de> <bc8618a5-2ffc-46eb-72a4-afa12ddc030d@behnel.de> <374d8f30-d5ec-a097-6bd0-ce15fc0d824e@mail.de> <e908fbb0-e390-5726-1714-f620f0aaac20@procoders.net> <ea6caf42-1b06-0d03-d811-2c5f7b3f954e@mail.de> <2b456907-a4e0-7b14-4948-8b1a28fd9710@procoders.net> <f69370fe-3134-13a3-d2b0-baf63e832e77@mail.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
In-Reply-To: <2b456907-a4e0-7b14-4948-8b1a28fd9710@procoders.net>
Content-Language: de-DE
Precedence: list
Xref: csiph.com de.comp.lang.python:5099

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