Zlý vtip menom async v djangu (pythone)

23.10.2025 15:36 | Přečteno: 1525× | Programovanie | poslední úprava: 23.10.2025 15:36

Práce na asynchronnom Djangu začali okolo roku 2020. Je rok 2025. Čo tak sa pozrieť, čo sme za tú dobu získali?

Päť rokov je v oblasti IT veľmi dlhá doba aby async prestal ignorovať aj taký technologický konzervatívec a spiatočník ako ja. Po všetkých tých fantastických blogoch a benchamrkoch som nasadol na vlnu asyncu.

Nie až tak dávno som začal nový projekt v asynchrónnom frameworku FastAPI. Nebudem rozoberať, prečo som sa rozhodol práve pre Django v úlohe ORM. Akonáhle som sa začal trocha hrabať vo vnútornostiach, šokovalo ma ako zle všetko funguje. Tento blog bude o čistom djangu.

Výkon

Blogy sľubujú výkon. Tak moje konzervatívne skostnatené ja si spustí zastaralý uWSGI a oproti tomu postavím uvicorn. Oba s jedným workerom. Môj naivný view vyzerá ako väčšina dnešných benchmarkov. Veď prečo sa pozerať na komplexnú aplikáciu keď môžeme merať nič?

from django.http.response import JsonResponse


def naive_sync(request):
    return JsonResponse({"status": "ok"})


async def naive_async(request):
    return JsonResponse({"status": "ok"})

S týmto viewom si spustím benchmark pre 10 simultánnych požiadaviek a 1000 celkovo:

ab -n 1000 -c 10 'http://127.0.0.1:8000/naive/sync/'

Výsledný graf zobrazuje synchrónne volanie v uWSGI, potom synchrónne uvicorn a asynchrónne uvicorn. Vyššie číslo udáva vyššiu priepustnosť.

Obrázok 1: Naivná implementácia

Čo sa stalo? No jednoducho v tomto príklade nemala ako vyniknúť asynchrónnosť. Okrem toho uWSGI je napísaný v C, ale oproti python implementácii je to rozdiel len 2ms na pižiadavku. Nie je to nič, čo by mi žily trhalo v reálnej aplikácii. Tento benchmark je nanič a som si toho vedomý.

Chceme ešte jeden nanič benchmark? Samozrejme! Tak teda to isté so 16 workermi.

Obrázok 2: Naivná implementácia so 16 workermi

Trocha realistickejší príklad

Väčšina aplikácií hrabe do databázy a tak si vytvorme pár tabuliek:

from django.db import models


class Author(models.Model):
    name = models.CharField(max_length=100)


class Category(models.Model):
    name = models.CharField(max_length=100)


class Document(models.Model):
    name = models.CharField(max_length=100)
    authors = models.ManyToManyField(Author, related_name='documents')
    category = models.ForeignKey(Category, on_delete=models.CASCADE, related_name='documents', null=True)

Po naplnení databázy som ešte napísal jeden synchrónny a jeden asynchrónny view.

from asgiref.sync import sync_to_async
from django.http.response import JsonResponse
from .models import Document


def db_sync(request):
    data = []
    for document in Document.objects.order_by('pk'):
        authors = []
        data.append(
            {
                "name": document.name,
                "category": document.category.name,
                "authors": authors,
            }
        )
        for author in document.authors.all():
            authors.append({"name": author.name})
    return JsonResponse({"data": data})


async def db_async(request):
    data = []
    async for document in Document.objects.order_by('pk'):
        authors = []
        data.append(
            {
                "name": document.name,
                "category": (await sync_to_async(getattr)(document, 'category')).name,
                "authors": authors,
            }
        )
        async for author in document.authors.all():
            authors.append({"name": author.name})
    return JsonResponse({"data": data})

Vytvoril som dve prakticky rovnaké funkcie líšiace sa len v dvoch detailoch. Prvým je volanie generátora for. V jednom prípade je synchrónny (for) a v druhom prípade asynchrónny (async for). No a potom je tu táto šialenosť:

