3 ms·
> One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server. Probably need a better fra
by optimuspaul 8y ago
> One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server.
Probably need a better framework. I've never had such a problem come up unless I was trying to be clever and not use an established framework.
- weberc2 8y agoYou don’t understand the problem you’re criticizing. If you’re using an async web framework like aiohttp and something in the depths of one of your routes does sync IO, it will block your event loop. Nothing clever required. There isn’t a web framework that I’m aware of which magically makes all sync requests async.
- jashmatthews 8y ago> There isn’t a web framework that I’m aware of which magically makes all sync requests async. Waitress gets part of the way there. IIUC Request/response is done via asyncio but the actual web app part uses a thread so you can't accidentally block the whole thing.
- weberc2 8y agoInteresting. I wonder how it manages the threading with the GIL and all that.
- jashmatthews 8y agoThread per request works because the GIL is released during blocking IO. You only need one process per core and each process runs multiple threads. It saves a massive amount of RAM compared to trying to cram 50 (g)unicorns onto a server.
- optimuspaul 8y agoFunny that you insult me and then backup my vague comment with more specifics. My point is that you need to be aware of what is blocking all the way down, all frameworks you are using. It is possible, maybe not magical or trivial, to making everything async. Please don't assume you know what someone understands. Try asking questions when comments seem vague or stupid like mine did.