Batch throughput calculator

It reports items per second, minute, and hour, then optionally compares that capacity with a target. When you provide a target rate, it calculates the minimum whole-item batch size needed at the current processing time and the longest interval your current batch can tolerate. This makes capacity assumptions explicit before you tune workers, queue consumers, imports, inference jobs, or scheduled bulk operations.

Translate batch behavior into a comparable rate

Batch systems are often described with two numbers that are difficult to compare directly: how many items a run handles and how long that run takes. The calculator divides batch size by batch time to produce effective throughput in items per second, then expands the same rate into items per minute and hour. For example, a worker that completes 500 items every 20 seconds sustains 25 items per second, assuming it can begin the next batch without additional delay. Use elapsed launch-to-launch time when setup, polling, cooldown, or queue delay belongs in your real operating cycle. Use measured processing time only when those delays are handled elsewhere and you intentionally want compute-stage capacity. The result is an average rate, not a claim that individual items finish evenly throughout the interval. A batch may release all of its results at once while still having the reported long-run throughput. Keeping that distinction clear helps compare batch consumers with streaming workers without confusing delivery latency and processing capacity.

Plan a batch size for a target throughput

Add a target rate in items per second when you need to know whether the current configuration can keep up with arrivals or a service objective. The calculator multiplies the target by the current batch time and rounds upward to the next whole item. Rounding up is essential because a fractional item cannot be added to a batch, and rounding down would quietly produce less capacity than requested. The result called required batch size therefore represents the smallest integer batch that reaches or exceeds the target while processing time stays unchanged. The accompanying resulting rate shows the small amount of excess capacity that integer rounding may introduce. This scenario assumes that increasing the batch size does not increase processing time. That can be a useful first estimate, but real databases, APIs, memory limits, and parallel workers may scale nonlinearly. After choosing a candidate, benchmark it with representative payloads and feed the measured interval back into the calculator. Repeating that loop replaces an optimistic sizing assumption with evidence from the actual system.

Find the interval allowed by an existing batch

Sometimes batch size cannot change because an upstream API, transaction limit, memory budget, or message broker sets a hard ceiling. In that case, the target analysis also calculates the maximum batch time permitted at the current size. It divides the current number of items by the target items per second. A 600-item batch serving a 40-item-per-second target, for example, must complete on a launch-to-launch interval of 15 seconds or less. Compare that threshold with measured high-percentile timing rather than only the fastest or average run. If ordinary variation pushes batches beyond the threshold, the nominal configuration may meet the target while the production queue still grows. The rate ratio provides another compact planning signal: values above one indicate capacity greater than the target, one means exact equality, and values below one show a deficit. The model assumes batches run sequentially as one effective lane. For several identical concurrent workers, calculate the observed combined batch size over a shared interval, or calculate each lane separately and add their sustainable rates only when work distribution is balanced.