[halifaxbeard]

It’s been my experience that async Python frameworks tend to turn IO bound problems into CPU bound problems with a high enough request rate, because due to their nature they act as unbounded queues.

This ends up made worse if you’re using sync routes.

If you’re constrained on a resource such as a database connection pool, your framework will continue to pull http requests off the wire that a sane client will cancel and retry due to timeouts because it takes too long to get a connection out of the pool. Since there isn’t a straightforward way to cancel the execution of a route handler in every Python http framework I’ve seen exhibit this problem, the problem quickly snowballs.

This is an issue with fastapi, too- https://github.com/tiangolo/fastapi/issues/5759

[adeelk93]

The solution mentioned in the issue is the same one I use, `run_in_threadpool`. Does that not work for you?

[scriptr]

Threadpools incur high overhead but that should work mostly.

Also, in Litestar Sync is a first class citizen just as much as async is.

You can see in benchmarks (that shouldnt be taken as gospel) how frameworks drop off in sync perf., where Litestar maintains both well.

https://docs.litestar.dev/latest/benchmarks.html