NetSuiteFree calculatorPDF, Excel, Word exportNetSuite

NetSuite Map/Reduce Parallelism Throughput Calculator

Map/reduce lets NetSuite run your code in parallel, but raising the concurrency setting does not always make a job proportionally faster. This tool shows where the returns diminish.

Your numbers

Items in the map stage

items

Concurrency set on deployment

5 processes

Share of processors you actually get

60 %

Other scripts in the queue compete for the same processors.

Seconds per item

seconds

Fixed overhead for stages

minutes

getInputData, summarize and queue start time.

Your results

Map stage time

222.2 min

Total elapsed estimate

225.2 min

Effective processes

Time if run serially

666.7 min

Speed-up vs serial

2.96

Parallel efficiency

98.7%

Lower means overhead is eating the benefit.

Real map/reduce runtimes also depend on yielding, script governance and how work is distributed across keys. Use this to compare options, then measure on realistic data in a sandbox.

Save results:

Total minutes vs configured concurrency

Sweeps Concurrency set on deployment from 1 to 20, holding your other inputs fixed.

Map/reduce design review

Optional: have a developer review your key design and stage split.

Optional. The tool and every export work without this. No spam.

How to use it

Enter the number of items the getInputData stage returns, the concurrency you configure on the script deployment, and the time one map invocation takes. The share slider represents the fraction of those processors you realistically receive when other scripts are queued. The fixed overhead covers the stages that do not parallelise. The output shows effective processes, map stage time, total elapsed time, speed-up and efficiency.

The model

Effective processes equal the configured value multiplied by your share, rounded down and never below one. Map time equals items divided by effective processes, rounded up, multiplied by the time per item. Adding the fixed overhead gives total time, and dividing the serial time by that total gives the speed-up. This is Amdahl's law in simple form: the fixed overhead puts a ceiling on gains regardless of how many processes you request.

Effective = floor(configured x share)
Map time = ceil(items / effective) x seconds per item
Speed-up = serial time / total time
Efficiency = speed-up / effective processes

Reading the result

Efficiency above about 80 percent means extra processes are well spent. When efficiency falls below 50 percent, the fixed overhead or the share you receive is the bottleneck, and more concurrency only reserves capacity other scripts could use. If speed-up is close to the effective process count, your work distributes evenly. If the real runtime is far worse, check for a hot key where one reduce key holds most of the work.

Common mistakes

People often assume that setting 20 processes guarantees 20 workers. Processors are shared across the account and scheduled by priority, so a busy account may give you a few. A second mistake is a skewed key design, where a single reduce key receives a very large list. A third is heavy work in getInputData or summarize, which runs unparallelised.

Keep map work independent and idempotent
Avoid one huge key in the reduce stage
Move heavy setup out of getInputData where possible
Test at off-peak and peak to see your real share

Frequently Asked Questions

Does more concurrency always help?

No. Gains stop when other scripts compete for processors, when fixed stages dominate, or when work is skewed to a few keys. Use the efficiency output to see when to stop adding processes.

Where is concurrency set?

On the script deployment record, where you choose the number of processors the deployment may use. The actual number you receive also depends on account-level processor availability and queue priority.

How do I estimate seconds per item?

Run a sample of a few hundred items in a sandbox and divide the map stage duration from the execution log by the item count. Do this at a normal data size rather than with an empty account.

Is map/reduce better than a scheduled script?

For large independent workloads, usually yes, because it distributes work and restarts failed items. For small jobs with strict ordering, a scheduled script is simpler and has less overhead.

If a nightly map/reduce is slow or unpredictable, Netray can review its design and the account processor contention.

Talk to an Expert Explore More Free Tools

Related Tools

NetSuite

More NetSuite tools

See all

Back to All Tools