$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()?
Or using the command line version of PHP and GNU Screen (I haven't fully studied the code, but it looks similar to a queue system that I hacked together a couple of days ago where the worker is wrapped in a while(TRUE) loop).
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).
Not sure who your question was directed to, but I've implemented a similar system in the past for a website with 10m+ users and 15+ web servers. It scaled just fine, we were sending close to 150K emails a day, among other background jobs for reporting, data cleanup, automated spam checks, etc
Comments
In your example, does the call:
$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()?
I think the point is to run the worker outside of a web request and using a cron job
Or using the command line version of PHP and GNU Screen (I haven't fully studied the code, but it looks similar to a queue system that I hacked together a couple of days ago where the worker is wrapped in a while(TRUE) loop).
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).
Not sure who your question was directed to, but I've implemented a similar system in the past for a website with 10m+ users and 15+ web servers. It scaled just fine, we were sending close to 150K emails a day, among other background jobs for reporting, data cleanup, automated spam checks, etc