Zlý vtip menom async v djangu (pythone) (diskuse)

[mirec]

Příloha:

• download.zip (238858 bytů)

Keďže sa k blogu nedá priložiť súbor prikladám tu. Veľa sa tu na abclinuxu od mojej poslednej návštevy nezmenilo. Akurát ja som o dosť starší, šedivejší a bývam s 10 mačkami v dome.

[Want]

Veľa sa tu na abclinuxu od mojej poslednej návštevy nezmenilo. Akurát ja som o dosť starší, šedivejší a bývam s 10 mačkami v dome.

To je teda ale smutný příběh.

[mirec]

Smutný ani nie, ale 10 mačiek je dobrý začiatok konverzácie :P Sám nie som, mám partnerku, ktorá má rada mačky, veľa cestujem, mám catsittera kým som preč, veľa koníčkov, aktivít. Škoda akurát, že dni nemajú viac hodín.

[_]

nemackej macky nemaj to rady

[karkar]

Možná keby si najal catsitterku, možná by kvůlivá mačkám preskočila iskra.... a moh' bys několik koček propustit... 10 je imho moc...

[mirec]

Je to veľa, ale už sú také stále. Mal som aj viac, rozdal som. Občas sa niekto spýta, či nechcem darovať. Hmm iskra medzi mačkami a ňou?

[karkar]

Nene, vymeniť část mačiek za catsitterku teda iskra medzi tebou a catsitterkou

[mirec]

Mám partnerku (človeka) a som monogamný takže nie :)

[karkar]

[vlk]

Ja som vobec neprisiel na chut async-u. Davam prednost prehladnosti, jednoduchosti a dobremu navrhu pred nejakymi sialenstvami. Ak potrebujem nieco naozaj paralelne (ale akoze naozaj - ze inak sa neda) tak mam stale v zalohe multiprocessing.Process a vynimocne este Thread. A obcas mi padne do vyuzitia yield a tam to konci. Ale mozno ta nechut do async asi bude aj tym sedivenim (a to nemam ziadne macky!)

[RealJ]

Zajimave, ja to mam presne naopak.

[RealJ]

Ja ti nevim, kdyz neco pisu (jako amater), tak to vzdy pisu pro async. Psat v dobe 100+ core CPU a ruznych clustru neco synchronne mi prijde jako nevyuziti dostupneho vykonu. Delam hodne s daty v ruznych formatech (jako amater) a nezpracovavat je asynchronne by me zabilo. K tomu blogpostu - nevim co mas za db ale mozna narazis na db limits.

[mimi.vx]

az na to ze async nema s vyuzitim cpu cores moc spolecneho ...

 

na tyto strandy jsou multiprocess a multithread moduly + concurrent.

[RealJ]

Takze async neresi “overlaping overlaping waits on single thread”? A jak chces bez async vytizit 100gbit sitovku nebo rychly storage? Ja chapu, ze async resi IO ale to je jaksi provazane s multicpu systemy.

[vlk]

spracovanie dat zo 100gbit siete nebudem riesit v pythone

[mimi.vx]

a zrovna tyto dva priklady nejsou o vytizeni cpu .. ale presne o cem async je .. IO

[kralyk z abclinuxu]

Ja chapu, ze async resi IO ale to je jaksi provazane s multicpu systemy.

No, ani ne. Původní C10k problém je formulován na single-threaded službě. Zvýšením počtu CPU to prostě akorát horizontálně škáluješ...

[🇨🇽]

az na to ze async nema s vyuzitim cpu cores moc spolecneho

cpu si muže jít makat na něčem jiným zatimco se čeká třeba na I/O :O ;D

[Aleš Kapica]

Příliš sofistikovaný fakt, který Žako nikdy nepochopí.

[kralyk z abclinuxu]

Ale on má pravdu. Synchronní I/O neblokuje CPU, blokuje daný thread od toho, aby mohl být naplánován na CPU. Ostatní thready nijak neblokuje.

[mimi.vx]

jop, az na to ze to v klidu muze byt pouze 1 cpu s 1 jadrem ... nic co by nejak ovlivnilo multicore system ...

 

proste async != paralerni ..

 

A prohlasit ja vse pisy async abych vyuzil vsechan jadra CPU znamena jen jednu vec ... netusis co to async je a  proc je .

[mirec]

Async kód využíva kooperatívny multitasking. Niečo, čo vzniklo v dobách jednoprocesorových strojov. Spoliehať sa len na async znamená využívať jediné jadro. Ak sa bavíme o pythone tak správnou cestou je multiprocessing, alebo subinterpretery alebo novy no-GIL. Inak sa bude striedavo využívať jediné jadro.

