async is cool for I/O bound operations. You don't have to wait the request/response to finish in order to start processing another request.
Talking with a db, or doing http requests are IO operations, so instead of blocking the process, django can now start processing another one. When the IO operation is done, it continues where it stopped.
In python world you have few Django processes spawned by WSGI/ASGI app container, and those processes spawn python threads to handle requests. Because python uses GIL, no more than single thread is executed at single time per process. At specific times GIL stops running bytecode for one thread and moves to next one (eg when you do IO). This means other threads keep running, but in theory you can run out of threads.
In async you use tasks instead of threads for http requests, so single process can handle multiple requests at same time, only spawning threads at limited number of situations.
Yes, you can add more processes (or threads), but more processes (or threads) blocked by IO equals more context switches which equals drop in performance. Not a big deal if your app is distributed and you scale horizontally, but most apps don't need scaling that way and async fits the bill without adding unneeded resources.
If your workload is IO bound (and most of web development is) async improves performance in any case.
it would be useful if your code has to execute async code and await it's result from within a view. For example: create 10 tasks and return await asyncio.gather(*tasks) as json.
I don't know much about Python's async tools, but why couldn't that be done in a non-async view?
In pseudo code I would think it would look like this:
def my_view(request):
name = async_get_name() // returns a promise
city = async_get_city() // returns a promise
waitUntilResolved(name,city)
return HttpResponse('Hello '+name+' from '+city)
It sounds like your waitUntilResolved() function is effectively asyncio.gather(), which due to the nature of Python’s async implementation is not something that could be used in a Django view prior to this release.
Talking with a db, or doing http requests are IO operations, so instead of blocking the process, django can now start processing another one. When the IO operation is done, it continues where it stopped.