Transcript: Python Async Teil 1 - am Beispiel von Django

Ja, hallo liebe Hörerinnen und Hörer, willkommen im Python-Podcast.

Heute ist die 23. Episode, also für uns wieder eine ganz besondere Zahl.

Was machen wir heute? Heute machen wir wieder Async und Multiswelling und sowas.

Und zwar Django Async kommt bald raus und darüber haben wir eine eigene Folge aufgenommen.

Und zwar in dem schönen Wintergarten von Jochen. Ich bin der Dominik.

Und diesmal haben wir natürlich wieder einen Gast. Den kennt ihr vielleicht schon.

Hallo Johannes.

Hallo Dominik. Hallo Jochen.

Und hallo Jochen.

Hallo, genau, auch wieder dabei.

Ja, falls euch irgendwas gefällt oder nicht gefällt,

dann schreibt uns doch wie immer gerne eine E-Mail an

hallo-at-pison-podcast.de

Und wir möchten uns auch gerne noch für ein paar Abonnenten bedanken.

Und zwar haben wir allein auf Spotify

mittlerweile über 1111 Abonnenten.

Herzlichen Dank dafür und wuhuu!

Sehr cool, wir freuen uns, wir finden das toll.

Naja.

Reicht es noch nicht, du willst die Welt verschaffen.

Du guckst zu viele YouTube-Channels,

oder? Ich weiß nicht genau.

Ist das da so üblich?

Ich weiß nicht, ob das beim Podcast auch so üblich ist.

Ach, was denn? Ich habe mich einfach gefreut.

Ja, nee, ist schon toll, aber keine Ahnung.

Ja, und wo wir gerade schon bei so anderen Sachen sind.

Also ihr habt ja vielleicht den Thomas gehört,

der mit uns eine schöne Folge gemacht hat.

Und der hat jetzt seinen Podcast umbenannt.

Also wir hatten ihn das letzte Mal zu wenig erwähnt.

Deswegen müssen wir es auch einmal extra erwähnen.

Der ist ein ziemlich cooler Podcast, den er da hat.

Wie heißt der jetzt, Jochen?

Dads and Stats.

Und er hat Kevin Sisson dabei in einem letzten Talk

und redet über Pi MC3.

Ich glaube, ist sehr hörenswert, die Co-Founder von Pi MC3.

Ja, ich hab's gestern schon gehört, fand's sehr gut.

Also, ja.

Ja, vielen Dank, Thomas, für die nächste tolle Episode.

Ja, und hätte ich jetzt

gar nicht gedacht, ich meine, dass Instagram Python macht,

aber dass sich halt deren Gründer und Ex-CEO

irgendwie so viel mit

Statistik und Machine Learning-Kram so beschäftigt

ist und Data Science. Oder, naja, gut,

das hat er ja vorher nicht so gemacht, aber das macht er jetzt halt,

das fand ich schon sehr interessant und

ja, war auf jeden Fall eine interessante Geschichte.

Ja, hört doch da mal rein, wenn ihr möchtet.

Ja, wir machen heute wieder

Django, vor allen Dingen halt, weil Django 3.1

jetzt im August erscheint und

tatsächlich jetzt mehr Async-Features

unterstützt als in der 3.0-Version, die

seit Dezember draußen ist. Und wir

möchten ein bisschen mit euch darüber reden oder

untereinander darüber reden, was das überhaupt

heißt, was das alles so ist.

Was ist überhaupt dieses Multisprengen? Wir hatten das

in irgendeiner Episode schon mal so ein bisschen angerissen,

vielleicht auch so ein bisschen kurz gesprochen, aber

uns sind noch so ein paar andere Erkenntnisse gekommen und

darüber wollten wir halt so sprechen. Warum

macht man so ein Shred und warum

macht man so ein Multiprocess? Und warum macht man

das dann irgendwie Async? Und warum macht man das mit Async.io?

Und was gibt es dann noch für Alternativen?

Wann braucht man das überhaupt? Und warum?

Und warum vielleicht auch überhaupt nicht?

Irgendwie so.

Ja, wollten wir vielleicht erst noch so ein bisschen News machen?

Oh, News, ja. Du hast natürlich

recht. Neuigkeiten aus der Szene.

Ja, wobei

so wahnsinnig viel gab es nicht. Ich habe mir noch ein paar

Dinge aufgeschrieben. Ich weiß nicht,

ob du das verwendest. Insofern kannst du vielleicht

Pylance. Ach ja.

Ja, sehr gut. Ja, also Pylance

ist ein neues Plugin, was für VS Code rausgekommen ist.

Also ein neuer Language-Server, wenn ich das

richtig verstehe, der eine ziemlich coole Sache macht.

Also mit der Auto-Import-Sätze in VS Code und so

und fast alle Features, die man sonst

so auf PyCharm eher hatte. Und also

ich mag ihn sehr gerne. Hast du ihn auch schon aktiv im Einsatz?

Ich habe das auch schon aktiviert

und finde es auch ziemlich gut. Also

ich mache jetzt gar nicht so viel mit

Type-Annotationen, aber die Verlockung

wird stärker. Ja. Und

das Ding kann da irgendwie einiges rausholen,

ja. Finde ich auch. Tja, Johannes,

da bist du raus, wenn du uns PyCharm, ne?

Ja, tut mir leid, ich habe die Features alle schon.

Ich meine, ich benutze ja auch PyCharm.

Also insofern, ich finde das auch gar nicht schlecht.

Du wurdest dazu gezwungen, habe ich gehört, Jochen.

Naja, mehr oder weniger.

Ich meine, ich finde es ja auch interessant.

Also ab und zu mal andere Dinge verwenden, ist vielleicht gar nicht so schwierig.

Bei uns nutzen wir alle VS Code.

Achso, wer übrigens auch VS Code natürlich nutzt,

ist Daniel Feldtroy, falls ihn kennt,

der Autor von Two Schools of Django,

der ja bald das 3X-Version-Buch rausnimmt.

Und ich war letztens bei ihm ein, zwei Mal in seinem Twitch-Stream,

weil er irgendwie streamt, irgendwie twitcht und er

hat mir versprochen, dass er in Düsseldorf zum Essen

vorbeikommt. Bin natürlich ganz gespannt, ob das

irgendwie nicht nur blöd ist.

Ja, das kann man leicht

versprechen, ne? Solange keine Flugzeuge fliegen und so,

ist das immer irgendwie relativ...

Also ich glaube, ein zweites Mal, als ich da war, hat er gedacht,

oh, warst du nicht der aus Istanbul? Ich so, nee,

das war aus Düsseldorf, aber...

Ja, relativ gesehen...

Ach, Düsseldorf, Istanbul. Kann man sich dann da

Bücher signieren lassen? Ja, also wenn die

Altersdiener auf jeden Fall, ja, das hat er ja auch gesagt,

vielleicht verlieh ich dann sogar dahin und dann

Quatsch mir ein bisschen. Nein, fand ich super.

Wollte ich nur mal kurz erwähnt haben.

Ja, aber es stimmt. Ich gucke in letzter

Zeit auch gerade in

Vorbereitung auf diese Episode, habe ich relativ

viel YouTube-Channels und so geguckt.

Und da verwenden doch sehr viele

VS Code. Du hast dich

vorbereitet? Ja, ausnahmsweise mache

ich ja sonst eigentlich nicht. Es bestehen noch Zeichen und Wunder.

Ja, ich fand es auch sehr unangenehm, ehrlich

gesagt. Ich weiß nicht, ob ich das nochmal machen möchte.

Aber gerade

zum Beispiel, da gab es

eine Serie

von Lukas Langer, der hat

auch VS Code verwendet.

Zu Async.io und so.

Auch sehr empfehlenswert, kommt auch noch

in die Show-Nutzung. Ja, ansonsten

war, glaube ich, irgendwie für 3.7

ist die letzte

Bugfix-Release irgendwie

gerade erschienen. Für 3.6

noch irgendeine Security-

Geschichte, Python, und

das war es dann so ziemlich irgendwie mit

Ja, dann bald ist 3.9 durch, ne?

Ja, bald kommt dann 3.9, genau.

Was ist denn das Tolle an 3.9?

Jetzt hast du jetzt mal gefragt.

Auf dem falschen Fuß erwischt.

Also ich meine, das Tolle an 3.8

ist ja der Walrus-Operator und den wir

auch alle ständig immer benutzen.

Ich wüsste nicht, was in 3.9 neues drin ist.

Doch, also ich habe gehört,

dass zum Beispiel diese

Subinterpreter-Geschichte da

irgendwie mit drin sein soll.

Also das war fraglich eine Zeit

lang und dann gab es... Bitte erkläre

uns dann, was ist ein Subinterpreter?

Ja, das ist im Grunde auch so eine

so eine Methode, um dann halt eventuell,

also, ähm, ja,

um halt den Gil so ein bisschen

loszuwerden oder halt das so ein bisschen...

Gil ist der Global Interpreter-Log, ja?

Ja, da werden wir sicherlich gleich noch ganz viel drüber sprechen.

Genau, die Konsequenzen so ein bisschen zu

mitigieren und das

sollte, ich weiß es nicht,

vielleicht auch so hinterher zählen, ich habe keine Ahnung.

Also, ich habe gehört, Python 3.9 unterstützt einen neuen

Parser und der macht ganz viel anders und deswegen

kann man jetzt auf einmal ganz viele andere Code-Analysen

oder irgendwas benutzen. Ja.

Aber...

Ja, diese Pack-Parser-Geschichte, ja.

Ja, weiß ich aber auch nicht so viel zu.

Also für den normalen Programmierer erstmal keine Unterschiede.

Ja, nicht so richtig viel.

Also muss man sich mal mit beschäftigen.

Vielleicht gibt es auch irgendwelche total coolen Sachen.

Na gut.

