5 ms·

Every request is expected to be completed in 10ms-20ms because of the nature of this benchmark test. In these cases it is unlikely you're going to beat the sche

Every request is expected to be completed in 10ms-20ms because of the nature of this benchmark test. In these cases it is unlikely you're going to beat the scheduling overhead to make async worth it. However, if 10% of your requests take 10s, your 16 workers are very soon going to become 16 stuck workers and you won't be able to fulfill any new requests. This is the problem that async solves. You shouldn't use a fire hose to water your plants but you also shouldn't use a sprinkler system to put out a fire.

omega3 5y ago
You might want to use a different analogy: https://en.wikipedia.org/wiki/Fire_sprinkler_system https://en.wikipedia.org/wiki/Fire_sprinkler_system
- huntertwo 5y ago
  /facepalm
- remram 5y ago
  It seems exactly backwards
rebelcoder 5y ago
This should be obvious to most people agreeing with the article, and I came here to say what you just said. I use async in a webserver environment only, where it does shine, and I use Celery + Rabbit for synchronous tasks (executed asynchronously via webserver). As long as I keep my async code on the webserver end, and my sync code elsewhere, the project seems to stay organized well. Otherwise, I tend to lose sight of proper naming, etc.
aenis 5y ago
Very much this. I run prod workloads with async python and indeed when you have some external I/O that can take a long time to complete - async fixes that. One of my systems does around 8 api calls to service a request. It serves 80,000 daily users generating close to 2,000,000 expensive api calls and typically thats served by a single node running on a 2 core cpu. Gunicorn/starlette/fastapi. The real problem with async in python is how easy it is to break it by introducing code or dependency that hogs the cpu every now and then. This usually means debugging weird timeouts that only happen every few days and are super hard to trace. Not sure I'd like to do async python again but it sure is efficient for I/O heavy workloads.

omega3 5y ago

You might want to use a different analogy: https://en.wikipedia.org/wiki/Fire_sprinkler_system https://en.wikipedia.org/wiki/Fire_sprinkler_system

huntertwo 5y ago
/facepalm
remram 5y ago
It seems exactly backwards

rebelcoder 5y ago

This should be obvious to most people agreeing with the article, and I came here to say what you just said. I use async in a webserver environment only, where it does shine, and I use Celery + Rabbit for synchronous tasks (executed asynchronously via webserver). As long as I keep my async code on the webserver end, and my sync code elsewhere, the project seems to stay organized well. Otherwise, I tend to lose sight of proper naming, etc.

aenis 5y ago

Very much this. I run prod workloads with async python and indeed when you have some external I/O that can take a long time to complete - async fixes that. One of my systems does around 8 api calls to service a request. It serves 80,000 daily users generating close to 2,000,000 expensive api calls and typically thats served by a single node running on a 2 core cpu. Gunicorn/starlette/fastapi. The real problem with async in python is how easy it is to break it by introducing code or dependency that hogs the cpu every now and then. This usually means debugging weird timeouts that only happen every few days and are super hard to trace. Not sure I'd like to do async python again but it sure is efficient for I/O heavy workloads.