Is it true that if I set the Concurrency Limit to ...
# suitescript
d
Is it true that if I set the Concurrency Limit to 1 in a Map/Reduce, its effectively processing the results sequentially ... 1 at a time?
s
As far as I've seen, yes
c
get input data is always single threaded but once you hit the reduce, its gonna try to parallel what it can but if there's only 1 its gonna run sequentially... so yeah like 1 big sequential script that just manages governance for you.
s
concurrency = 1 means you have only built an overly complex scheduled script :)
m
… with unlimited governance.
s
yes, good point
(though I do get the feeling that aspect actually leads devs to not think much about governance efficiency. )
n
I don't agree with "unlimited governance". Map function have 1000 units. Reduce have 5000 units. If you consume these units, the script throws an error.
m
Map/reduce offers a lot more than just parallel processing over scheduled scripts. Even with concurrency set to 1, you get the two-stage processing, automatic yielding, the sort/shuffle logic, and unlimited governance to do what needs doing. Yes, each map has an allowance of usage, but you get as many map instances as you need, so you can process a million transactions without worrying about governance.
s
the multi-stage processing and sort/shuffling are not improvements over scheduled scripts, especially if concurrency = 1
💯 1
n
If you put it that way @mattdahse, then yes, I agree with the word of "unlimited governance"
d
Woah! Great feedback.
So, my default async bulk processor is Map/Reduce. I mean, it forces proper code decoupling, and offers 'unlimited governance' ... so, I'm not apposed to Scheduled Scripts. The real reason I asked was I found a bug in a customers' API ... where concurrent calls were causing major problems. So, I was hoping (and validating with you folk) that moving my concurrency to 1 might allow me to keep my solution (rather than port to a schedule script)
c
Setting it to 1 should solve that issue