Ansonsten Django, genau, war auch 2.2.14 und 3.0.8 sind irgendwie vor kurzem raus.

Ja.

Ja, also Django ist jetzt hart an der Entwicklung zu 3.1.

Und das ist ja das, worüber wir heute reden wollen,

weil es halt tatsächlich diese Async-Features jetzt gibt.

Oder hast du noch mehr News aus der Szene?

Ja, ich habe welche aus dem Hintergrat,

beziehungsweise aus meinem persönlichen Setup.

Oh.

Und zwar, genau, ich weiß nicht, ob man es hören kann,

aber jetzt ist hier, wir haben irgendwie eine große Bohrmaschine genommen

und dann irgendwie hier mal die Außenmauer durchlöchert

und jetzt ist hier tatsächlich kabelbasiertes Netz.

Oh.

Und es könnte sein, dass es jetzt deutlich weniger knackst als vorher.

Also du meinst, weil es weniger

Wi-Fi gibt und jetzt mehr konstantes

Laden. Jetzt gibt es halt richtig ordentliches

Stimmt, ich sehe sogar da hinten das Kabel,

das durch die Wand in den Raum geht.

Genau. Und

eine zweite Geschichte, die auch

neu ist und die ich eigentlich ganz

cool finde, weil ich nicht wusste,

also ich habe das Ding einfach mal so auf Verdacht

gekauft und wusste nicht, ob es geht, aber es ging tatsächlich,

war, ich habe mir so eine

Kaldigit Docking Station

besorgt. Eine was?

Kaldigit. Ja, ja, ja.

Das Ding versorgt gleichzeitig einen Rechner mit Strom, macht irgendwie Thunderbolt und du kannst Monitore dran anschließen.

Und was ich halt da drin habe, also ich habe sozusagen nur noch ein Kabel, das ich halt immer an den Rechner stecke.

Weil ich hatte nämlich jetzt, da ich jetzt Netzwerkkabel habe, das Problem, okay, wie mache ich denn das Netzwerkkabel an meinem Rechner fest?

Der hat ja nur USB-C.

Da so irgendwie so ein Dongle dran zu hängen, der dann so rumbaumelt, ist auch irgendwie etwas unschön.

Zusätzlich zu den ganzen anderen Adaptern und Dongle, die da sowieso schon rumbaumeln.

Ähm, äh, und, ähm, das geht damit halt ganz gut, weil da steckt man einfach Ethernet hinten rein plus irgendwie das, was zum Monitor geht und, äh, hat halt nur ein einziges Kabel, was zum Laptop geht und alles andere, äh, geht dann über die Dockingstation und was tatsächlich funktioniert ist, man hat halt, ich hab da hinten halt dann noch Storage dran und das ist schnell, äh, und, also so eine externe SSD und das ist ordentlich schnell, der Monitor ist so ein, so ein, so ein ultrafein, äh, LG 5K und da dachte ich auch so, uh, ob das funktioniert, aber es funktioniert tatsächlich.

Und es kommt auch noch Strom durch.

Also ich suche auch so etwas Ähnliches.

Ich möchte gerne meine Monitore umschalten

mit so einem Switch.

Und zwar einmal auf eine Workstation

und einmal auf meinen normalen Rechner.

So eine KVM-Switch?

Ja, genau, eine KVM-Switch.

Und ich habe mich dann gefragt,

ob es da was Vernünftiges für gibt.

Weil ich hätte gerne auch die Auflösung der Monitore

und mit Switch immer hin und her geschaltet

zwischen allen Setups.

Das finde ich cool.

Aber ich habe noch keine Ahnung, was es da gibt.

Falls ihr da irgendjemanden kennt

oder einen guten Tipp habt,

her damit, ich freue mich drüber.

Das schaffe ich mir an und probiere das mal aus.

Ansonsten

habe ich nichts mehr. Johannes, hast du eine News?

Eine Neuigkeit? Nee, ich bin immer noch im WLAN.

Ich habe kein Kabel.

Du bist tatsächlich im WLAN bei dir im Haus?

Ja, das geht ja nicht anders.

Das ist zu weit weg.

Rohrmaschine? Ja, nicht in einem

Miethaus.

Und ich habe schon lange

so ein relativ altes

Lenovo-Dock. Das gehört auch

gar nicht zu meinem Rechner, sondern das habe ich einfach mal irgendwo

gekriegt für, keine Ahnung, 50 Euro oder so.

Ein Dock ist total gut.

Da ist einfach alles eingesteckt. Tastatur eingesteckt,

Maus eingesteckt, Monitore eingesteckt,

Storage ist auch dran.

Das ist total gut. Und du sitzt diesmal auf einem

anderen Stuhl und auf einem anderen Schreibtisch,

vor einem anderen Schreibtisch in deinem Büro.

Naja, nee, ich habe ja zwei

Arbeitsplätze in meinem Büro.

Der andere Arbeitsplatz.

Der ist ja praktikant nicht zu Hause, na gut.

Es gibt den

mobilen Arbeitsplatz und den immobilen

Arbeitsplatz und das ist jetzt der fest installierte

mit den großen Monitoren.

Okay, okay.

Ja, cool.

Dann würde ich sagen, von mir aus

kann man jetzt tatsächlich das Thema

Ich bin absolut begeistert,

das ist eine Weltpremiere hier heute.

Liebe Hörerinnen und Hörer, hört zu,

ihr wisst genau, was euch jetzt erwartet.

Weltpremiere Dango Async 3.1.

Ja, also genau.

Ich habe direkt mal eine Frage.

Ja, was ist denn der Async?

Muss ich irgendwas beachten,

wenn ich jetzt von 3.0 auf 3.1 upgrade?

Muss ich dann irgendwas machen

oder geht es dann auch noch alles?

Das geht alles genauso wie vorher auch.

Wichtigste Frage direkt geklärt.

Okay, also erstmal nochmal so vielleicht ganz kurz

so zum Frame, zum Rahmen, worum es eigentlich geht.

Was Async dann überhaupt bedeutet

und was man jetzt damit machen kann,

was vorher schon so ging, so diese Geschichte

und wofür man das eigentlich braucht.

Also womit wollt ihr denn anfangen?

Vielleicht, was das ist, Async überhaupt?

Und ja, dann kommt man vielleicht darauf,

warum man das vielleicht haben wollen

möchte oder vielleicht auch gar nicht braucht.

Das ist gleich eine schwierige

Frage am Anfang.

Also ich glaube, ich würde tatsächlich mit der

Motivation starten, weil sonst

wird das direkt so trocken und alle Leute

schalten sofort auf Durchzug und

wenn man so zumindest

weiß, dass es irgendwie vielleicht nicht so

super unwichtig ist und dass tatsächlich

interessante Dinge damit gehen, dann

vielleicht hält man ein bisschen länger durch.

Also du weißt schon, dass da Eve Online steht und das ist

gleich sonst einen Exkurs von mir zu EVE Online.

Ja, genau, das wäre

interessant.

Aber die sind doch noch auf 2.7.

Die kriegen ja doch die ganzen Sachen gar nicht mit.

Ja, ja, aber es gibt

wahrscheinlich Gründe, warum das so ist.

Also okay, ich fange einfach mal so an.

Das ist der Grund.

EVE Online hat von Anfang an gesagt,

wir haben, keine Ahnung, 15 Millionen Codezeilen

in unserem Server, wir fangen jetzt nicht an, die auf Python 3.

Also genau, EVE Online

basiert viel auf Python, falls ihr das noch nicht gehört habt.

Ja, genau. Und soweit ich weiß, ich weiß nicht, ob das immer noch so ist, aber soweit ich das gehört habe, auch auf Stackless Python.

Oh ja, das ist interessant. Da umgehen Sie ja gleich viele von den Dingen, weshalb man Async überhaupt braucht.

Genau, also beziehungsweise zu der Zeit, wo Sie das gemacht haben, gab es das halt einfach noch nicht.

Und Stackless Python war halt eine Lösung für die Probleme, die sich da gegeben haben.

Und ich meine, gut, wir können auch einfach direkt so einsteigen, weil das ist ja auch eine gute Motivation, warum braucht man sowas überhaupt?

Und was die wohl können, also hieß es jedenfalls,

ist, dass da das alles in Stackless-Python

halt auch so Userland-Threads oder Green-Threads

oder wie auch immer man die nennt, sind.

Stackless-Python, du brauchst keinen Execution-Stack

dafür im Betriebssystem.

Was Stackless-Python kann, ist, du kannst diese Threads picklen.

Ja, vor allem kannst du mehr als einen ausführen, oder?

Ja, ja, ja, das auch.

Das hat auch keinen Global Interpreter-Log, das heißt, du kannst

einfach...

Jetzt gerade wieder die ganze Bagage

mit dem Grammisch-Collector in den Müll.

Moment! Stopp, stopp, stopp,

da sind wir doch noch nicht.

Also, ich wollte

eigentlich nur mal kurz, warum man das eigentlich machen will,

was das Coole daran ist.

Dadurch, dass diese Threads, also wenn ich jetzt zum Beispiel

halt ein Ding, ich habe keine Ahnung,

wie die EVE Online funktioniert, ja, ich kenne das nicht gar nicht,

aber ich glaube, es geht irgendwie um Raumschiffe und so,

die da irgendwie im Weltraum rumfliegen.

Excel in Space.

Gut, wem es Spaß macht, aber

naja.

Und du hast jetzt irgendwie einen Thread, der jetzt so ein Raumschiff

simuliert, das da so richtig gegenfliegt.

Dann kannst du halt das Ding

pickeln, in eine Datenbank schreiben,

irgendwo anders wieder

auspacken und weiter ausführen.

Ja, das ist eine sogenannte

Continuation, wäre mal

die akademische Fachliteratur.

Ah, okay, gut.

Und das ist natürlich, wenn man ein

Riesenuniversum hat, vielleicht eine ganz gute Sache,