Správnym využitím async je v prípadoch, keď sa čaká na IO, ale aj vtedy môže byť rozumnejšie kombinovať multiprocessing s asyncom a nemať jeden veľký loop pri veľkom množstve spojení s väčšou priepustnosťou.

Sám by som rád písal čistý async kód, ale knižnice, ktoré používam nie sú prepísané do async a nik ich do async celkom neche prepísať, lebo by bolo potrebné prepísať komplet kód, ktorý ich využíva a vlastne musel by sa infikovať celý ekosystém.

Na limity databázy nenarážam. Používam PostgreSQL 17 s nastavenými max 100 connections.

[vlk]

zabudni na 100+ core, async bezi na jedinom vlakne, navyse to ma aj nejaky overhead ked prepina medzi ulohami ktore spracovava asynchronne. s obycajnym selectom dosiahnes lepsie vysledky..

[jbv]

Python 3.14 ma patche, kde async ve free threaded verzi skaluje linearne s poctem threadu. Viz clanek od autora. Samozrejme to jeste muzes zabit, kdyz budes spatne zamykat atd. ale to plati pro async ve vsech jazycich.

[Bystroushaak]

Zeptám se možná naivně: k čemu to je? Myslel jsem že hlavní výhoda async programování (resp. korutin obecně) je že běžíš v jednom threadu a nemusíš řešit zámky a synchronizační primitiva, takže máš jednodušší kód. Tohle je pak jen threading with extra steps, ne?

[jbv]

Zámky musíš řešit vždycky. Nikdy nevíš, která korutina zrovna běží. Můžou tam nastat stejné problémy jako v threadech na 1 CPU (rozdíl je jen v tom kdo rozhodne o přepnutí na jinou úlohu: programátor vs. runtime). Obecně to vidím tak, že threading je super pro CPU bound úlohy. Máš dobrou utilizaci zdrojů a dobrý výkon. Async je super pro IO bound úlohy. Zvyšuješ tím utilizaci zdrojů a propustnost (nemáš všechny thready čekající na IO a nemusíš jich pouštět milion). Víc threadů pro async znamená větší výkon serveru, stejně jako v synchronním kódu (např. můžeš pustit 8 instancí s 1 vláknem vs. 2 s 4 vlákny). Pokud se bavíme o pythonu, tak je to mnohem lepší než použít multiprocessing, protože můžeš poslat čekající úlohu na jiný nevytížený thread. Bez toho je lepší load balancer a jeden proces stejně jako v node (tím si zase komplikuješ architekturu aplikace).

Co je na async těžký, že ty musíš řešit přepínání kontextu. Pokud to uděláš blbě, tak jen zvyšuješ latence. Pokud dobře, můžeš dosáhnout lepší utilizace zdrojů a menších latencí než v synchronním kódu. Ale tohle záleží na úloze.

[jbv]

Ještě třeba příklad serveru, kde nejde ani o výkon, ale nechceš mít jen jeden thread. Máš server, kterému se rychle mění vydávaná data pod rukama a zároveň je hodně vytížený od uživatelů a IO pro získání potřebných dat je pomalé. Aby věděl, jaká je poslední verze dat, tak mu chodí zprávy z message queue nebo je to někde v redisu nebo i klidně v normální databázi. Takže pokud tyhle věci nestíháš procesovat asynchronně v jednom vlákně abys nezvyšoval latence pro klienty, musíš pustit druhý thread pro aktualizaci stavu. Takže už ti běží 2 a třeba klidně každý v jiné async loop (abys nebrzdil odbavení klientů updatem dat). Tady je už potom na pováženou jestli se vyplatí mít 2 thready s veškerým overheadem synchronizace a škálovat instance serveru nebo jestli není jednodušší pustit všechno v jedné async loopě a provozovat jí na víc threadech. Např. mít 20 instancí toho samého serveru na víc strojích už znamená obrovské rozdíly ve výkonu už jen kvůli cache filesystému v linuxu, jiném vytížení sítě apod. Obrovsky si tím komplikuješ provoz. Ale chápu, že při malém provozu nebo velkém provozu a malé zodpovědnosti programátorů je lepší to neřešit.

[Bystroushaak]

Zámky musíš řešit vždycky. Nikdy nevíš, která korutina zrovna běží.

Myšleno jako že kód mezi dvěma awaity je z pohledu běžících korutin možno brát v podstatě jako atomickou operaci. Což ti teda přestane platit, když to běží ve vícero threadech na vícero event loopech.

Obecně to vidím tak, že threading je super pro CPU bound úlohy.

Tak v současnosti je to v py přesně naopak, ne? Protože GIL ti tohle zabíjí a dělá ti to použitelné hlavně pro IO bound úlohy.

Pokud se bavíme o pythonu, tak je to mnohem lepší než použít multiprocessing, protože můžeš poslat čekající úlohu na jiný nevytížený thread.

