this post was submitted on 07 Oct 2023
9 points (100.0% liked)

Django

417 readers
3 users here now

Django Project

Django Community

Django Ecosystem

Jobs
Learning/Docs
Podcasts:
Related Fediverse communities
Feeds

founded 1 year ago
MODERATORS
jnovinger
jsalvador
norambna
9
What's your experience with async Django? (lemm.ee)
submitted 1 year ago by [email protected] to c/django
3 comments fedilink hide all child comments
 

I'm curious to know how folks use async Djagno in production. Have you switched a project over? Fully or critical code only? What was your experience like? Was it worth it?

I made an example app to demonstrate superiority in a confined test. I've found it quite awkward converting existing sync views to async. Fetching a limited queryset for json serialization is awkward [x async for x in values]. Some ORM functions, like get_or_create, appear to be just wrappers that call sync_to_async. Django Rest Framework doesn't support async and adrf doesn't support everything.

you are viewing a single comment's thread
view the rest of the comments
[–] __init__ 2 points 1 year ago (1 children)

I don’t think anything in the Django ORM is truly async yet, they only just finalized the async API, but the implementations of those APIs are just sync_to_async under the hood for the moment.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

The linked example repo would suggest some part of it is indeed async. At least with psycopg 3 and postgres. The async version is able to serve multiple concurrent requests that make database calls. It uses just one worker. The sync version just hangs loading one request at a time.

*edit looking at the source more, yes everything seems to use sync_to_async under the hood. I wonder if the observed performance improvement is just something small like the database connection being async.

[–] __init__ 1 points 1 year ago

I didn’t look super closely at the example app, but it looks like it is comparing a sync vs async view? Or wsgi vs asgi? I think even with a single wsgi worker running sync code you should be able to handle more than one request at once if they’re IO bound (e.g. waiting on db queries), since each request runs in its own thread. Although that might still require using a different kind of gunicorn worker to make it use a thread per request like that.

To answer your original question, we “sort of” use async in production, but only by using asgi and the uvicorn worker class. All of our view/orm code is sync still. We do not get a very large volume of requests at all but I haven’t seen any performance issues due to concurrent or long-running requests using this setup for a few years now.