wenn man das machen kann, weil eventuell

will man halt nicht alles immer laufen haben,

sondern möchte halt auch

Teile von dem Universum, das man simuliert,

da irgendwie auch einfach mal

einfrieren und in eine Datenbank

schreiben und erst dann wieder auftauen, wenn man es

tatsächlich benötigt, damit man nicht immer alles

gleichzeitig ausführen muss oder so.

Wäre eine gute Idee für Zeitreisen.

Aber wir wollten über die Motivationen

nochmal dann doch vielleicht kurz, lass das doch mal kurz

heute ausnahmsweise strukturierter angehen.

Und dann, wir gehen auch versprochen wieder zu

EVE Online zurück.

Ja, also genau, die Frage ist halt sozusagen,

ob nicht es valide Use Cases gibt für so sehr,

das deutsche Wort ist so ein bisschen doof,

aber ich weiß auch nicht, ob man da ein besseres finden kann,

nebenläufige, also massiv nebenläufige Programme.

Also man braucht halt viel Concurrency.

Also es gibt Probleme, da hat man halt einfach ganz viel Concurrency.

Und die Frage wäre halt, muss man, wenn man so ein Problem hat, damit umgehen zu können, die Sprache wechseln oder nicht?

Das ist sozusagen, also diese, ich würde sagen, das zentrale, ich habe mir ein paar Sachen angeguckt und das zentrale Ding, das hat auch Tom Christie quasi in einem Vortrag auf der DjangoCon 2019, als er irgendwie einen, den er da gehalten hat, so gesagt.

Also es gibt da diverse Geschichten in Go,

es gibt diverse Geschichten in Node.js oder Rust

oder Erlang, Erlang ist auch ziemlich en vogue gerade

und die Frage wäre halt, wenn man jetzt so einen Use Case hat,

bedeutet das, dass man die Programmiersprache wechseln muss

und dann halt Erlang machen muss

oder halt kann man das auch in Python machen?

Eigentlich kann man das auch in Python machen,

ist jetzt sozusagen dafür die Infrastruktur

noch nicht so ausgeprägt wie in anderen Sprachen,

aber so prinzipiell geht das schon

und man könnte jetzt sagen, na gut,

das hat ein bisschen lange gedauert, also die Geschichte von

Async in Python ist wahnsinnig lang,

aber in letzter Zeit wird es halt

sehr interessant. Zum Beispiel, wenn man jetzt Django als Beispiel

nimmt, dann geht das jetzt gerade erst so

richtig. Und der Grund dafür ist,

dass eigentlich will man

die Syntax dafür haben, also

für Kuroutinen,

und die ist erst seit 3.5 so richtig in der

Sprache. Das heißt, vor 3.5 ist sowieso

schwierig. Und

Django hat mit Version

1.11 noch Python 2 supported.

Dann geht es auch nicht.

Das kann man einfach vergessen.

Und mit Django, glaube ich, 2.1, 2.2 weiß ich gar nicht mehr,

aber noch Python 3.4.

Und mit 3.4 geht es auch nicht.

Das heißt, bis vor kurzem konnte Django das gar nicht

mit der nativen Syntax machen,

weil Python-Versionen supportet wurden,

bei denen das einfach nicht geht.

Und jetzt ist es halt sozusagen alt und abgehangen genug,

dass sozusagen nur noch Python-Versionen unterstützt werden,

mit denen man das dann tatsächlich nativ machen kann.

Und jetzt kann man halt anfangen, das umzustellen.

Beziehungsweise die Arbeiten daran sind ja jetzt auch schon was älter,

aber jetzt ist es halt so weit, dass es tatsächlich mal in einer

verwendbaren, für User verwendbaren Form halt tatsächlich in Django ankommt.

Und wenn man sich sowas überlegt,

also was ich zum Beispiel mir angeguckt habe,

Erlang ist ja relativ irgendwo gerade,

beziehungsweise halt so ein Dialekt,

der oft dann so für Web-Entwicklungsgeschichten benutzt wird, Elixier.

Und da gibt es auch so ein Web-Framework Phoenix zum Beispiel,

Und da kann man auch mal sich angucken,

so Phoenix Elixier,

Live View, solche Sachen.

Und das sieht alles schon sehr beeindruckend aus

und ist auch sehr nett.

Und die Frage wäre halt, kann man sowas in Django

und Python auch machen? Und die Antwort ist eigentlich

ja. Eigentlich gibt es nichts, was einen davon prinzipiell

abhält.

Außer, dass es halt nicht, dass noch nicht so

unterstützt wird in den Frameworks und so. Aber

prinzipiell geht das schon.

Was macht das denn jetzt so schön?

Ja.

Ähm, keine Ahnung, habt ihr noch was oder wegen Motivation oder was? Ich überlege gerade, ob ich jetzt schon ausreichend motiviert habe.

Ja, da fehlt noch ein kleines bisschen vielleicht. Warum man das vielleicht macht, könnte man bei der Motivation direkt sagen, oder? Also was für Problemfälle gibt es denn, die man jetzt…

Ja, es gibt ja schon immer, also ich meine, es gibt ja schon immer Anstrengungen, Sachen zu parallelisieren und da gibt es auch schon ganz alte Sachen.

Nur damals war es halt, damals, ja, also vor zehn Jahren war es halt noch so, dass Computer zwei Cores hatten oder vier Cores und da ist es nicht so wild, wenn du nur einen benutzt.

Aber heutzutage ist es ja relativ leicht, gerade im Serverbereich, Sachen zu kriegen, die 64 oder 128 Cores haben oder noch mehr, wenn man das unbedingt haben möchte.

Oder wenn man auf Grafikkarten geht, kriegt man direkt

in die Tausenden von Cores.

Deshalb ist das, man darf da

nicht so viel Python verdammen, weil das

einfach vor zehn Jahren noch kein Problem war.

Ja, Moment, Moment, aber das ist jetzt, glaube ich,

ein anderes Problem, oder? Also, oder aus

meiner Perspektive ist es ein anderes.

Generell die Nebenläufigkeit,

die man da jetzt braucht.

Aber das braucht man, das haben die anderen auch nicht.

Das haben die anderen auch nicht. Also, das kriegst du auch

auf Node.js nicht hin.

Das mag sein, dass das mit Node.js nicht

nicht unbedingt hinkriegst, aber mit C

und Erlang und Rust und so weiter kriegst du die Sachen

schon hin. Und Go auch.

Ja, gut.

Die nutzen schon alle Cores aus.

Ja, aber da

weiß ich gar nicht, ob man das unbedingt braucht.

Da würde ich jetzt denken,

warum? Doch, also ich glaube,

für mich ist das schon eine Motivation,

mehr Cores ausnutzen zu können.

Geht zwar nicht mit

Async, das weiß ich, aber

ja.

Generell, der Trend geht dazu, mehr Sachen gleichzeitig zu machen, um es mal so auszudrücken. Und dafür braucht man halt irgendeine Syntax. Und klar, es gibt die ganzen Sachen, die man früher machen konnte. Da gibt es die coolen Message-Parsing-Interfaces und die coolen, was weiß ich, verteiltes Rechnen-Ansätze und dann gibt es Threads und Multiprocessing und so weiter.

Aber die

haben halt alle ihre Nachteile und die haben halt alle

ihre, sagen wir mal,

Schwierigkeiten.

Und gerade wenn man

anfängt mit Threads zu arbeiten in Python,

merkt man halt sehr schnell, dass das von der Geschwindigkeit her

überhaupt gar nichts bringt.

Also ist die Frage, was man

mit Schwierigkeiten meint, ja,

wenn es um

quasi wie schnell kann man

Dinge machen geht, dann

bringt einem das nichts, sondern

macht es einfach langsam.

Und auch, wie viele Sachen gleichzeitig kann ich machen.

Wir helfen einem

im Verhältnis in Python ja erstmal gar nichts.

Ja, wobei, da würde ich direkt

unterscheiden zwischen Sachen

parallel machen, das heißt,

und Sachen concurrent,

und daneben läufig, ja, weiß nicht, ob das eine gute Übersetzung

ist, könnte man nicht.

Die deutschen Worte sind da total blöd.

Weil parallel geht

halt in Python nicht, aber ich glaube auch nicht, dass

das das Problem ist.

Oder geht noch nicht.

Da gibt es verschiedene Workloads, glaube ich, die da

die du da bedenken musst.

Also Multi-Processing ist parallel?

Wenn du in Nampai bist, dann hast du ja schon Parallelität.

Mit Nampai kriegst du die Cores schon alle voll.

Ja, ja, klar, genau.

Insofern würde ich sagen,

das ist auch nicht so ein Problem.

Vielleicht muss man erst noch erklären,

was Parallelität und Nebenläufigkeit sind.

Ja, bitte, bitte.

Einmal kurz da einschränken.

Ja, aber ist jetzt Multi-Processing

nicht sowas wie parallel?

Ja, Multi-Processing ist parallel,

aber auch das kannst du nur machen,

wenn du wenig Kommunikation hast,

weil du da eben zwischen Prozessen kommunizieren musst

und das ist langsam.

Das ist generell die Krankheit, die du hast,

wenn du solche Message-Parsing-Sachen machst.

Das hatten wir ja früher auch schon gehabt.

Als ich studiert habe, hatten wir einen großen Cluster,

der hatte 16 Prozessoren an der Universität.

Und das waren halt unterschiedlich, es waren halt 16 Computer,

die mit einem schnellen Netzwerk verbunden waren.

Aber je weniger Nachrichten du schicken konntest,

schicken musstest, umso schneller war das dann halt.

Das heißt, im Wesentlichen warst du da gar nicht

die CPU gedrosselt,

sondern eben durchs Netzwerk.

Ja, ja, gut.

So ein bisschen ist es bei Multiprocessing ja auch.

Je weniger Nachrichten du schicken musst, umso

