What exactly is "Extended Delay" in the context of Batch Apex?

Question

Just noticed in the Salesforce Technical Library: Asynchronous Processing in Force com it says:

Fair Request Handling

Since all of the requests in the peek set are from a single organization (organization 1), those 15 requests will be moved to the back of the queue with a specific delay.

This is called an extended delay.

Then further down in the same article, it says:

Batch Apex

Ensure that the Batch Apex process executes efficiently as possible and minimize the batches submitted at one time. Like @future requests, batch Apex needs to execute as fast as possible. Best practices include:

...

Extended delay is not applicable to batch Apex.

What exactly does this last statement mean?

• Does this mean Salesforce never delays between jobs when you chain batches?
• Does this mean Salesforce never delays between chunks within each job?
• Or does this mean something else?

Surely SFDC wants to penalize 1-chunk batches and encourage the use of Queueables and Futures, but the application of extended delay seems to be back to front here.

Answer 1

Batch Apex only starts when there's available resources. For example, Batch Apex only allows one start method per organization simultaneously. This gateway means that even though you might have many batch processes queued, it's likely that only 1 or 2 large jobs will run from the same organization at once. However, there's also a limit of 5 simultaneous executing batch jobs per organization as well, and a limit of 100 batches on Hold (so a total of 105 total batches can be in an org at once).

They do, in a sense, penalize small batches, because it takes much longer (usually about 5-10 times as long) to execute as it would to use future or Queueable methods. Combined with the limits on queued batches, and you'll see that they're actually quite severely restricted compared to the lightweight queueable and future methods.

Once your batch process has completed its start method, the requests will be interleaved with other requests in other orgs. This will be represented as an inter-transaction delay. This delay seems to be between 100 and 3500 ms (0.1 to 3.5 seconds) under normal circumstances. The time will not be consistent as batches enter and leave processing, but since the system generally won't start batches until the resources are available, the delay will be remarkably consistent in most cases, as they appear to be handled in a round-robin pattern across all available threads, ensuring equal time to each chunk.

The final statement "Extended delay is not applicable to batch Apex" applies to jobs that have started. Jobs that have not started will be queued until the resources are available. However, that's not an extended delay, just a normal delay. There may be a normal delay between chains in a batch job (e.g. you already have one or more batch jobs on Hold, so they get to go first), but this also won't be an extended delay. There will definitely be a noticeable delay between chunks in a batch job, since they are interleaved with other running chunks, but these are also just normal delays, not extended delays.