3 ms·

EDIT: 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 performa

by dotdi 6y ago

EDIT: 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.

pluies 6y ago
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.
calpaterson 6y ago
> Maybe I'm misunderstanding something here, but why is the author benching sync frameworks with 16 workers vs async frameworks with ~5? Hi - that is explained in some detail in the article
martius 6y ago
What matters is that the server app uses as much CPU as it can when it needs it. With a sync server, a worker is inactive as long as it is waiting on IO, so you need enough workers to maximize the chance that all workers are busy, else, some clients are waiting even if you've got the CPU to deal with them. With an async server, a single worker handles many clients simultaneously, in theory, a single worker per core is sufficient to eat all the CPU available.
- jordic 6y ago
  with asyncio we deploy a thread per worker (loop), and a worker per core. We also move cpu bound functions to a thread pool
deleted 6y ago
[deleted]

by dotdi 6y ago

pluies 6y ago

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.

calpaterson 6y ago

> Maybe I'm misunderstanding something here, but why is the author benching sync frameworks with 16 workers vs async frameworks with ~5? Hi - that is explained in some detail in the article

martius 6y ago

What matters is that the server app uses as much CPU as it can when it needs it. With a sync server, a worker is inactive as long as it is waiting on IO, so you need enough workers to maximize the chance that all workers are busy, else, some clients are waiting even if you've got the CPU to deal with them. With an async server, a single worker handles many clients simultaneously, in theory, a single worker per core is sufficient to eat all the CPU available.

jordic 6y ago
with asyncio we deploy a thread per worker (loop), and a worker per core. We also move cpu bound functions to a thread pool

deleted 6y ago

[deleted]