ERP Nightly Batch Job Parallelism and Runtime Calculator
Adding threads to a nightly ERP batch helps until the serial part and contention take over. This calculator applies Amdahl's law with a contention term to show the expected runtime, the point of diminishing returns and whether you fit your batch window.
Your numbers
How long the batch runs with one thread or one worker.
Steps that cannot be split: initial load, locking steps, final posting, file generation.
Batch servers, processes, MRP workers or job streams.
Lock waits, I/O queueing and coordination, per additional thread.
Your results
A two-parameter model for planning. Measure real runtime at two or three thread counts and fit the serial share and contention to your results before changing production schedules.
Batch runtime (hours) versus parallel threads
Sweeps Parallel threads from 1 to 32, holding your other inputs fixed.
Batch window review
Optional: send us your job chain timings and we will point out the serial steps and the best candidates to parallelize.
Optional. The tool and every export work without this. No spam.
How to use it
Enter how long the batch takes on a single worker, and the share that must run serially: initial selection, single-threaded posting, locking steps, final reports. If you are unsure, run the job at two thread counts and solve for the serial share. Add a small contention percentage for each extra thread, which represents locks and shared storage. Then compare the expected runtime and headroom against your window and see the curve on the chart.
- Measure the serial share from real runs, not guesses
- Treat contention as the cost of each extra thread
- Watch the minimum point on the chart
The formula
Amdahl's law says runtime equals single-thread time times the serial fraction plus the parallel fraction divided by threads. With a serial share of 15 percent, even infinite threads cap the speedup at about 6.7 times. The contention term multiplies the result by one plus the overhead per extra thread, which makes the curve turn upward past some thread count. That turning point is the useful limit for your environment.
Worked example
An 8 hour single-thread batch with a 15 percent serial share and 2 percent contention per thread, run on 8 threads, has an ideal runtime of 1.8 hours. Contention raises it to about 2.1 hours, a 3.8 times speedup at 48 percent efficiency. Going to 16 threads gives a worse result near 2.2 hours, because contention outweighs the parallel gain. Reducing the serial share is worth more than adding threads.
Common mistakes
Teams add servers without checking that the database or the lock manager is the real bottleneck. Another is splitting work unevenly so one thread runs far longer than the rest, which behaves like a larger serial share. Check how the job divides work, for example by site, warehouse or item range, and balance the streams.
Frequently Asked Questions
What serial share should I assume?
Start with 10 to 20 percent for typical ERP batch chains and then measure. Time the job at one and four threads, and solve Amdahl's law for the serial fraction. The measured figure beats any default, and it changes after tuning or data growth.
Why does adding threads make it slower?
Extra threads compete for locks, I/O, memory and the database log. Past a certain point the coordination cost outweighs the extra processing. The chart shows this as a curve that bottoms out and rises again.
Is this valid for MRP and costing runs?
It is a good first model for any job that can be split by key range, such as MRP by level, costing by site or posting by company. Jobs with strict dependency chains behave like a larger serial share.
How do I reduce the serial share?
Move preparation and cleanup steps out of the critical path, replace single-row loops with set-based work, split final posting by company or ledger, and run reports after the window. Each removed serial minute is worth more than adding a thread.
If your batch window keeps slipping, we can profile the job chain read-only and show which steps are serial or blocking.
Related Tools
D365 Batch Job Window and Runtime Calculator
Estimate how long a D365 F&O batch job will take for a given record volume and thread count, and whether it fits the nightly window.
Developer ToolsSQL Server Transaction Log Sizing Calculator
Work out how large the transaction log of an ERP database should be, and how log backup frequency changes it.
Developer ToolsERP Incremental Extract Watermark SQL Generator
Generate a T-SQL script that pulls only new and changed ERP rows using a watermark control table.
Developer ToolsSQL Query Performance Tuning Log Worksheet
An editable log of slow ERP queries with before and after timings that computes percent improvement and CPU hours saved per day.