I read the article, thanks. I think you've missed my point. I'll TL;DR it for you to make it clearer:
> This article doesn't evaluate the case that you actually want ASGI for, so I don't think it's very useful.
> The standard usecase of a sync API backed by a local DB with low request latency is typically going to be compute-bound.
(Note, I'm specifically talking about Django here)
> Essentially, there's no reason to use Django async if you're doing a traditional monolithic DB-backed application. It's going to give you benefits in usecases where the standard sync model struggles.
My claim is that these benchmarks are not looking at the use-case that Django async is intended to solve. It's not about increasing throughput to your local DB, and so it's not surprising that you don't see an improvement in benchmarks testing that case. Django's async is intended to enable API-gateways and other long-running requests where the upstream latency can be long enough to starve your API worker threads.
Regarding compute-bound vs. I/O-bound, I'm sure YMMV, but my APM tracing for a mature non-trivial production Django API shows that waiting on the DB accounts for about 25% of the total request time across all my endpoints.
Serialization/deserialization takes an embarrassing amount of time in Django, see https://news.ycombinator.com/item?id=24161828 for example. This framework is optimized for developer productivity, not for performance.