(await sync_to_async(getattr)(document, 'category')).name

Python neumožňuje kombinovať synchrónne a asynchrónne funkcie. Napíšete jedinú funkciu asynchrónne a musíte prepísať všetky funkcie, ktoré ju volajú. V postate tým infikujete celý kód. Ak ste tvorcom knižnice, môžete buď napísať knižnicu syncrhónne, alebo asynchrónne, alebo oboma spôsobmi pričom každú funkciu napíšete 2x a bude sa v 99% prípadov líšiť v tomto:

# async
async def afunkcia():
   ...
   await ainafunkcia()
   ...

# sync
def funkcia():
   ...
   inafunkcia()
   ...

Django začala ako synchrónna knižnica a postupne sa duplikuje kód. Niektoré „drobnosti“ nie sú doteraz podporované ako napríklad transakcie. No a potom sú tu ešte veci, ktoré sa nedajú prepísať ako napríklad property, kde .category potrebuje zavolať SQL dotaz, ale propery nie je polymorfná a tak volá len syncrhónny select, ktorý sa nedá zavolať z asynchrónneho kontextu. Zabalíme to teda do sync_to_async

Obrázok 3: Prístup do databázy

To nie je možné!?! Dajme tam 16 workerov. Nech sa ukáže asyncrhṕnnosť.

Obrázok 4: Prístup do databázy so 16 workermi

Ešte väčšia katastrofa, čo? Rozmeňme si to na drobné. Databázový driver, ktorý django používa je synchrónny. Aj keby nebol, tak celá implementácia Djanga je hračkárska a vyzerá takto:

async def aget(self, *args, **kwargs):
    return await sync_to_async(self.get)(*args, **kwargs)

V tomto momente dochádza k prepnutiu kontextu, čo môže trvať rádovo okolo 1ms. Nie je dostatok vývojárov, aby implementovali a udržiavali Django so skoro každou duplikovanou funkciou. Preto sa len hráme na akože asynchrónnosť. Mimochodom viete, že veľa vývojárov vo svojich knižniciach overriduje save, aby tam pridali napríklad nejakú logiku, ja neviem date_created = now? Teraz to funguje pretože asave vyzerá takto: sync_to_async(self.save). Teraz si predstavte ako sa django knižnice začnú rozpadávať až sa začne reálne implementovať async. Celý ekosystém, desaťtisíce knižníc sa musia prepísať.

Nakoniec ešte doplním úpravu vďaka ktorej sa spustia len 2 dotazy namiesto 300:

def db_opt_sync(request):
    data = []
    for document in Document.objects.order_by('pk').prefetch_related('authors').select_related('category'):
        authors = []
        data.append(
            {
                "name": document.name,
                "category": document.category.name,
                "authors": authors,
            }
        )
        for author in document.authors.all():
            authors.append({"name": author.name})
    return JsonResponse({"data": data})


async def db_opt_async(request):
    data = []
    async for document in Document.objects.order_by('pk').prefetch_related('authors').select_related('category'):
        authors = []
        data.append(
            {
                "name": document.name,
                "category": (await sync_to_async(getattr)(document, 'category')).name,
                "authors": authors,
            }
        )
        async for author in document.authors.all():
            authors.append({"name": author.name})
    return JsonResponse({"data": data})

Obrázok 5: Prístup do databázy so 16 workermi po optimalizácii

Záver

Čo som vlastne chcel povedať? Neverte všetkým sladkým rečiam v blogoch. Python má svoju filozofiu „explicit is better“ a nej podriadil aj implementáciu async. Autori knižníc sa teraz musia rozhodnúť, či budú písať synchrónne, asynchrónne, alebo budú svoj kód duplikovať, budú mať 2x viac práce a 2x viac chýb. Pritom v dynamickom jazyku s tak neskorou adaptáciou async / await nebolo farbenie vôbec nevyhnutné. Škoda. Z môjho pohľadu premárnená príležitosť urobiť lepší jazyk.

       

Obrázky

Komentáře

[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š...

[Pendrekama do nich❗]

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.