Async Python is not faster
calpaterson.com
Async Python is not faster
1–10 of 364 posts
Re: Async Python is not faster
#2Cooperative multitasking came out slower than preemptive in the nineties, so this is unsurprising in the generic case.
I think my question is whether async Python is slower in the case it was designed for -- many, long-running open sockets.
Async was traditionally used server-side for things like chat servers, where I might have millions of sockets simultaneously open.
Re: Async Python is not faster
#3I would be really interested in seeing some numbers on how long the async code spends before each yield.
Re: Async Python is not faster
#4Is speed really a good reason for using async? If I remember correctly, asynchronous I/O was introduced to deal with many concurrent clients.
Therefore, I would have liked to see how much memory all those workers use, and how many concurrent connections they can handle.
Re: Async Python is not faster
#5Is speed really a good reason for using async? If I remember correctly, asynchronous I/O was introduced to deal with many concurrent clients. Therefore, I would have liked to see how much memory all those workers use, and how many concurrent connections they can handle.
same.
maybe author is concerned that many people are jumping the gun on async-await before we all fully understand why we need it at all. and that's true. but that paradigm was introduced (borrowed) to solve a completely different issue.
i would love to see how many concurrent connections those sync processes handle.
Re: Async Python is not faster
#6Not surprised. The bottleneck in Python tends to be the Global Interpreter Lock. That's also why multithreading only rarely helps and why people attempt multi-process execution instead.
But Python is an excellent language for quick prototyping and for controlling other things, like coordinating GPUs who do the actual compute work. So I don't quite get why we need to make Python usable for Webservers, when we already have other languages optimized for that purpose, e.g. Google's Go.
Re: Async Python is not faster
#7Is speed really a good reason for using async? If I remember correctly, asynchronous I/O was introduced to deal with many concurrent clients. Therefore, I would have liked to see how much memory all those workers use, and how many concurrent connections they can handle.
I think speed is the wrong word here. A better word is throughput.
The underlying issue with python is that it does not support threading well (due to the global interpreter lock) and mostly handles concurrency by forking processes instead. The traditional way of improving throughput is having more processes, which is expensive (e.g. you need more memory). This is a common pattern with other languages like ruby, php, etc.
Other languages use green threads / co-routines to implement async behavior and enable a single thread to handle multiple connections. On paper this should work in python as well except it has a few bottlenecks that the article outlines that result in throughput being somewhat worse than multi process & synchronous versions.
Re: Async Python is not faster
#8EDIT: Read the article again, cleared up why the worker count differs.
Anyway, I'm running quite a few small Python services on cheap VPSs, i.e., shit performance, and using async was beneficial for me, with performance being ~30% better. They are bread-and-butter apps that read from Postgres, do some HTTP requests, process the results, and potentially write stuff back to the DB. Same performance gain for other services that have HTTP servers.
In my mind, hardware can be used more efficiently with async, since while one routine is waiting for an async result, other routines can run meanwhile.
Re: Async Python is not faster
#9Cooperative multitasking came out slower than preemptive in the nineties, so this is unsurprising in the generic case. I think my question is whether async Python is slower in the case it was designed for -- many, long-running open sockets. Async was traditionally used server-side for things like chat servers, where I might have millions of sockets simultaneously open.
Yes, the whole hoopla about async and particularly async/await has been a bit puzzling, to say the least.
Except for a few very special cases, it is perfectly fine to block on I/O. Operating systems have been heavily optimized to make synchronous I/O fast, and can also spare the threads to do this.
Certainly in client applications, where the amount of separate I/O that can be usefully accomplished is limited, far below any limits imposed by kernel threads.
Where it might make sense is servers with an insane number of connections, each with fairly low load, i.e. mostly idle, and even in server tasks quality of implementation appears to far outweigh whether the server is synchronous or asynchronous (see attempts to build web servers with Apple's GCD).
For lots of connections actually under load, you are going to run out of actual CPU and I/O capacity to serve those threads long before you run out of threads.
Which leaves the case of JavaScript being single threaded, which admittedly is a large special case, but no reason for other systems that are not so constrained to follow suit.
Re: Async Python is not faster
#10EDIT: Read the article again, cleared up why the worker count differs. Anyway, I'm running quite a few small Python services on cheap VPSs, i.e., shit performance, and using async was beneficial for me, with performance being ~30% better. They are bread-and-butter apps that read from Postgres, do some HTTP requests, process the results, and potentially write stuff back to the DB. Same performance gain for other servi…
From the article:
> Why the worker count varies
> The rule I used for deciding on what the optimal number of worker processes was is simple: for each framework I started at a single worker and increased the worker count successively until performance got worse.
> The optimal number of workers varies between async and sync frameworks and the reasons are straightforward. Async frameworks, due to their IO concurrency, are able to saturate a single CPU with a single worker process.
> The same is not true of sync workers: when they do IO they will block until the IO is finished. Consequently they need to have enough workers to ensure that all CPU cores are always in full use when under load.