$worker = new DJWorker($options); $worker->start();
Actually: 1. block until all jobs stored in the database have been completed 2. simply run a single job and return 3. return immediately and run all the jobs on a separate thread in the background
I'm wondering where in a web application would be the best place to call $worker->start()?
In the interest of some outside figures, how have you found this to scale? I implemented a similar solution as more of a stopgap until I had the time to get RabbitMQ installed with a "proper" worker dispatcher (more moving parts but less stress on the DB). I mostly ask because we implemented it for our notification system where we had to generate a send large batches of custom emails which was bogging down the page (and hard to debug where in the chain we were getting failed messages).
I put it on GitHub because Jeremy Kemper really wanted to have a look at it. I thought the idea behind it was so naive that it would have occurred to everyone who ever needed a queue and had discarded the approach for some reason.
Little did I know that it was a fairly novel approach and that it would become one of my most popular libraries, right after ActiveMerchant and Liquid.
Thank you for the PHP port!
You're welcome, and thank you for delayed_job!
for eg. an in-memory sqlite db would be ideal for this purpose (and a lot faster)