Ok, I'm curious, script performance nerds. How long should it take a map /reduce script to create 10,000 invoices? How about 30,000? 50,000? I'm trying to set a proper benchmark. Assume the average invoice has 5 lines, and there only a few large ones, and none over 500. You can assume 1 SCP (so 5 queues), no UEs or workflows, no GL plugins, no other junk. Put it another way: How long should it take an efficiently built M/R to save a single invoice record, and how does that number change as we scale up?

First, how many SC+ licenses do you have, and how many queues is the Map/Reduce configured to use? That can make the biggest difference in time. Creating any transactions is likely to to come with its own set of performance concerns. Transactions may have GL plug-ins running, which can affect the time. Netsuite performs a lot of processing on them so their governance cost is the highest of all record types. But then on top of those costs, there may be many user event scripts and workflows running that could be slowing things down further. If you have the Advanced Performance SuiteApp installed, you can use it to help track down where performance issues might be. Also, does the script do anything else besides create invoices? If there are searches, queries, record loads, or other potentially costly actions that could also be slowing it down. You can easily add timing logs to the M/R script to find out which steps are contributing the most to the time. There’s probably no one answer as the time can vary a lot, based on so many factors, even the time of day the script is running. During peak hours, expect things to take longer.

You can assume 1 SCP (so 5 queues), no UEs or workflows, no GL plugins. I don't need help to troubleshoot, though! I'm just interested to know what you'd consider a good/normal result given that volume and NetSuite's OOTB processing. Put it another way: How long should it take an efficiently built M/R to save a single invoice record, and how does that number change as we scale up?

In our environment today it took my auto-invoice M/R script 35 seconds to create 1 invoice at 4 am PDT and 2 mins 30 seconds to create 17 invoices at 8 am PDT so basically 8.82 seconds per invoice. There’s a UE that runs and the M/R script is also doing a few lookups. We have 1 SC+ license.

You're chasing your tail if you're on a multi-tenant environment. Your benchmark will change daily if not sooner due to the load handling.

Thanks @creece I'm having that convo with a client and trying to convey that nobody is expecting to create an invoice in under 2 seconds, which is how fast it would have to go to get through the required volume in the acceptable number of hours without more SC+ licenses.

2 seconds on a transaction is probably never going to happen. They are the slowest of all records. 2 seconds for a Custom Record (which are some of the fastest Records) with no related Records may be reasonable depending on what it does.

Netsuite won’t guarantee any times, not 2 seconds, not even 20 seconds. Some days, it could take a minute, and Netsuite won’t even consider that an issue, so long as it is still possible to save the invoice at all. If the client wants guaranteed timers, even having more SC+ license won’t get them that. Netsuite is not for them (tell them to ask Netsuite directly for such guarantees).

They could also get their own server

Way way more

And even if you built it to work that way now, future updates or bundles they install could tank performance, even if they had their own server. There’s no guarantee it will always work as well as it does now.

at least as of several years ago, even when you got a "dedicated server" from NetSuite it was still really a multi-tenant environment under the hood when you drill down on it and start asking tough questions about performance, so really there's no winning netsuite

Just to chime in here, we ARE on a dedicated server have 25 threads, and use a MR to create over 15k custpayments and related PDFs. Our thread runtimes are right around the 35 second timeframe per thread. I think the lowest times I've seen are in the low 20 second timeframes. I can also say that, the runtime of your MR is not just related to your MR, but to all of the UE scripts which "hang off of" the records you're loading or updating, those also gobble up runtime.