News Archive
PhpRiot Newsletter
Your Email Address:

More information

Integrating Gearman Into Zend Framework

Note: This article was originally published at Planet PHP on 17 October 2010.
Planet PHP

When scale and performance is important, you start to look into moving operations into synchronous or asynchronous tasks. This is important for any web application that must scale out and/or to add new ways of handling feedback to your users. While I will not be going into detail of how to operate Gearman or briefing you on ways of utilizing gearman, what I am going to show you is how to incorporate Gearman into being it's own Zend Framework application.

This article will go into incorporating Gearman workers into Zend Framework (rather a lightweight approach that can and likely should be scaled out) as you work with aoWorkersa. I have implemented these much to be like aoControllersa in the current MVC model, however, they do lack quite a bit of functionality at this point in the process. Basically, they do not support any plugins or action helpers. However, if you are looking for some form of consistency in your Gearman workers, this is a fairly unique approach of getting them incorporated into your application.


When I started looking into how I could leverage gearman into a new suite of applications, I knew that I was going to need several workers, however, many of these workers would not require the same amount of configuration nor resources. I also knew that I wanted them to be fairly consistent and be able to take new functionality that might be added in the future. I really think of this as something like helpers that mimic the current Zend_Controller_Action_Helper area. However, I knew I would not get to this at the start. I also knew that there was quite a bit of functionality that I wanted to encapsulate such as allowing each individual worker to be able to bootstrap what it needed and do some form of initialization separate from anything else. Lastly, I also knew that I wanted it to be able to kill itself if it started to leak too much memory, be able to handle timeouts in the event that I had a database connection or any other connection that might need to be pinged, encapsulate error handling and last but not least take most of the methods of putting together the registration for the function into a simple constructor.

There is a custom dispatcher that has to be in place since this runs off of the CLI, it takes an argument of the worker name and the application environment. Since these can be exited out, you should utilize something to the degree of aoSupervisora in order to handle keeping the processes alive.

Remember that this is preliminary functionality that I plan to extend in the future but wanted to share the work that has been done. And since I have not been updating my blog often enough this may lack a bit of detail.

The Code

Gearman Worker

To be placed in library/ZF/Gearman/Worker.php

?php A /** * Gearman Worker * * @package Gearman * @subpackage Worker * @version $Id$ */ class ZF_Gearman_Worker { A /** * Register Function * @var string */ protected $_registerFunction; A /** * Gearman Timeout * @var int */ protected $_timeout = 60000; A /** * Alloted Memory Limit in MB * @var int */ protected $_memory = 1024; A /** * Error Message * @var string */ protected $_error = null; A /** * Gearman Worker * @var GearmanWorker */ protected $_worker; A /** * Bootstrap * @var Zend_Application_Bootstrap_BootstrapAbstract */ protected $_boots

Truncated by Planet PHP, read more at the original (another 38816 bytes)