danidee10
Refactor database layer: replace psycopg3 queries with Django ORM asy…
Just adding my 2c here, we recently re-implemented this library and we went with ORM queries as well in the first place, but they were significantly slower than have a dedication psycopg async connection, as with the ORM implementation you're constantly waiting on the main thread for queries.
This was just our experience though, YMMV.
The Django ORM async interface relies on asgiref.sync_to_async, for example: https://github.com/django/django/blob/05ba1a9228128614fb3c475f1c4bdf0160f44dba/django/db/models/query.py#L1412. From the Django doc (https://docs.djangoproject.com/en/5.2/topics/async/#sync-to-async):
The reason [thread_sensitive=True] is needed in Django is that many libraries, specifically database adapters, require that they are accessed in the same thread that they were created in. Also a lot of existing Django code assumes it all runs in the same thread, e.g. middleware adding things to a request for later use in views.
This means that the main Django thread (usually started by an asgi server), which is a blocking thread, will be waited on to perform database queries. Hence, you reduce the throughput of channels-postgres because you're limited by the availability of the connection from the main thread.
I assumed it would be slightly slower due to the translation from ORM to SQL but I wasn't aware of sync_to_async was such a bottleneck. This is a blocker @Demagalawrence
I don't see how we can merge it if it causes a big drop in performance. In the meantime, I'll focus on building a benchmark so we have a clearer picture on the performance.
Yeah I'm sorry I don't have a number, it just felt slower. This is definitely a "feeling" assessment, but it makes sense.
Thanks for clarifying — that makes sense. I understand ORM async may reduce throughput. I’ll wait for your benchmark results. hmmmm i have understood something too , thank you so much