besser. Aber da musst du überhaupt gar keine schicken.

Irgendwie, dass man sagt, man hat so

eine gemeinsame Verwaltung. Genau, es gibt Chat-Memory.

Kannst du einfach wenden. Musst du gar keine Nachrichten schicken.

Cool, sowas gibt es schon? Ja, ja. Das ist auch eingebaut.

Seit Python 3.8 ist das drin.

Also kannst du sagen, hier irgendwie, ja.

Umso besser.

Aber dann hast du trotzdem noch

irgendwelche Locking-Mechanismen, die dir da

wo wir halt warten mussten.

Aber wenn du CPU-Bauern bist, ist das alles nicht mehr schlimm.

Also das ist alles, also ich würde sagen,

wenn du Dinge einfach,

wenn du jetzt irgendwie Number-Crunch-Geschichten machst,

da alle Cores zu verwenden,

ist in Python überhaupt kein Problem.

Das geht super. Das ist tatsächlich einer

der beliebtesten Anwendungsfälle für Python.

Also ich würde sagen, Data Science,

da ist Python wahrscheinlich die Sprache Nummer 1 gerade.

Und das ist ja

hauptsächlich so ein Zeugs. Und da geht das super.

Da werden immer alle Cores benutzt, gar kein Problem.

Ja, klar. Im Wesentlichen ist der Trick halt daran, dass die aus Python rausgehen, die Bibliotheken, und dass die das halt in C machen.

Ja, oder du kannst halt auch so Dinge machen, nee, nee, nicht nur. Also du kannst auch pure Python-Funktionen parallelisieren.

Also mit REST geht das, auch mit mehreren Maschinen hinweg.

Ach so, ja, okay.

Aber das ist, also ich habe hier gerade die …

Also das ist jedenfalls Parallelität.

Ja, genau, das ist Parallelität.

Man macht Berechnungen auf mehreren Prozessoren und die sind gleichzeitig im Wesentlichen.

Und es spielt keine Rolle, ob es die gleiche Berechnung ist oder

eine andere Berechnung. In den meisten Fällen

werden es ja die gleichen Berechnungen sein.

Und wenn er zuerst fertig ist,

dann schreibe ich. Auf allen Zeilen dieser

Tabelle möchte ich jetzt ausgerechnet haben,

was die Summe ist. Genau, genau.

Also ich habe

hier die Definition von

Rob Pike, von dem

jenigen, der sich da

mal ausgedacht hat. Und der sagt halt

Concurrency is about dealing with

lots of things at once.

Parallelism is about doing lots of things

at once. Not the same, but

related. One is about structure,

one is about execution.

Concurrency provides a way to structure

a solution to solve a problem that may

but may not necessarily

be parallelizable.

Ja, das sagt er erst mal.

Ich dachte, das hätte ich gerade.

Nee, das

fand ich jetzt auch nicht arg erhellend.

Verdammt, na gut.

Ja, Parallelität ist halt

Sachen gleichzeitig machen

und Concurrency ist verschiedene Sachen

machen. Das ist so, wie es in meinem

Kopf ist. Ja, eine Erklärung, die ich mal gehört

habe, vielleicht ist die besser,

vielleicht einfach mal ein paar durchprobieren,

ist, dass halt sozusagen

ein Bartender

kann irgendwie viele Kunden

concurrent

behandeln, sozusagen, oder wenn ein Bartender

viele Kunden hat,

die er mit

Drinks beschickt, dann

ist das irgendwie Concurrency, aber

wenn du mehrere Drinks gleichzeitig machen willst, brauchst du mehrere

Bartender. Da reicht einer nicht.

Und das wäre dann Parallelität, sozusagen.

Ja, also mehr

Arme für den Barkeeper.

In meinem Kopf

geht es

bei mir ganz viel um das Wort gleichzeitig.

Parallelität heißt

du machst mehrere Sachen gleichzeitig.

Und

Nebenläufigkeit oder Concurrency heißt,

du machst mehrere Sachen

nebeneinander her. Also nicht an einem

abschließenden Schritt erstmal den einen Drink mixen,

sondern fünf Gläser hinstellen und jedes Mal

einmal ein bisschen Zitrone rein und dann ein bisschen

Drink. Genau, genau. Also du hast

fünf Drinks, die du zubereiten musst und du machst

halt die Schritte von denen und du machst erstmal was

an dem Drink eins, dann machst du was an dem Drink zwei,

dann machst du was an dem Drink drei.

Die Gesamtzeit ist

dann ja genau dieselbe, als würdest du fünf einzeln

machen, nur du hast halt dann fünf

gleichzeitig rausgeschickt und alle haben quasi

die Zeit gewartet, anstatt dass du jeweils erstmal

den ersten, den zweiten, den dritten, den vierten, den fünften

Genau, also du machst eventuell die

Latenz geringer. Du kannst

schon mal die Bestellung des Nächsten

annehmen, während ein Drink noch

in Bearbeitung ist. Ja, aber dann doch nur die Durchführung.

Ja, du kannst halt den Nächsten bearbeiten, während einer noch, weiß ich nicht,

in einem irgendeine fürchterliche chemische

Reaktion läuft, die halt eine Zeit lang braucht

und du wartest halt jetzt nicht stumpf davor ab.

Oder du wartest auf den Assistenten.

Ja, aber der Erste, der sonst

seinen Drink sofort bekommen hätte, weil es erst in der Schlange stand,

der muss jetzt länger warten, weil er die anderen Drinks

auch nicht hat. Potenziell ja.

Aber guck mal, wenn da gerade kein Eis da ist,

dann kannst du ja einen anderen Drink

machen, während du aufs Eis wartest oder während dir

jemand was aus dem Lager holt.

Das merkt der erste Kunde überhaupt

gar nicht, weil der muss so oder so drauf warten,

bis sein Eis da ist.

Ja, aber nur dann kannst du was anderes machen.

Mit deinen Tasks.

Ja, genau, wenn du Wartezeiten hast.

Und dann bemerkt der erste

Kunde gar nichts. Dann hast du automatisch

weniger Latenz und

mehr Durchsatz, weil du Wartezeiten

nutzen kannst. Und das ist ja eine der großen

Allüren dieser

ganzen Geschichte, dass du sagst, okay, ich muss jetzt

eh auf eine Datenbank warten oder auf

die Dateien. Ja, also sobald zwei Leute

da arbeiten, also nicht nur den Barkeeper,

sondern auch noch die Küche und du möchtest immer einen Drink mit

Essen servieren oder sowas. Und solange das Essen noch nicht fertig ist,

dann kannst du alle anderen Drinks schon fertig

bereiten. Ja, genau. Wenn du Abhängigkeiten

hast oder wenn du Wartezeiten hast, die kannst du

überbrücken, indem du da was anderes machst. Und das ist

Concurrency. Du machst nie Sachen gleichzeitig.

Du hast, der Bartender kann nie

mehrere Sachen gleichzeitig machen.

Dem wachsen keine fünf oder sechs Arme.

Genau, der hat halt nur einen

Prozessor.

Aber der kann mehrere Drinks gleichzeitig zubereiten.

Das heißt nicht, dass er überall gleichzeitig was reinschüttet,

aber das heißt halt, dass die alle

zu einem gleichen Zeitraum in Bearbeitung

sind. Genau wie der Jochen sagt, wenn

du fünfmal so viele Drinks

machen willst, brauchst du halt mehr Bartender.

Und die sind dann auch erstmal unabhängig

voneinander. Es gibt jetzt leider keine

Simdi-Bartender, die

mehrere Sachen

identisch gleich machen können, dann

könntest du fünf identische Drinks

gleichzeitig zubereiten.

Da wüsste ich jetzt keine

Analogie in der

echten Welt.

Async ist jetzt Parallelität

oder Concurrency?

Ich würde sagen, dieses Problem Parallelität

ist, also dass du

beides gleichzeitig brauchst,

das wäre jetzt mal eine steile These,

ich meine, ich weiß jetzt auch wieder, wann wir das schon mal hatten

Und ich glaube, das war tatsächlich in der ersten Sendung, wo ich halt auch meinte, so eigentlich diesen Fall, dass man beides hat, dass man Concurrency braucht und Parallelität, den hat man fast nie.

Also, oder mir fällt es schwer, mir dafür einen Use Case auszudenken.

Die anderen Fälle hat man, dass man viel Concurrency braucht, hat man, dass man viel Parallelität braucht, hat man, aber beides zusammen.

Ja, also ich kann mir jetzt viele Sachen vorstellen.

Also wenn ich jetzt beispielsweise vorstelle, autonomes Fahren oder Sport oder sowas.

und gleichzeitig fahren bestimmte Menschen

übers Eis oder sowas.

Und da musst du prognostizieren,

was dann passiert. Das ist echt parallel

für jeden Einzelnen.

Ja, aber das ist nicht concurrent.

Du machst das Auto fahren gleichzeitig.

Nein, es fahren alle gleichzeitig und alle müssen gleichzeitig

darauf reagieren. Und du möchtest ja für alle

gleichzeitig irgendwie Werte haben.

Du möchtest dann das ganze Team.

Das verstehe ich nicht. Tut mir leid.

Also du hast mehrere Fahrzeuge.

Du hast so einen Rechner, auf den mehrere

Fahrzeuge fahren? Das verstehe ich nicht.

Genau, du hast die ganze Flotte, die du steuerst.

Ja, aber die sind ja unabhängig.

Also ich würde sagen, das ist ein Anwendungsfall,

den kenne ich so nicht. Aber du hast ein gegnerisches Team

und das ist halt nicht unter deiner Kontrolle und du möchtest

dann trotzdem alle deine Leute,

deren Informationen du dann halt gerade erst

live einlesen kannst,

dazu bringen, dass sie parallel

die Entscheidung treffen,

die vernünftig,

statistisch wahrscheinlich ja zu besseren