Mno, tohle jsem teda nějak nepochopil. Jakože nějak mixuješ terminologii, nebo topologii. Při topologii kde máš vyšší počet worker procesů jak počet jader/threadů procesoru a nějakém obsluhování queue to bude to samé, ne? Zprávu si vezme z queue nevytížený proces.

Threading / multiprocessing bude mít větší overhead než asyncio při spouštění workerů, což typicky řešíš tak že pustíš nějaký pool workerů a dál to neřešíš. Paměťově asi vyjde vždycky líp asyncio? Umím si představit že asi nižší latence dělá pouštět korutinu pro každý příchozí požadavek, protože když se ti vytíží ten worker pool, tak buď budou nové požadavky čekat, nebo musíš pouštět nové thready a tady asi vynikne výhoda asyncia?

[jbv]

Krasny doklad toho, ze stejne jako AI ani blbci neumej programovat

[Heron]

Já teda moc nevím, k čemu je přesně určeno použití async na single thread programu / interpretru, ale nás už od vysoké (2006) učili všechno dělat ve vlastním threadu. V C je to složitější (fork a IPC) ale v moderních jazycích typu Golang nebo Rust je to trivka. Na vše, co může být vlastní thread (gorutina), je prostě vlastní thread. Už si ani nepamatuju, kdy jsem naposledy napsal single thread program.

Jasně, async je vhodný tam, kde se čeká na data z disku nebo ze sítě, tam to skutečně může pomoci, ale dneska thread má skoro nulovou zátěž, IRQ jsou rozhozena na jádra, takže posluchač na síť běží na stejném jádře, kde je připnuto IRQ od síťové karty. A tak dále.

Tohle je jeden z důvodů, proč jsem opustil Python. Multithread se tam v podstatě dělá jen přes multiprocessing.Pool.Map a tím to tak nějak ve standardním pythonu končilo. V čemkoliv jiném si vytvořím miliony gorutin a ať se o to postará runtime (v golangu to zrovna není žádný problém).

[kralyk z abclinuxu]

Tos poněkud namíchal jabka a hrušky.

dneska thread má skoro nulovou zátěž

OS thread má stále netriviální zátěž, protože alokuje dopředu celkem velký stack. Golang korutiny jsou odlečené userspace thready, které Go runtime plánuje na konečný počet OS threadů. Stack řeší (relativně) malými dynamicky rostoucími stacky. Rust korutiny jsou stackless. (Obojí má nějaké výhody/nevýhody.)

[Heron]

A je potřeba tohle vůbec řešit s výjimkou velmi expertních příkladů, kde je nutné zachovat nějakou definovanou latenci? Ptám se vážně.

Protože kdykoliv slyším rady typu "nepoužívejte moc tohodle, protože je to pomalejší", tak to zkusím prostě schválně přehnat a zatím úplně všechno funguje zcela podle očekávání. Měl jsem i 250 running procesů na 1CPU v době, kdy jsem to uměl spustit všechno současně, ale neuměl jsem frontu (nebo se mi prostě nechtělo to řešit). PC mělo load 250, ale dalo se stále používat v Xkách (stačí nastavit nice). V golangu (ano vím, že to má pouze NCPU OS threadů) počítám v milionech gorutin. PovRAY jsem schválně benchmarkoval až do 80threadů (na 16 thread starém CPU), abych Frantovi ukázal, že výkon opravdu neklesá s počtem os threadů. Takto jsem vlastně vůbec nikdy neověřil pravdivost tvrzení: "tohle nepřeháněj, nebo...".

Takže programuju v golangu, všechno v gorutinách v neomezeném počtu a na jednom serveru je těch procesů a jejich os threads mnohokrát víc, než počet jader/threads v tom CPU. A ono to prostě funguje.

[kralyk z abclinuxu]

A je potřeba tohle vůbec řešit s výjimkou velmi expertních příkladů, kde je nutné zachovat nějakou definovanou latenci?

Ano, je. 250 threadů/procesů nic není. Milion gorutin je v pohodě, protože to jsou lehké userspace thready. Milion OS threadů bude problém, protože stacky, kernel struktury a kernel context-switching...

[Heron]

Dobře, ale tohle se stane pouze v případě chyby. Nikdo normální na normální server nepustí něco, co si naspawnuje milion OS threads. Myslel jsem, že se bavíme o normálním provozu a ne nějaké neblahé události. Za normálního stavu jsem se opravdu nesetkal s tím, že by bylo potřeba omezovat alokaci stacku apod a těch vadných procesů je opravdu za těch 20 let co bych spočítal na prstech jedné ruky.

[_]

Promarnena prilezitost na lepsi jazyk je tenhle blog. Obzvlaste v dnesnim kontextu psat na CZ nepratelskym cizim jazykem je pokekud nevhodne.