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?
Best Answer
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).