Ergebnissen funktionieren, irgendwie so.

Der Dominik überspringt

so die simplen Schritte.

selber fahren können müssen, der macht direkt

komplett. Ne, tut mir leid, das würde ich sagen,

das ist kein Newscase.

Vielleicht doch. Da wüsste ich jetzt auch nicht.

Ne, aber

wir können ja direkt mal zu einem

super guten Newscase zurückgehen und der heißt

EVE Online. Da sind ganz viele Spieler,

die gleichzeitig Sachen machen wollen

und du hast aber trotzdem die große

Statustabelle auf dem Server, die du die ganze Zeit

aktualisieren musst und das musst du parallel machen.

Also ich meine, die Lösung, die EVE Online

dafür hat, ist halt, dass sie es langsamer machen.

Habt ihr EVE Online mal gespielt?

Nee, nur ganz viel drüber gelesen.

Oh, ich habe es tatsächlich auch mal ausprobiert.

Ich muss gestehen, ich war nicht in den Gruppen.

So viel Zeit habe ich nicht.

Ja, das habe ich auch nicht geschafft.

Aber es gab tatsächlich tolle Schlachten.

Also man hat dann so Schlachten gehabt,

wo dann so 20.000, 30.000 Schiffe verloren gegangen sind.

Und man konnte da ein Business draus machen,

weil da konnte man die Schiffe kaufen.

Das war richtig Geld, was da vernichtet wurde.

Ich glaube, in der größten Schlacht

wurden mehrere Millionen Dollar an virtuellem Kapital vernichtet,

gleichzeitig, weil man irgendwelche Sprungtouren blockiert hat

mit riesigen Flotten an Schiffen

und alles in die Luft gesprengt hat,

was dann ja nie zu finden war.

Ja, das ist das Geschäftsmodell von EVE Online, oder?

Ja.

Du kannst virtuelle Güter kaufen und sie dann verbrennen.

Ja, und du kannst sogar tatsächlich aber in diesem Spiel

konntest du halt Echtgelddinger generieren,

die du halt verkauft hast.

Und wenn du halt ein Wirtschaftsunternehmen,

Imperium, in diesem Spiel aufgebaut hast.

Es gab eine Leute, ich glaube, die haben über 20.000 Dollar

oder sowas im Monat gemacht,

indem die für EVE Online Businesses gebaut haben,

die sie da durch die Dachen geschleust haben.

Und wenn du dann halt sowas gemacht hast,

wie einen Krieg zu organisieren zwischen den einzelnen Fraktionen,

die sich gegenseitig in die Luft sprengen

und das halt alles auf dieser spielerischen Karte,

ohne dass das jetzt reale Auswirkungen hätte, also außer

wirtschaftliche, für die Jungs, die da vor dem

Rechner saßen, dann war das

schon irgendwie sehr faszinierende Geschichte.

Aber guck mal, Jochen, das ist doch

ein perfektes Beispiel, oder? Du hast ganz viele

Spieler, die gleichzeitig Sachen machen wollen und

du musst aber diese Statustabelle,

das ist parallel. Ja, also ich würde sagen,

ich bin nicht

so der Spielexperte, insofern, keine Ahnung,

aber ich würde jetzt mal sagen, Spiele,

die sind alle nur concurrent, da brauchst

du nichts parallel. Wenn ich jetzt so gegenseitig

spiele, ein ganz klassisches Killerspiel,

Ja, und wir schießen beide gleichzeitig aufeinander.

Aber wo brauchen die denn, wo brauchen die Spiele

denn bitte CPU?

Die brauchen überhaupt gar keine CPU.

Die Spiele heutzutage

laufen nicht mehr auf dem Client, sondern die laufen komplett

auf dem Server. Ja, selbst wenn die komplett auf dem Server laufen,

wo brauchen die denn CPU?

Diese vorher genannte

Battle, die der Dominik genannt hat,

wo dann 30.000 Leute teilnehmen.

Der Trick an der Sache, warum das funktioniert,

ist, dass die den Timestamp runterdrehen.

Das heißt, in so einer Zone, wo viele

Leute gleichzeitig sind,

Die müssen auf einem Server sein, damit diese Zone kohärent ist. Wenn da zu viele Leute sind, dann tun die so, als ob die Zeit langsamer läuft, weil der Rechner ausgelastet ist.

Und wenn die diese Status-Updates parallel abarbeiten könnten auf einem Rechner, dann müssten sie das nicht machen. Die gehen ganz, ganz hart ans Limit, weil die Simulation auf dem Server passiert.

zum Teil passiert die Physik-Simulation

auf dem Server. Das ist im Wesentlichen

der Grund.

Man hört ganz oft, dass

so und so viele Millionen Leute gleichzeitig in Fortnite

sind. Aber das stimmt nicht. Es sind nur

höchstens 50 auf einer

Instanz. Jetzt

gab es so Events, wo 10 Millionen Leute

bei so einem Konzert dabei waren.

Das ist ein kleines bisschen gelungen. Das waren 250.000

Instanzen mit

jeweils maximal 50 Leuten, weil da

einfach die Auslastung,

da ist der Prozessor voll.

Und da ist Parallelität einfach ...

Okay.

Je mehr Parallelität du nutzen kannst,

umso höher kannst du diese Zahl setzen.

Und umso weniger Instanzen brauchst du.

Und das ist richtig, da ist Geld drin und da ist richtig ...

Okay, vielleicht weiß ich einfach noch nicht gut genug,

wie Spiele funktionieren,

dass ich mir gar nicht so richtig vorstellen kann,

warum die jetzt CPU brauchen.

Also die Frage ist halt, wo ist da der Flaschenhalt?

Ist der Flaschenhalt tatsächlich CPU?

Das ist dann irgendwie sowas wie Netzwerk.

Ich glaube eher Concurrency und Netzwerk, ja.

Da müsste man Peer-to-Peer vielleicht machen.

Das würde vielleicht schneller gehen,

wenn man das irgendwie über Peers verteilt,

als dass man irgendwie alles durch einen Hals schickt.

Bei allen Leuten irgendwie so ein bisschen was weitergeht.

Da gibt es sicher viele Flaschenhälse.

Ich glaube, da ist alles, das ist so ein blödes Problem.

Wenn du ein Problem gelöst hast, dann kommt direkt das Nächste.

Wenn du einen Kopf abgeschlagen hast,

wachsen direkt vier neuere.

Aber CPU ist da einfach einer der Faktoren.

Vielleicht ist es bei Spielen so.

Ich kann es noch nicht so richtig nachvollziehen, aber okay.

Also ich meine, mir fällt auch ein Beispiel ein,

und das sind halt Datenbanken.

Da hast du nämlich auch beides.

Da hast du halt sowohl I.O.,

du hast halt, weiß ich nicht, 30.000, 40.000 Requests pro Sekunde,

Und die machen alle CPU.

Die machen alle irgendwie

Geschichten in irgendwelchen

Biotrees irgendwie durchsuchen,

irgendwelche Indizes

abgleichen,

ja, Hashes ausrechnen. Und je mehr

du gleichzeitig machen kannst, umso besser.

Genau. Also an der Stelle würde ich sagen, also Datenbank-Server

und Python schreiben, vielleicht nicht die beste Idee, weil das

wird schwierig. Aber... Wie ist es mit

Videostreaming? Auch das ist sowas, wo...

Würde ich sagen, komplett concurrent. Da gibt es nichts,

was irgendwie CPU braucht. Nein, überhaupt nicht.

Na klar. Also außer du kodierst irgendwie

um, aber ansonsten. Ja, und zwar, und musst

du. Du musst die Sachen umkodieren.

Dann. Jeder, jeder,

jeder moderne Streaming-Dienst,

also wir sind jetzt hier auf Whereby,

aber wenn du auf BBB gehst oder auf

Zoom oder auf sonst was, die kodieren alles um.

Tatsächlich

machen die Größenskalierungen,

damit die Clients mit

unterschiedlichen Bitraten versorgen können.

Und das kannst du entweder auf dem Client machen, was

nicht super zuverlässig ist, weil die Clients

halt auch Mobilgeräte sein können.

Du machst auf dem Server und dann bist du ganz knallhart

Ja, aber da würde ich sagen, da bist du doch sowieso schon

da ist der Flaschenhals auch wieder woanders, weil

dadurch, dass du

dass die einzelnen Clients, die du

dran hast, so fett sind

macht es doch überhaupt nichts, wenn du pro Verbindung

dann halt was Fettes aufmachst, wie ein Prozess oder so

Ja klar, aber du hast auf jeden Fall

Parallelität, du musst auf jeden Fall

diese 8 Streams

Das ist auch bei dem Spiel, wenn du sagst, es gehen nur 50 Leute

auf eine Instanz oder es gehen nur 50 Streams

über einen Rechner, dann machst du halt für die

50 Prozesse auf, gar kein Problem, geht das auch mit

Ja klar, aber das ist dann schon Parallelität.

Also du machst schon viele Sachen gleichzeitig.

Ja, aber

ein Fall, nach dem ich suche, ist,

wo du ganz, ganz viel Concurrency hast,

so viel, dass du das mit Prozessen nicht erschlagen kannst,

weil es zu viele sind. Also sagen wir mal,

du hast 10.000 Verbindungen gleichzeitig.

Aber das kannst du ja bei einem Webserver locker mal haben.

Ja, natürlich, genau. Also du hast

10.000 gleichzeitig, die auch gleichzeitig aktiv sind.

Nicht nur einfach eine Verbindung, die rumliegt, sondern tatsächlich

aktiv, über die irgendwas drüber geht.

Wenn du das Problem hast,

plus irgendwie CPU, dann kannst du es vergessen.

kriegst du es mit Python nicht mehr hin, weil Prozesse kannst du dann

nicht mehr nehmen. Ich glaube, du hast das ausprobiert.

Hast du mal so eine Story erzählt auf deinem Mac und

