22

I've recently implemented a batch apex class that initially did not implement Database.Stateful. After using it for a while as-is I decided to implemente better error handling via a simple Map to store any error messages for records being processed and to email them to me in the finish(Database.BatchableContext) method.

All well and good, now on to the meat of my question: once this was in place I noticed a serious performance hit on my job's total runtime. (each execute seems to be roughly the same though). Why is this, and are there any other side effects to implementing or not implementing Database.Stateful?

Improve this question
3
  • How big is the map storing the error messages getting? Being a stateful member variable it must be persisted somehow between batch transactions. If it got particularly large the serialization cost could become significant.
    – Daniel Ballinger
    Commented Aug 21, 2012 at 3:43
  • 2
    That could certainly play a role but I've noticed a performance hit even when keeping something small like an integer or boolean in state. Would love it if someone more knowledgeable could chime in.
    – Greg Grinberg
    Commented Aug 21, 2012 at 4:46
  • 1
    If you will permit me one more unknowledgeable conjecture. If the batches are stateful they must be orchestrated so that the member variables can be passed from the completion of one execution to the start of the next. Without the stateful constraint two executions could, in theory, run simultaneously. I have no proof or references to support this idea and would be interested in getting a definitive answer as well.
    – Daniel Ballinger
    Commented Aug 21, 2012 at 19:36

2 Answers 2

Reset to default
15

Daniel Ballinger: No, batches do not ever run simultaneously. You are correct, however, that serialization is the culprit here.

grigriforce: what's your batch size? If you're doing a million records, and your batch size is 1, then you will serialize/deserialize your state 1M times. Even with a small serialized object, that's gonna hurt.

Improve this answer
3
  • Thank you for that, I could swear I once had a senior member of SFDC R&D mention there are 7 worker threads per org, which doesn't make sense if batches are never run in parallel. I may be mis-remembering though.
    – ca_peterson
    Commented Aug 22, 2012 at 20:48
  • perhaps getting batch apex and the bulk api mixed up? (the bulk api can do parallel batches)
    – superfell
    Commented Aug 23, 2012 at 5:05
  • @superfell could be. Or maybe there's some hidden soft limits or other magic for the future. Or may I misheard. Either way between your and Rich's response I'm pretty confident it's not what I thought it was. Thanks to you both for confirming.
    – ca_peterson
    Commented Aug 25, 2012 at 4:03
1

Commenting on a long-dead question:

  1. The difference between a Batchable batch and a Batchable and Stateful batch is that the Batchable's state is updated (serialized and stored) at the end of each start and execute call when Stateful, in addition to it being (serialized and) stored on Database.executeBatch (or System.scheduleBatch) and deserialized before each call to start, execute and finish whether the batchable is stateful or not.
  2. Up to 5 different batches' operations (execute and I assume finish) can be executed in parallel on a given org, but for a given batch instance only one async operation is performed at a time (and always in the order start -> execute* -> finish).
  3. Only one batch instance's start method will be executed at a time on a given org (which gives a sort of "synchronized block").

See the Salesforce docs for details on points 2 and 3.

Clearly the additional serialization and storage actions after the start and execute calls have an overhead. Note that a batchable that is not stateful still does hold its initial state in the database; it just doesn't change from async operation to async operation without being stateful. If that initial state is large then the batch still has that deserialization overhead even when not stateful.

Improve this answer
2
  • The concurrency limit of 5 is only for batch. There aren't firm concurrency limits on future/queuable in the same way, but due to fair use prioritization it might seem like it for small to medium size orgs.
    – ca_peterson
    Commented Mar 8, 2019 at 5:14
  • 1
    @ca_peterson, thanks. Yes, sorry, I'll update.
    – Phil W
    Commented Mar 8, 2019 at 7:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .