There could be a flag on the Db class - or inside each of those methods - that would reduce the number of database reads.
Currently, each iteration over reserve() issues a SELECT. If there are 100 jobs waiting to be run, 200 queries will happen: 100 selecting and 100 deleting. Instead, one one SELECT query could be issued if the developer sets a given flag, and a pool of jobs would be held inside the Queue class for further processing.
Example:
$queue = new DbQueue();
$queue->bulkFetches = true;
$queue->put(1);
$queue->put(2);
$queue->put(3);
while ($job = $queue->reserve()) { //one query, three jobs
echo $job->getBody();
$job->delete(); //one query per job; can't be avoided as further jobs may hang
}A call to reserve(), peekReady(), peekBuried() or peekDelayed() would retrieve all available jobs given those constraints, store them in a cache (a class property for instance) and returns one every time the method is called again. Once that cache is emptied, a new query would happen.
There could be a flag on the Db class - or inside each of those methods - that would reduce the number of database reads.
Currently, each iteration over reserve() issues a
SELECT. If there are 100 jobs waiting to be run, 200 queries will happen: 100 selecting and 100 deleting. Instead, one oneSELECTquery could be issued if the developer sets a given flag, and a pool of jobs would be held inside the Queue class for further processing.Example:
A call to
reserve(),peekReady(),peekBuried()orpeekDelayed()would retrieve all available jobs given those constraints, store them in a cache (a class property for instance) and returns one every time the method is called again. Once that cache is emptied, a new query would happen.