4 ms·

"When you don't need it" If you're doing any kind of database / external network calls - won't you gain a huge amount of requests per second? I ask partly bec

"When you don't need it" If you're doing any kind of database / external network calls - won't you gain a huge amount of requests per second? I ask partly because on one of my projects, we have a fastapi app, but it's not using async, and I have been toying with the idea of converting it to async. It will take some work though because it uses libs that don't support async. I thought the advantages would be worth it because we hit postgres and/or redis on all requests.

mattclarkdotnet 4y ago
Why not run multiple processes? This has been the way for over 20 years.
- smackeyacky 4y ago
  Green Unicorn and the like do this and do it very well.
digisign 4y ago
The usecase for async is spidering web pages or keeping a thousand chat sockets up, not for talking to a local database.
aeyes 4y ago
> If you're doing any kind of database / external network calls - won't you gain a huge amount of requests per second? Only if they can be parallelized. I'm not sure if I would choose Flask if I had such a complex application.
floober 4y ago
Flask is a multi-threaded server, so while only one thread can execute Python code at a time (due to the GIL), you still get concurrency with respect to IO. Not to say that e.g. FastAPI won't get you more RPS, but it may or may not be as dramatic as you would expect.
323 4y ago
I think I'm in a similar situation with you, and asyncio has been great. Not sure what libs you use, you'll probably need to switch libraries, it's not common for one lib to support both sync/async. I'm using aiohttp for http/websockets and asyncpg for postgres, running on uvloop as the base event loop. Something which is trivial with asyncio: I receive 10 consecutive heavy websockets requests, I spawn a task to handle each one of them and they will be served back out of order as Postgres returns results. With no locking or messing with threads. Another benefit is knowing for certain your code won't be interrupted unless you call "await", this simplifies a lot using shared state without requiring locks.
ekimekim 4y ago
Flask has historically been used in combination with gevent/eventlet which are greenthreaded async frameworks that predate python's async/await support. These still work and are still a great choice for an async server with many concurrent requests. The big downside is just lack of compatability with the new async ecosystem.
kissgyorgy 4y ago
The only reasonable use case for asyncio is an API gateway or similar, when you issue a huge amount of HTTP requests, do very little CPU intensive tasks and waiting for I/O all the time. Any other use-case you are better off going with the simplicity of a sync framework like Flask. For databases you are way worse with async, see why from the Python database god himself: https://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/ https://techspot.zzzeek.org/2015/02/15/asynchronous-python-a...

mattclarkdotnet 4y ago

Why not run multiple processes? This has been the way for over 20 years.

smackeyacky 4y ago
Green Unicorn and the like do this and do it very well.

digisign 4y ago

The usecase for async is spidering web pages or keeping a thousand chat sockets up, not for talking to a local database.

aeyes 4y ago

> If you're doing any kind of database / external network calls - won't you gain a huge amount of requests per second? Only if they can be parallelized. I'm not sure if I would choose Flask if I had such a complex application.

floober 4y ago

Flask is a multi-threaded server, so while only one thread can execute Python code at a time (due to the GIL), you still get concurrency with respect to IO. Not to say that e.g. FastAPI won't get you more RPS, but it may or may not be as dramatic as you would expect.

323 4y ago

I think I'm in a similar situation with you, and asyncio has been great. Not sure what libs you use, you'll probably need to switch libraries, it's not common for one lib to support both sync/async. I'm using aiohttp for http/websockets and asyncpg for postgres, running on uvloop as the base event loop. Something which is trivial with asyncio: I receive 10 consecutive heavy websockets requests, I spawn a task to handle each one of them and they will be served back out of order as Postgres returns results. With no locking or messing with threads. Another benefit is knowing for certain your code won't be interrupted unless you call "await", this simplifies a lot using shared state without requiring locks.

ekimekim 4y ago

Flask has historically been used in combination with gevent/eventlet which are greenthreaded async frameworks that predate python's async/await support. These still work and are still a great choice for an async server with many concurrent requests. The big downside is just lack of compatability with the new async ecosystem.

kissgyorgy 4y ago

The only reasonable use case for asyncio is an API gateway or similar, when you issue a huge amount of HTTP requests, do very little CPU intensive tasks and waiting for I/O all the time. Any other use-case you are better off going with the simplicity of a sync framework like Flask. For databases you are way worse with async, see why from the Python database god himself: https://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/ https://techspot.zzzeek.org/2015/02/15/asynchronous-python-a...