Py4Web

[kbr]

Ich hatte jetzt einen Fall, bei dem async sinnvoll war, ebenso das in django bereits integrierte ORM. Django 3.1 macht da schon einen recht brauchbaren Eindruck.

[naheliegend]

Ich hatte jetzt einen Fall, bei dem async sinnvoll war, ebenso das in django bereits integrierte ORM. Django 3.1 macht da schon einen recht brauchbaren Eindruck.

Was war das für ein Anwendungsfall (,wenn man fragen darf)?

[DasIch]

In dem Zusammenhang ein Klassiker: You Are Not Google.

Ein Punkt der hier nicht explizit genannt wird aber wichtig ist: Man greift natürlich bei Google und anderen Organisationen bei neuen Problemen auch ganz pragmatisch zu Lösungen die man schon hat. Nur weil man ein kleineres Problem hat und dieses Werkzeug was man schon hat da etwas überdimensioniert ist erfindet ja niemand das Rad neu (wobei dass natürlich auch vorkommt). Ganz praktisch und pragmatisch schiesst man so halt ab und zu mit Kanonen auf Spatzen.

Du braucht eine Queue für ein paar Events pro Tag? Könntest du jetzt auch einfach in postgres umsetzen. Wenn du aber da schon den Kafka Cluster hast, vielleicht sogar mit tollem Monitoring und praktischerweise kümmert sich ein anderes Team um die Administration, tja dann greift man auch schonmal zu Kafka.

Es ist also völlig egal um welches Problem es geht, selbst bei kleineren Problemen die man vielleicht auch hat, würde ich Lösungen von größeren Organisationen mit ganz viel Vorsicht genießen.

[kbr]

Was war das für ein Anwendungsfall (,wenn man fragen darf)?

Zur Bearbeitung eines Requests wird u.a. eine externe API aufgerufen, die ihre eigene Latenz hat. Es ist natürlich eine Designentscheidung, ob man in einem separaten Thread wartet oder async verwendet.

[noisefloor]

Hallo,

Warum ist Node und Go besser als Python?
[/quote]

"Besser" ist relativ - es kommt drauf an, was du brauchst Neben der bereits genannten Ausführungsgeschwindigkeit hat Go eine einfach zu nutzende Nebenläufigkeit in Form von Goroutines eingebaut. Was halt praktisch ist, wenn man Webanwendungen hat, die viele Requests in kurzer Zeit bearbeiten müssen.

Gruß, noisefloor

[DasIch]

Async ist übrigens auch so eine "You are not Google" Sache. Macht nur Sinn wenn man viel IO macht, während man einen Request verarbeitet. Das tut man in großen Unternehmen sehr häufig, wenn man da Microservices nutzt. Da macht man schonmal einen request für authentication zum authentication service, einen zweiten für authorization zum authorization service und schon ist man bei zwei Requests minimum pro eingehendem Request.

Wenn man aber eine einfache Webanwendung hat die auf eine Datenbank und vielleicht auch noch auf Redis zugreift macht async keinen Sinn, im Gegenteil dürfte der Latenz eher schaden.

[__deets__]

Ich sehe noch einen anderen Vorteil von async: Nebenlaeufigkeit. Viele Leute die zB GPIOs steuern wollen, mit anderen dauerhaft offenen Dateien hantieren, oder Timer-basiert arbeiten, koennen das damit oft ohne auf Threading zurueckgreifen zu muessen.

[Sirius3]

@DasIch: async macht bei Datenbankzugriffen und Redis genauso Sinn, dann das ist ja genauso IO.

[DasIch]

Die Anzahl der Queries die man effizient parallel ausführen kann ist überraschend gering. Das erreicht man auch ohne async problemlos. Wenn du also viele Requests bekommst hängst du dann einfach an deinem Connection Pool. Wenn backpressure nicht richtig implementiert ist (was du ja bei sync io implizit und ohne aufwand hast) akzeptierst du aber weiter Requests und der Server fliegt dir um die Ohren.

Zur backpressure Problematik gibt es auch einen Artikel von Armin Ronacher aka mitsuhiko, der noch mehr ins Detail geht.