Worker Process Count Calculator

Work out worker process count instantly with clear inputs, formula shown and shareable results.

About Worker Process Count Calculator

For CPU-bound work, workers should roughly match cores. For I/O-bound work, each worker is blocked most of the time, so the useful count scales as cores divided by (1 - I/O fraction) — 8 cores at 65 percent I/O wait supports about 22 workers. Memory then caps it, and the binding constraint tells you which resource to buy.

Formula

Worker count

CPU limit = cores / (1 - I/O wait fraction); memory limit = available memory / per-worker memory; workers = min of the two

Worked example

With the default values below, Worker Process Count Calculator returns Recommended worker count of 22. Change any input above and every figure here is recalculated in your browser.

Inputs used

CPU cores availableminimum 1: 8
Share of request time spent waiting on I/Oaccepts 0–99 %: 65 %
Memory per workerminimum 1 MB: 220 MB
Memory availableminimum 1 MB: 7,168 MB

Results

Recommended worker count: 22
Limit from CPU and I/O profile: 22
Limit from available memory: 32
Binding constraint: CPU and I/O profile

Step by step

1Values used
2Worker count
3Recommended worker count= 22
4Limit from CPU and I/O profile= 22
5Limit from available memory= 32
6Binding constraint= CPU and I/O profile

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to whole numbers, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why not just run many workers?

Each process costs memory and adds context switching. Past the point where cores are saturated, more workers increase latency without increasing throughput.

Do threads change the arithmetic?

Threads are cheaper in memory, so the memory limit relaxes, but the CPU relationship is the same. For very high I/O concurrency, async event loops avoid per-connection cost entirely.