hast Kernelpanik verursacht. Kann das sein?

Ja, das habe ich jetzt im Zug.

Aber das waren Threads tatsächlich, keine Prozesse.

Also mit Prozessen wird das gar nicht gehen. 10.000 Prozesse

ist nicht möglich. Aber

Threads sollten eigentlich möglich

sein.

Nicht auf dem Mac. Und ich habe es

tatsächlich dann auch mal auf einem anderen ausprobiert,

um auszuschließen, dass irgendwie meine Hardware leicht defekt

ist oder so. Nö, auf Catalina

macht das halt sofort Kernelpanik, wenn man 10.000

Threads aufmacht. Also die

Lüfter gehen kurz an und dann ist der Rechner aus.

Ich habe da tatsächlich auch einen Bug bei Apple

aufgemacht. Das geht ja so nicht.

Ja gut, aber ich meine, wenn man da in die

Ecken und Kanten geht. Also ich habe auch schon mal

mein Mac mit einem Programm abgeschützt, was nur

das Clipboard

ausgelesen hat.

Ja, es ist

ein großes Kartenhaus.

Ein großes Kartenhaus.

Ja, tatsächlich. Ich habe es dann

jetzt auch nochmal auf Linux probiert und so und da

geht es problemlos, gar kein Ding.

Ja gut, aber so eine Situation

wurde 10.000 Threads.

Also ich meine, das ist dieses

berühmte C10K-Problem.

Wie schaffst du es, einen Web-Server

zu machen, der 10.000 Clients

gleichzeitig benutzen, bedienen

kann? Und wenn du

das hinkriegst, ist es besser.

Weil dann hast du weniger Web-Server.

Aber dafür würde ich sagen, brauchst du eben keine CPU, sondern das ist rein

Concurrency und das geht

problemlos mit einem Prozess

und einer zu bringen. Aber ich finde

bestimmt irgendeine Workload, wo du noch was berechnen musst.

Wo du noch, keine Ahnung, Bilder skalieren musst.

Ich glaube auch. Ich glaube, dass es sowas tatsächlich gibt.

Aber es ist so einfach, dass man

sagt, also ich kenne das ja dann immer so,

dass Leute sagen, das ist ja gar keine richtige

Problemgespräche. Aber ich meine, wer hat solche Probleme?

Also ich hatte sowas

ehrlich gesagt noch nie.

Und ich habe schon eine Menge Zwergs gesehen.

Bei mir war es entweder

Vielleicht ist es einfach so,

ich glaube, da ist so ein bisschen

Selection Bias auch drin, oder?

Gut, kann auch sein, ja.

Klar, wir haben auch schon viele Sachen gesehen,

aber wir sind halt in Python unterwegs

und wir sehen nur solche Sachen, die es in Python gibt.

Ja, ja, ja, das mag sein.

Das kann durchaus, ja.

Ja gut, wie auch immer.

Wie auch immer, aber genau, diese Parallelität-Ding,

also wenn man beides braucht, ist halt schlecht.

Das ist nach wie vor nicht gut in Python.

Aber sagen wir mal so, dieser Concurrency-Use-Case,

für den es ja tatsächlich auch Anwendungen gibt

und ich meine, Node.js ist einer der Gründe,

warum Node.js so populär ist,

ist halt, dass es damit besser ging.

oder dafür halt besser benutzt wurde,

äh, besser benutzbar war, äh,

und, ähm, ja, äh.

Ja, auch ein besseres Programmiermodell

hat, oder? Also dieses,

ähm,

Promisers und Futures und so weiter, das,

ja, das ist alles schon sehr einfach.

Ja, aber das ist eigentlich alles, äh,

sozusagen, das gibt's halt in Python ja auch.

Ähm.

Ja. Was, was gibt's denn da in Python?

Gibt's schon, aber. Kannst du das kurz beschreiben?

Ja, also gut, okay.

Also wenn wir jetzt schon

im Grunde wissen, okay, wir wollen das

eigentlich schon haben und das ist schon cool und das kann ja

wohl nicht sein, dass ich jetzt Node.js lernen muss, nur

irgendwie, um immer noch

hip zu sein,

dann kann man sich ja,

genau, kann man so, okay, wie macht Node.js das denn

eigentlich, weil Node.js hat

die gleichen Beschränkungen im Grunde, ist sehr vergleichbar

zu Python, hat die gleichen Beschränkungen,

da gibt es auch in GIL,

ja, ganz genauso wie in Ruby on Rails

und sonst irgendwie in PHP

Die ganzen Skript-Sprachen machen das ja alle.

Die machen das alle so, weil es halt auch sinnvoll ist.

Ja, und weil es halt

auch single-threaded die Performance, also wenn du

kein Multiprocessing brauchst, also wenn

du keine Parallelität brauchst und

keine Concurrency, dann ist es halt das Schnellste.

Ja, genau. Und was

Node.js macht, ist halt,

sie haben halt eine Event-Loop und

ja,

dann kann man halt

sozusagen

Callbacks auf dieser Event-Loop, oder sagen wir so,

das ist halt das, was ganz früher schon immer,

ich glaube, das ist schon immer möglich, irgendwie, man kann halt Callbacks

auf dieser Event-Loop registrieren, oder?

Ja, Callbacks sind ja was Schreckliches,

das ist doch die Callback-Hell. Genau, ja.

Gar keine richtige, gar keine lineare

Programmierung mehr. Hast du was gesagt? Hatte ich irgendwas gesagt?

Vielleicht gab es da irgendjemand, der hat was gesagt, der wollte,

er wartet noch auf irgendwas. Wie heißt denn das? Wie muss ich

dann da fragen, wenn ich das wissen will? Ach, Moment,

da steht jemand, der hat da rumgegangen, ach nee, da war noch

jemand anders. Ach, Moment, da war noch jemand,

der hat aber was gesagt, was dann irgendwie, ach, Callback,

ach so, da hinten, ach nee, da unten, ah, oh.

kriegst du ja immer. Das Problem ist, dass dein Programm

dann auch so aussieht, weil du die Callbacks

quasi in der falschen Reihenfolge definieren

musst. Du kannst nicht sagen, erst

A, dann B, dann C, sondern du musst

erst sagen, erst A und wenn es erfolgreich ist,

dann B, ansonsten C und wenn

B erfolgreich ist, dann zwischendurch

D und E und dann hast du A, B,

E, F und C

kommt dann irgendwo ganz anders. Das heißt, du hast dein

Programm nicht mehr, kannst es nicht mehr

von oben nach unten lesen,

sondern du musst es so gemixt

lesen und das ist ganz, ganz, ganz blöd

zu programmieren. Und deshalb hat JavaScript dann

irgendwann diese Promises und Futures eingeführt,

wo du einfach sagen kannst,

da kommt jetzt was zurück,

was irgendwann

fertig ist und

sobald du es benutzt, musst du halt warten.

Ja, kann man,

in Python

gibt es das halt quasi ganz genauso.

Also seit 3.2

gibt es Concurrent

Futures.

Ich weiß nicht, ob sich

JavaScript, das auch so das Promises-Konzept

da so ein bisschen abgeguckt hat. Also Python hat sich das

abgeguckt aus der Java-Welt tatsächlich,

wo es dieses Future-Konzept wohl schon länger gibt.

Aber in Java nimmt man doch viel eher Threads, oder?

Ja, aber man kann auch

das machen.

Genau, also aber

sagen wir so, wenn wir jetzt schon bei den Callbacks sind,

oder bei dieser

Art, das kann man halt in Python

im Grunde auch so machen.

Ja, klar.

Ja, also

das ist auch in dem Async-Teil, also

sagen wir mal so, man muss das wahrscheinlich alles

so ein bisschen voneinander unterscheiden, es gibt halt

ein riesiges Glossar machen. Ja, genau,

wie das unten drunter aussieht, was man unten drunter für

einen Mechanismus verwendet, um halt

Concurrency zu erreichen und

was man dann für Abstraktionen darüber verwendet,

weil tatsächlich in Async.io jetzt

sozusagen die aktuell

in der Standardbibliothek

befindliche Lösung für diese

Concurrency-Geschichte ist halt

Ja, sogar in der Sprache, oder? Ist nicht

eine Bibliothek, sondern ist richtig in die Sprache integriert

mit Schlüsselwörtern. Ja, aber

das ist auch eine

gute Sache, das ist voneinander getrennt. Also,

was in der Sprache tatsächlich drin ist, ist halt

sind halt Async-Funktionen.

Also, die man halt mit Async-Dev

Async-Dev, genau, und Await

mit diesen Schlüsselwörtern

kann man da operieren, aber

in der Sprache ist nur definiert,

dass diese Geschichten dann, wenn du sie

aufrufst, halt eine Co-Routine zurückgeben.

Es ist nicht gesagt, wie

das jetzt alles sonst funktionieren muss. Der Rest ist

halt... Ja, okay, klar, die Event-Loop

und so weiter. Du kannst nämlich, genau, du kannst halt

Async-Dev und Await

auch in Trio verwenden. Und Trio verwendet ein ganz anderes

Modell unten drunter als jetzt Async-IO.

Trio, das

ist eine Implementierung

sowas Ähnliches wie Async-IO,

bloß mit einer

etwas moderneren, etwas anderen Zielsetzung.

Also es gibt diverse. Es gibt Async-IO,

ist in der Standard-Bibliothek. Es gibt

Curio, das ist das

von David Beasley.

Ist halt sozusagen erst ab Python 3.7

und irgendwie so ein bisschen

advancer.

Und dann gibt es nochmal die advancedere

Version von Nathaniel Smith

im Trio.

Und das Ding macht

im Grunde sowas ähnliches, aber halt

anders. Also die Art, wie man es

programmiert, ist halt anders.

Und benutzt aber Async-Def kann man

in all diesen Dingern verwenden, weil

