Also more generally, despite some attractive and well written docs, I’m not totally understanding the difference is between Batch Size, Concurrent Batches, and Queue Runners.

Great feedback: I think this is something we can improve upon.

Actions are processed by one or more queue runners and, generally speaking, the number of concurrent batches basically dictates the number of queue runners that can run in parallel.

The number of actions each queue runner is allowed to claim is dictated by the batch size. Once actions are claimed, they ‘belong’ to that queue runner and cannot be processed by any other queue runners until/unless they are released without having been processed (which might happen if a queue runner has to exit early for some reason).

Here’s a scenario:

• We have 1,000 pending actions.
• 400 of them are past-due (/should be processed as soon as possible).
• 5 concurrent batches (queue runners) are allowed.
• Batch size is 20.

If possible, Action Scheduler will spin up 5 queue runners and each will claim actions in sets of 20 until all the past-due actions are processed.

However, when I schedule a lot of immediate “actions” it appears to only process them one at a time.

It depends a little on what you mean by ‘a lot’. Let’s adjust the previous scenario a little:

• We still have 1,000 pending actions.
• 10 of them are past-due ← this is the factor that changed.
• 5 concurrent batches (queue runners) are still allowed.
• Batch size is still 20.

This time, although upto 5 queue runners are still permitted to run in parallel, the number of past-due actions is only enough to result in one being created.

You could of course reduce the batch size, potentially to as low a value as 1. Then we’d see all the queue runners swinging into action—but in most cases this would create different problems (contention between claim processes, leading to deadlocks).

Does that help/clarify at all?