Batch Window Planner
Converts a volume and a deadline into the throughput and worker count that make it, with the setup time and the safety margin counted.
Your 60 workers finish in 10.7 h — 4.7 h past the deadline.
- Usable window after setup
- 5.8 h
- Required throughput
- 95.2 items/s
- Required throughput, per minute
- 5,714 items/min
- One worker delivers
- 1.25 items/s
- Workers at 100% utilisation
- 76.2
- Workers at 70% utilisation
- 109
- Throughput of the planned fleet
- 52.5 items/s
- Finish time
- 10.7 h
- Slack against the deadline
- −4.7 h
Why the required number is the one with headroom in it
The arithmetic of a batch window is simple enough to do in your head and it is still worth writing down, because the naive version leaves out the two terms that make jobs miss deadlines. Items divided by the window gives a required rate. Service time inverted gives a per-worker rate. Divide one by the other and you have the number of workers — at which point people provision exactly that many and are surprised when it does not finish.
The first missing term is the usable window, which is shorter than the window. Spin-up, model loading, the first-request penalty on a cold pool, and the final write all come out of it, and on a six-hour window a ten-minute overhead is 3% of your capacity gone before an item is processed.
The second is utilisation. Planning at 100% of theoretical throughput means every provider slowdown, every retry and every straggler eats directly into the deadline, because there is nowhere for the lost time to go. Planning at 70% costs 43% more workers and turns a missed deadline into a late finish. This is the same trade as a queueing system running hot — the closer to saturation you plan, the more violently small perturbations move the finish time. If the workers are rented by the hour the extra ones cost nothing extra overall: the same total work over a shorter time. The headroom is close to free, which is why it is odd how rarely it is bought.