Queueable Execution Time Limitation

Question

I've got a trigger on opportunities (after update) that enqueues a job using a Queueable apex class.

What are the limitations I'm going to hit if opportunities are update very frequently? Will salesforce limit my execution time one one job per minute, or will it process them as fast as it possibly can?

My concern stems from the following blog post:

https://developer.salesforce.com/blogs/engineering/2014/10/new-apex-queueable-interface.html

In there, it's noted:

The primary new item to know about is the increasing backoff for re-queuing a job. Each job will have a delay before it is enqueued again. The time will climb from a one-second delay to a one-minute delay, and it will continue at one minute forever. This means your logic will be able to run as quickly as once a minute. This should be sufficiently fast for your use cases; as it is, we can sometimes see delays in the queue of several minutes. I have to think that the world can wait sixty seconds for nearly anything in forever-asynchronous mode.

I believe this limitation is ONLY for queue jobs that chain forever, but it's a little ambiguous. Will I hit this limitation (or any others) with my architecture?

Answer 1

First, the "backoff" feature apparently isn't implemented yet, at least last time I tried. See this question that I asked... no response from salesforce.com or anyone else, really. That aside, the answer to your specific is somewhere in the middle. It will not process queued items immediately as fast as possible, nor will it be once per minute.

Queuable items are placed into a queue to be processed at a specific time in the future, with a penalty applied for each call past the first in a transaction. The penalty is double the previous call's penalty, starting at 1 second, with some maximum cap. They'll be processed as soon as possible once the penalty expires. This means that you'll get better performance if you can process an entire trigger worth of records in a single queueable call.

Queueable jobs that "chain" are supposed to suffer additional back-off penalties, which doesn't seem enforced at the moment, but might change later. There's no real advantage to chaining instead of just spawning multiple jobs in a transaction, perhaps 4 to a batch (for example), if you need to. There are some limits to be concerned about, of course, outlined in the Governor Limits, particularly they share limits with future, batch, and scheduled calls, which are limited to 250,000 per rolling 24-hour window (or 200 times your license count if this would be higher).

Answer 2

Followup to @sfdcfox answer

At least as of V40.0 when I started testing this, the Queueable backoff is definitely implemented.

I ran a small test where I created an initial queueable that then chained to another that chained to another for a depth of 15 total. Results are in sandbox and are as follows (YMMV depending on how much work the queueable execute() does)

Back off times are rounded to nearest hundredth of a second

                    Run 1                         Run 2
Chain depth              SFDC-imposed backoff time (s)
    1                 -                            -
    2                 0.87                       0.91
    3                 0.84                       0.45
    4                 0.84                       0.34
    5                 39.49 !!                  27.28 !!   
    6                 58.75                     57.98
    7                 60.41                     60.70
    8                 59.65                     60.34
    ...               around 60s thereafter     around 60s thereafter

So -- lessons here:

• Your arrival rate of signals that create a chained queueable had better be < 1/minute or the queue will grow without bound - basic queueing theory
• You'll get better thruput if different running users are starting their own chains. sfdcfox suggests that multiple chains started by same user will also yield better thruput - I did not test this.
• try and make each queueable do as much batched work as possible to avoid chaining

UPDATE V57.0

I did a new experiment prompted by comments by the Apex PM that the queueable backoff time had been relaxed

With 100 iterations of a queueable chaining itself with the default delay. I observe the following

Chain depth        Sec delay before starting
----               ------------------------
  1                  .090
  2                  .088
  3                  .082
  4                  .094
  5                  .076
  6                  .097
  7-100             between 1.09 and 1.8 sec