das halt nur sagt, okay, wenn ich

eine Async-Funktion habe, dann

gibt die halt eine Core-Routine zurück.

Und ich kann jetzt damit irgendwas machen. Aber wie das

Programmiermodell aussieht, was ich dann mit diesen

Co-Routinen mache. Das ist ja demjenigen, der

das sozusagen, dieses Framework implementiert,

überlassen. Und da gibt es unterschiedliche

Ansätze. Und im Grunde

Trio ist

so ein bisschen das zu Ende gedacht, dass das halt so

ein Problem ist. Also das wurde ja auch schon angedeutet

mit dieser Callback-Hell-Geschichte. Also

das grundsätzliche Problem, was

auch der Autor von Trio da identifiziert

hat, also ich packe da auch mal

einen Artikel, wo man das in Detail nachlesen

kann in die Shownotes, dass er sagt,

das ist alles, also die Problematik

großer Teil der Probleme, die wir hier sehen, sind

die gleichen Probleme, die Leute

früher mit GoTo hatten.

Oder ich sag, das ist halt eine sehr gute

Analogie dafür. Wir sind in der Assembler-Welt

angekommen, wenn wir über GoTo sprechen.

Ja, nee, nicht ganz Assembler.

Ganz viele Sprachen, die GoTo haben.

Ja.

Also,

das Problem bei GoTo ist halt irgendwie,

dass es dir,

was das unmöglich macht,

ist halt lokal über Code nachzudenken.

Weil du weißt halt nicht, also er hat

dann halt so ein schönes Diagramm, wo man halt

er macht halt immer, er geht von einem

Go-To zu einer Zeile und dann, er macht das halt

immer weiter, bis du halt siehst, das ist ein riesiges

Spaghetti-Kneuel. Das heißt, du

weißt halt nie genau,

wie du eigentlich hingekommen

bist und wo es hingeht.

Und zum Beispiel, du kannst halt keine

Tracebacks werfen, weil du weißt überhaupt nicht, wo du herkommst

eigentlich. Und

das ist halt relativ schrecklich,

du musst halt dann das Programm

immer komplett verstehen. Ansonsten

kannst du nicht sagen, was da gerade passiert

weil es keine lokalen Blöcke gibt, wo man sagt,

okay, ich habe jetzt ungefähr verstanden, was das Ding tut.

Das muss ich jetzt nicht noch,

also ich brauche nur zu wissen, wie die Abstraktion davon ist.

Und das reicht mir, um damit arbeiten zu können.

Zum Beispiel irgendwie sowas wie Print Hello World.

Print macht intern was relativ Kompliziertes.

Das macht irgendwie Syscalls,

das macht irgendwie alle möglichen komischen Dinge,

die halt dann so zu tun sind,

wenn dann was auf der Konsole erscheinen soll.

Aber das muss man

alles nicht wissen, sondern man ruft das einfach auf

und das geht. Und Funktionen sind halt

super, weil genau die brauchst du ja

eigentlich nur zu merken, was das Ding tut, aber wie das

intern funktioniert, das muss einen nicht mehr interessieren.

Ist auch die gleiche Idee bei Klassen und so weiter.

Und mit Gotoh funktioniert

das halt nicht, weil du nicht sagen kannst,

okay, ich weiß jetzt, was hier

passiert und muss mir darüber keine Gedanken mehr machen,

weil es kann halt passieren,

dass dein Code nicht wieder dahin zurückkommt,

wo du es, also es gibt nicht so einen Aufruf, der wieder

zurückkommt, sondern das kann

verschwinden und ist dann halt irgendwie weg und es passiert was völlig

anderes. Und das ist halt schlecht, wenn

das so ist, weil dann kann man nicht mehr lokal

über Code nachdenken. Und

er meinte halt so, ja gut, also in den

Ende der 60er, 74er

Dijkstra und so, da gibt es halt den berühmten Artikel,

die haben sich da Gedanken gemacht und

deren Vorschlag war halt, ja,

Gotoh rauswerfen,

verbannen, irgendwie ächten

und stattdessen sowas verwenden wie

Funktionen und Blöcke und so.

Und das hat sich durchgesetzt

und auch lustig, die

Gegenargumente damals und auch

Knut hat zum Beispiel gesagt, oh nö, ich

finde Kutu eigentlich ganz gut.

Auch sehr interessant.

Knut? Ja, Donald Knut.

Ah, war das nicht der, der

sowas gesagt hat wie Premature

Optimization is the root of all evil?

Genau, genau der.

Aber dieses Zitat ist mit

sehr viel Vorsicht zu genießen. Er hat auch gesagt, wenn man

drei Prozent rausholen kann, dann ist es nicht mehr

Premature.

Ja, ja, ach ja, andere Zeiten.

Ja, jedenfalls.

Genau, der war da auch nicht unbedingt so totaler Fan von Gotoh Rausschmeißen,

weil so eines der Argumente war halt so,

ja, das bedeutet ja, wir müssen ganz anders programmieren lernen.

Wir haben jetzt über Jahre irgendwie,

haben wir uns auf ein Level begeben,

dass wir damit irgendwie jetzt klarkommen

und haben uns so Methoden angewöhnt, wie man damit umgeht.

Und wenn wir das jetzt so ändern,

dann müssen wir im Grunde nochmal neu programmieren lernen.

Und ja, das ist wohl so.

Und vielleicht wird es dann sogar langsamer,

weil eben diese Funktionsaufrufe

und diese ganzen Strukturmechanismen,

die verbrauchen ja auch Rechenzeit.

Ja, natürlich.

Und Speicherplatz.

Genau.

Und wenn du nochmal 3% irgendwo rausholen kannst,

dann kannst du das auch machen.

Und wenn der Mainframe super teuer ist

und Arbeitskraft super billig,

dann macht es vielleicht sogar Sinn.

Aber heute vielleicht nicht.

Ja, das ist halt,

wir stehen auf den Schultern von Riesen.

Wir haben heute genügend Prozessoren,

Wir haben genügend Megahertz,

dass wir uns das leisten können.

Ja, und im Grunde,

er sagt halt, ja,

also bei Concurrent

Programmierung

hat man im Grunde in gewisser Weise das gleiche Modell

und er sagt zum Beispiel, Futures

findet er ganz schrecklich, weil

die im Grunde das gleiche Problem haben

wie Gotoh, weil du kriegst halt was zurück.

Also du rufst eine Funktion auf, du kriegst was

zurück, aber du bist ja

gar nicht, das ist ja gar nicht linear zurück.

Dein Code geht ja nicht linear weiter.

sondern irgendwo anders passiert

irgendwas, das aber

durchaus Auswirkungen darauf haben kann,

was später in dem Code, der dann

jetzt sozusagen von dir aus gesehen weiterläuft,

darauf Auswirkungen

hat. Das heißt, du musst wissen,

okay, der Task, der dann auch läuft, der wird

später mal irgendwas Böses machen oder

vielleicht noch irgendwie, keine Ahnung. Und da muss ich auf jeden Fall

dran denken, dass der mir vielleicht irgendwie dazwischen

grätscht oder ich muss hier mal einen Lock setzen, damit das irgendwie

atomar bleibt und keine Ahnung.

Das heißt,

ich kann nicht mehr sagen, okay,

ich habe jetzt diese Funktion aufgerufen,

ist es gut, ich weiß jetzt Bescheid,

es hat funktioniert oder nicht

und ich mache jetzt weiter, sondern

ja, ich habe dieses Future-Ding in der Hand,

aber tatsächlich muss ich

mir irgendwie selber merken, was da noch alles

passieren kann und das ist natürlich schlecht,

weil das macht halt genau diese lokale,

dieses lokale Nachdenken

über Code kaputt und er sagt

halt so, alle Concurrency-Lösungen, die

dazu führen, dass man nicht mehr lokal

über Code nachdenken kann, das ist

alles, das ist alles nicht richtig,

Das sollte man so nicht machen.

Was ist da die Lösung jetzt davon?

Er hat da so ein Konzept,

das heißt dann irgendwie

Nurseries.

Nurseries, die kleine Krankenschwester,

die die Babys auf der Aufzuchtstation ist.

Genau, er sagt so, ja, so Tars

oder sind so wie so kleine Kinder,

die darf man nicht einfach so frei rumlaufen lassen,

das ist nicht gut.

Die muss man irgendwo einsperren,

wo sie dann gepflegt werden.

Wo sich jemand drum kümmert.

die dürften aber nicht raus. Ja, genau.

Und das Ganze ist in so einem Context-Manager drin

und tatsächlich, also ich habe noch nicht

so viel damit rumgespielt. Also es sah gut aus, aber

ja, angeblich

ist das wohl eine Möglichkeit,

das so hinzukriegen, dass

dass man weiterhin lokal über Sachen nachdenken kann

und dieses Problem, dass man

Spalter-Effekte hat, gar nicht mehr bekommt.

Und es ist sogar teilweise

einfacher, Sachen damit umzusetzen.

Es gibt da diesen für IP

Happy Eyeballs-Algorithmus,

der auch in Twisted drin ist. Und es gibt eine Twisted-Implementierung,

die ist 120 Zeilen

und relativ fies. Und es gibt eine

in Trio und die ist halt irgendwie,

weiß ich nicht, also ich meine, obwohl Zeilen

vergleichen ist auch wieder ein bisschen Quatsch, aber

also viel, viel weniger und viel

klarer. Und als er das Ding

in Trio nachgeschrieben, hat er auch diverse logische Fehler

in der Twisted Implementation

gefunden, weil das einfach

super schwierig ist, das so hinzukriegen

mit den Futures. Also in

Trio gibt es keine Futures mehr,

es ist halt eher so, es gibt diese Nurseries

und ja, es wurde auch schon

darüber nachgedacht, ob das nicht vielleicht eine gute Geschichte

wäre, das in

Python direkt einzubauen

