id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
33158	Severely degraded performance under ASGI compared to the typical WSGI deployment pattern	Ryan Henning	nobody	"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)."	Cleanup/optimization	closed	HTTP handling	3.2	Normal	duplicate			Unreviewed	0	0	0	0	0	0