Epic Battle: Concurrent Map Reduce vs Concurrent Suitelet

Epic Battle: Concurrent Map Reduce vs Concurrent Suitelet

Spoiler: 50 concurrent Suitelet win. (Tested in Sandbox)

I am a big fan of Map Reduce scripts, spreading the load among 5 queues makes a huge difference when processing your data. Unfortunately to take advantage of the concurrent queues feature your account must have a SuiteCloud plus license. Moreover, consulting with an Insolvency Practitioner West Sussex can provide additional expertise, particularly in managing financial complexities and implementing effective strategies for business resilience.

So I figured it would be cool to simulate this feature with Suitelets. Suitelets support up to 50 concurrent connections and they are available without the need of SuiteCloud plus.

The results were very surprising.

Test scenario:

  • Task: Create and delete a custom record with no fields.
  • Account: Account with SuiteCloud Plus license in Sandbox.
  • Map Reduce: Run task 10k times by returning an array of 10k elements on the getInputData step and let the reduce step handle the main logic.
  • Suitelet SS2.0: Run task once per call. Return “OK” as response. Available without login (External).
  • Use Apache JMeter to call the Suitelet 10k times.
  • Additionally call the Suitelet using Ajax with browser (Chrome) 5k times (to avoid browser memory issues).

Here are the results:

testresults

 

Map Reduce w/buffer size of 1 : 196 seconds ~ 51 per second
Map Reduce w/buffer size of 64: 518 seconds ~ 19 per second
Suitelet w/JMeter w/50 at a time: 55 seconds ~ 181 per second
Suitelet w/JMeter w/100 at a time: 30 seconds ~ 333 per second
Suitelet w/JMeter w/200 at a time: 24 seconds ~ 416 per second
Suitelet w/JMeter w/250 at a time: 24 seconds ~ 416 per second
Suitelet w/JQuery: 1000/44 secs ~ 22 per second

As you can see, I ran multiple test variations. After I saw that the Suitelet was able to handle 50 requests at a time I went crazy and increased the number of concurrent requests. I got up to 250 requests being handled successfully. Once I reached 300 requests at a time I started getting errors and not all the records were successfully created.

As you can see, after 200 requests you pretty much get the same speed. This could be caused by my system, JMeter, my internet connection or by some throttling happening on the Netsuite side, I don’t know.

Conclusion:

This approach can be pretty handy if you ever need to process large quantities of records and you need even more speed than what Map Reduce gives you. You would need to develop your Suitelet in a way that even if something goes wrong you have a way to identify the errors and retry the operations. Additionally, you would need to get a tool that bypasses the browser restrictions such as Apache JMeter and configure it if you need to pass any data to the Suitelet.

Anyways, the difference is huge. Basically you could process 1 million records in 40 mins in the Suitelet vs 5:30 hrs in a Map Reduce… and this is in Sandbox, go figure how faster this would be in Production.

  • Chris

    Hello Adolfo,

    This is an excellent article, however will the latest 17.2 enhancements be the first step in stopping this from happening? In my experience with NS if you find a method to workaround Governance Netsuite will spot it and throttle it. The Netsuite SAFE guide I believe advises against this approach. Do you have any experience of running this approach in anger?

    Thanks

    • Good question. To my understanding the new concurrency limits don’t apply to Suitelets. As for the approach, I have had some experiences in which a solution broke because of a Netsuite update, so I would only use this solution for one-time uses like a data migration for example. If you want to have this as an ongoing solution I would advise to reduce the load by writing only to custom records and make your code very modular so in case Netsuite pulls the plug on it you could easily refactor the code into a map reduce or something similar and upgrade to Suitecloud plus if necessary.

  • Alana Thomas

    Hi, Adolfo, thank you for writing this blog.

    Is there any way to know when NetSuite is throttling performance? For instance, is there a global usage limit I can check against, to avoid getting throttled, or is there a rule of thumb I can use?

    • Unfortunately no, Netsuite isn’t clear on that besides providing a way to check the governance limits. If your account is using too many resources they will reach out to you and let you know what changes you need to make to improve it. For example if a Restlet endpoint that writes to transactions is getting called very frequently they would advise using a custom record instead because they are more lightweight.

      Another thing you may want to try is the APM SuiteApp which is free. This app let’s you see a performance overview of scripts and records at a glance.

      • Alana Thomas

        Thank you for all your help, Adolfo! I think I know the right direction to go 🙂

  • li star

    Hi Adolfo
    I use postman send post request to suitelet,but it return err (Error 405–Method Not Allowed)
    Do you know how to solve it

    • Try setting the header “User-Agent’ to ‘Mozilla/5.0’

      • li star

        thanks, It can solve my question.

  • Yuu

    Hi Adolfo, Can we auto insert many new lines by map reduce to a record?

    • You can insert many new lines to a record using map reduce, but if your intention is to add many lines simultaneously in different queues to the same record then no, that won’t work because it would throw an error saying “Record has changed” or something like that. Also, there’s really no benefit, in one operation you can save 999 lines at once, if you were to save 1 line per instance then it would take forever to finish.