und statt AsyncIO zum Beispiel

zu verwenden, aber das ist alles

noch gerade so dabei,

quasi noch nicht sprunghaft.

Ist der Zug nicht schon längst abgefahren?

Vielleicht schon, ja.

Ja, vielleicht ist er das schon.

Viel zu viele Leute, oder zu viele Leute

verwenden Async.io, als dass man

das noch vielleicht ändern könnte. Und es gibt halt da

diesen Ökosystem-Split und

wahrscheinlich ist es besser, dann eben

auf das zu versetzen, was eh dabei ist.

Trio macht das sowas, du hast jetzt gesagt,

Kontextmanager, das heißt, man muss diesen lokalen Scope

nicht verlassen. Ist das nicht eigentlich das, was Funktionen

tun, sowieso schon?

Ja, ja, aber Funktionen funktioniert halt nicht so richtig.

Weil?

Die Tats laufen ja weiter.

Das ist halt auch bei

wenn du halt eine Funktion

wenn du

Concurrence irgendwas machst, dann

hört das halt nicht in dem Moment auf, wo du das

aufgerufen hast, sondern das läuft halt unter Umständen weiter.

Das heißt, ich habe beispielsweise nur

den halben Whisky eingeschenkt und die andere

Hälfte, die kommt aber noch.

Aber woanders fängt der halt an, dann schon

andere Limetten rein zu

Ja, also

Und was ist der Unterschied?

in Trio, dann macht er dann trotzdem erst den einen Schritt fertig?

Oder wieso ist das so isoliert?

Also, dass du vielleicht bei diesem Barkeeper-Beispiel

das so anschaulich hinzubekommen

kriegst? Weiß nicht, ob ich das tatsächlich hinkriege.

Also, kann man sich, müsste man

sich selber angucken. Da gibt es auch Schaubilder auf der Seite.

Aber das zu erklären,

weiß ich nicht, ob das... Das ist so ein bisschen das Problem,

das generelle Problem an Current Programming,

oder? Dass diese Sachen alle gleich so kompliziert

werden, dass man dann diverse Schaubilder

braucht und Leute dann

irgendwann sagen, ja, lass lieber die Finger davon,

das ist nicht so. Ja, und tatsächlich ist das

vielleicht gar keine so schlechte, ich glaube, ich würde auch sagen, also auch meine

Erfahrungen, die ich damit so bisher gesammelt habe,

die waren alle immer, es war immer

ziemlich fies, also das war immer,

also die Beispiele,

die haben immer funktioniert, wenn man sich irgendwie

so Tutorials oder so anguckt, wenn man es

dann tatsächlich ausprobiert mit irgendwie

in den Fällen, wo man es dann halt

wirklich braucht, wo man dann viel Last macht,

dann sind mir jedes Mal

passieren komische Sachen

und das Debugging ist jedes Mal

Das ist so bei Ginkgo Program, da passieren immer

komische Sachen. Ja, also wirklich, also

zum Beispiel einen Bug

und diese

Geschichten, ich meine, das passiert anderen Leuten auch.

Zum Beispiel

der Gründer von

der ursprünglichen Entwickler von

Twisted hat einen langen Artikel darüber geschrieben,

warum er Multithreading hasst.

Wo er dann geschrieben hat, sie hatten

also Probleme und sie hatten dieses

sie hatten einen wirklich fiesen Bug

in einem größeren System und

der ist halt irgendwie nur

ab und zu aufgetreten. Sie haben es überhaupt niemals

reproduzieren können und sie sind es nicht losgeworden.

Und sie haben alles

from scratch nochmal neu geschrieben,

reimplementiert, um den Bug wegzukriegen,

weil sie ihn einfach über Monate nicht finden konnten.

Und das ist eigentlich schon echt bitter.

Es ist auch super schwer

zu testen, so Zeug. Das ist auch super schwer

zu sagen, wenn ich X mache und Y,

dann passiert Z. Sondern es ist halt,

wenn 37 Leute gleichzeitig X machen

und einer von denen aber Z macht und

einer von denen Y und

23 A und B, dann

passiert irgendwas.

Und Buchstabensuppe.

Aber dann passiert Buchstabensuppe und das ist ein Bug.

Ja, was ich

da mal hatte, war halt, genau,

ich hab halt so was Webcrawler-artiges

geschrieben und

mit ein paar tausend Seiten und

weiß ich nicht, so hundert

Seiten gleichzeitig abfragen pro Sekunde oder so,

alles gar kein Problem. Aber so, okay,

gehen wir auf eine halbe Million oder eine Million und machen

das mal so irgendwie ordentlich, so mit ein paar tausend

pro Sekunde. Und dann passieren

plötzlich seltsame Geschichten.

Irgendwie sterben plötzlich

Sachen oder was ich dann hatte, es wird

plötzlich irgendwie seltsam langsamer.

Man weiß nicht warum. Plötzlich

kriegt man ganz eigenartige

Tracebacks aus den Tiefen von Python.

Also was ich dann irgendwie

rausgefunden habe,

das war halt irgendwie die Resolver-Library

auf meinem Mac. Ich habe es auf dem Mac probiert.

Die hat halt irgendwie angefangen, plötzlich Probleme

zu machen. Und

zum Glück auf Linux ging es dann. Das ist auch

immer sowas. Ja, Mac gibt es dann

vielleicht für Smoketest gar nicht

so schlecht. Der macht dann irgendwie

ein bisschen früher irgendwie

fängt er an zu rauchen.

Bei Linux gehen dann viele Sachen, wo der Mac

dann schon raucht, aber

das war, und da habe ich auch lange dran rumgedebuggt

und nichts gefunden und das ist ganz schrecklich.

Ja, Load macht

Dinge kaputt, die

schwer zu finden sind und schwer zu sehen

sind.

Die dann auch nur so sporadisch auftauchen.

Da wird es dann auf einmal statistisch, wenn du

sagst, okay, mein Programm geht

in 99 Prozent

der Abläufe.

Das ist dann der echte Bug. Das ist dann wie, dass in der Schaltung

irgendwo ein Käfer reingeklettert ist,

weil die Schaltung so groß ist, dass da irgendein Käfer dazwischen

passt und du weißt aber nicht, woran er liegt.

Ja, wenn halt der DNS-Resolver nur 99 Prozent aller Anfragen

korrekt beantwortet und in einem Prozent der Anfragen

halt abstürzt oder irgendeinen Quatsch macht,

dann hast du halt so statistische

Dinge. Aber das ist natürlich sehr unbefriedigend,

weil ja eigentlich,

also als Softwareentwickler

oder als Informatiker ist man ja gewöhnt, dass wenn es

geht, dass es dann zu 100 Prozent geht und

immer.

Ein anderes Beispiel, eben

Lukas Langer, der hat ja bei Facebook

gearbeitet und hat dann auch so ein Beispiel für,

sie hatten halt irgendwie ein Ding, was halt auch

Async.io gemacht hat und dann

haben sie da auch Durchsatz,

wenn es anfing, so richtig Durchsatz zu machen,

wurde es plötzlich irgendwie magisch

langsamer.

Das sind die schlimmsten Sachen.

Sie haben dann irgendwie auf ihre Kurven geguckt

und sie haben es nicht verstanden und dann, bis dann

irgendwann jemandem aufgefallen ist, oh,

wo kommen eigentlich diese Kurven her?

Es gibt da halt noch einen Thread, der guckt sich halt an, was die anderen Threads so machen und was die anderen Tasks so machen. Und der hatte halt in der Art, wie er dann halt die Ergebnisse von dem, was er gesehen hat, wie er sammelt hat, irgendwie so einen naiven Algorithmus drin, der mit der Last nicht gut klargekommen ist.

der dann halt schnell langsamer

geworden ist und der wurde dann so langsam, dass er alles andere

aufgehalten hat und da ist dann

sozusagen die CPU rausgelegt

und ja, also

aber das sind alles so ganz ekelhafte

Probleme, also das ist

wenn man das nicht braucht, sollte man das nicht machen, glaube ich

das wäre so

Ja, oder halt sich möglichst

weiter von fernhalten, also ich meine, wir

sind ja Django-Entwickler und wir haben das ja schon lange

wir haben ja schon lange

Sachen, die konkurrent sind, weil wir halt

wenn du irgendwo was deployst, dann machst du halt

zehn Unicorn-Prozesse an oder so.

Aber die sind ja im Wesentlichen

unabhängig voneinander.

Die kommunizieren

nur über die Datenbank. Die Datenbank ist

da das, was die Currency macht.

Oder was die gleichzeitig

hat. Dass die Datenprobleme löst, dass das isoliert ist.

Genau. Da bin ich ganz froh, dass es

eine gute Datenbank gibt.

Genau. Wo ich einfach sagen kann, okay,

das kann ich messen, wie lange braucht

es, diese Query auszuführen

und wie viele können das gleichzeitig. Und wenn da zu viele

Leute gleichzeitig kommen, dann müssen die halt warten.

Wenn dann zu viele da sind, dann muss man halt die Timeouts hochstellen und sagen, fertig. Aber das ist so ein bisschen Concurrency Light, weil du eben die Sachen so sehr voneinander abtrennst, beziehungsweise das ist die smarte Concurrency. Du trennst die Sachen so weit voneinander ab, dass sie unabhängig voneinander sind.

Und wenn sie so unabhängig voneinander sind, dass sie sich gar nicht, dass sie keine Kommunikation machen müssen, dann kannst du sie auf verschiedenen Rechnern ausführen, dann kannst du sie skalieren, kannst du sie wegskalieren, ja, entweder über Prozesse oder über Prozessoren, über unterschiedliche Maschinen oder über, was weiß ich, Docker-Container, die dir dann, oder über einen Kubernetes-Cluster, ja, wo du dann halt im Prinzip das Gleiche an ganz vielen verschiedenen Stellen ausführst und das ist ein Modell.