Severely degraded performance under ASGI compared to the typical WSGI deployment pattern

[Ryan Henning]

For projects that are deployed under ASGI and have synchronous views (and/or synchronous middleware), a single Django process can only handle one request at a time. Stated another way, there is no way to allow concurrency and handle multiple synchronous requests in parallel.

This is degraded performance compared to the old-style WSGI deployments where solutions such as gevent or gthreads (via gunicorn) can handle concurrent requests from a single process. With Django and the new ASGI spec, your hands are tied because these options are not available anymore.

Applications that are impacted are those where each request does one or more ORM operation, thus views are synchronous, and each request blocks for some amount of time waiting on the database, and (while one request is blocked) all other requests must wait in the wings. People love the Django ORM so this is a common type of application. The only solution is to deploy tons of processes, which consume tons memory on the host OS and quickly becomes not-a-solution.

I'm a big fan of ASGI (we use channels extensively), but this is a disincentive for ASGI adoption.

Django 4.x has a solution, see #32889 (also #33157).

[Carlton Gibson]

Hi Ryan — sorry, this is just the same request as #33157.

The use of ThreadSensitiveContex from #32889 doesn't qualify for a backport. The bottom line is we don't backport arbitrary new features into released versions of Django. That does mean that folks need to upgrade to get the benefits of new features (which is the negative) but it's also a large part of why Django is so stable and reliable (the pro). On balance it's not worth the regression risk, and so the backport policy is as it is. I hope that makes sense.

In any case the fix from #32889 is not compatible with the Python support matrix of 3.2.

[Ryan Henning]

In any case the fix from #32889 is not compatible with the Python support matrix of 3.2.

Django 3.2 depends on asgiref 3.3.2 which has ThreadSensitiveContex and support for Python 3.6 - 3.9. Therefore, there is no issue with the Python support matrix for Django 3.2. I make this final point only in case it affects your stance (it's good to have all the info). I respect your decision regardless.

The bottom line is we don't backport arbitrary new features into released versions of Django.

I am not arguing for arbitrary features. Rather, this is a specific feature for which I've stated my reasons above. Thank you for considering my reasons. I'll rest my case.

[Claude Paroz]

It's a matter of rules and breaking rules. You have to set rules if you want to collaborate peacefully on a project. Then you find at times that some rule is not always appropriate to some issue. Some think you should never break the rules, even if it's partly detrimental to the ultimate goal, fearing that if you break once, you don't know when to stop. Others think that the ultimate goal is greater than the rules, and allow for breaking them in certain circumstances. Even if I picked my side, I don't judge one way better than the other.

That was my philosophical minute of the month :-)