Hi!
I have posted a topic in the “Show and Tell” section, but I think it probably belongs more here, because it is about using async views and why they do not perform better than normal sync views.
Maybe someone with async Django knowledge can help?
→ Evaluation of performance of async views - they suck?
Is a link to the other post ok, or should I delete the other post and post it here again?
Thanks for your help,
Anton
As a non-admin-but-regular-user here, I personally don’t pay too much attention to the categories. This forum isn’t so busy that I can’t keep up with reading pretty much everything by just monitoring the “Latest” view.
Sorry I can’t help with the original problem, however I do find it intriguing enough that if I get some time, I’d like to see if I can replicate your results on one of my servers.
I didn’t look into the details of your view code but, in general, until the ORM is async aware we’re forced to run sync_to_async with the thread_sensitive=True flag. This means that in Django 3.x, ASGIHandler is limited by the requirement to keep database operations in a single thread.
From Django 4.0 we’ll have a per-request context, allowing one thread per-request, which should see significant gains.
There’s no guarantee that this will (at this stage) make using an ASGI server faster than using WSGI — you’re contrasting battle-hardened mature tech with something very new, for which folks — even the “experts” — are still learning the patterns. That a particular example shows a WSGI setup with higher throughput is not surprising. I think the advice is/remains that you should use async for specific tasks where there’s an identifiable gain.
Working example:
Intro: Introduction to async views in Django | async/await in Django views - YouTube
Working example with measurement: How to improve the performance in Django apps with ASYNC views - YouTube