I spent some time today running performance numbers with various parts of the async stack loaded in.
My main concern is the speed impact we make on synchronous Django when this code lands - I don’t want sites that only use sync code to see a serious performance impact.
Sadly, right now we’re seeing a 10x performance slowdown on the request processing (from 0.6ms to 6ms). I did some playing around and the lowest we can possibly get for this (i.e. the cost of instantiating an event loop at all) is 0.8ms, which is not a huge increase and acceptable if we get down to it.
This is going to need some modification of
asgiref and the complex code around threadlocals; now we have the ability to run sync code in the same thread as other sync code, a lot of it can likely be thrown away and replaced just with a safety catch that makes sure you don’t call them from async threads.
Otherwise, there’s the chance we’ll have to maintain two request paths in
BaseHandler - one sync and one async. It’s not a huge amount of code, but it would be nice to avoid this.