This article reflects v3.4 and has not yet been revised
Activities like processing videos, resizing images or sending emails aren’t suitable to be executed online or in real time because it may slow the loading time of pages and severely impact the user experience.
The best solution here is to implement background jobs. The web application puts jobs into a queue and which will be processed separately.
While you can find more sophisticated PHP extensions to address queueing in your applications like RabbitMQ; Phalcon provides a client for Beanstalk, a job queueing backend inspired by Memcached. It’s simple, lightweight, and completely specialized for job queueing.
Some of the data returned from queue methods require that the module Yaml be installed. Please refer to this for more information. You will need to use Yaml >= 2.0.0
Putting Jobs into the Queue
After connecting to Beanstalk you can insert as many jobs as required. You can define the message structure according to the needs of the application:
<?phpusePhalcon\Queue\Beanstalk;// Connect to the queue$queue=newBeanstalk(['host'=>'192.168.0.21','port'=>'11300',]);// Insert the job in the queue$queue->put(['processVideo'=>4871,]);
Available connection options are:
IP where the beanstalk server is located
In the above example we stored a message which will allow a background job to process a video. The message is stored in the queue immediately and does not have a certain time to live.
Additional options as: time to run, priority and delay can be passed as second parameter:
<?php// Insert the job in the queue with options$queue->put(['processVideo'=>4871,],['priority'=>250,'delay'=>10,'ttr'=>3600,]);
The following options are available:
It’s an integer < 2**32. Jobs with smaller priority values will be scheduled before jobs with larger priorities. The most urgent priority is 0; the least urgent priority is 4,294,967,295.
It’s an integer number of seconds to wait before putting the job in the ready queue. The job will be in the ‘delayed’ state during this time.
Time to run – is an integer number of seconds to allow a worker to run this job. This time is counted from the moment a worker reserves this job.
Every job put into the queue returns a job id which you can use to track the status of the job:
Once a job is placed into the queue, those messages can be consumed by a background worker which will have enough time to complete the task:
Jobs must be removed from the queue to avoid double processing. If multiple background jobs workers are implemented, jobs must be reserved so other workers don’t re-process them while other workers have them reserved:
Beanstalkd supports the ability to manage jobs with both the idea of delaying a job and removing a job from the queue for later processing.
Burying a job is typically used to deal with potential problems outside of the worker that can be resolved. This takes the job and puts it into the buried queue.
A list of buried jobs is stored on the server. You can inspect the first buried job in the queue.
If the buried queue is empty, this will return false, else it returns a Job object.
You can kick the first [N] buried jobs in the buried queue to put it/them back in the ready queue. Below is an example of kicking the first three buried jobs.
Releasing jobs back to the ready queue can be done, along with an optional delay. This is handy for transient errors while processing a job. Below is an example of putting a low (100) priority and a 3 minute delay on a job.