Category Archives: Articles

Easy Performance Win in ZF2 with Route Caching

As a follow-up to our Zend Framework 2 (ZF2) performance article we created a composer package that can be used right away in your ZF2 application.

We have noticed that in real world applications routing can take
300 ms or more. With this module the routing can take less than 40 ms.

Installation

Run the following command from the root folder of your ZF2 application.

php composer.phar require learnzf2/route-cache:*

Setup

First: To enable the module make sure to add it to the list of modules in your config/application.config.php.

Second: This module requires a cache service that is called “var-cache”. The cache service
should be able to store variables. If you already have such a service but it has a different name then you can use aliases in the service_manager section of your application configuration. This can be achieved by adding the following lines:

3
4
5
6
7
8
9
'service_manager' = array(
 // ...
 'aliases' => array (
 // ...
 'var-cache' => '<your-cache-service-name>'
 )
),

If you don’t have a cache service in your application then copy the file
vendor/learnzf2/route-cache/config/cache.local.php.dist to config/autoload/cache.local.php.

Enjoy!

Route Cache in Zend Framework 2

There are several ways to improve the performance of a Zend Framework 2 (ZF2) application and in the “Learn ZF2” I explained some of them. But not all of them. Below you will find an information how to speed up the ZF2 application routing.

In a typical ZF2 application evaluating the routes and finding a match can be time-consuming task. The more non-literal routes your application has the slower the route matching process will be. Below I will present you one possible way to speed up that process.

In ZF2 routing means finding a controller, action and set of parameters that correspond to the current URL and given request parameters. In ZF2 the routing process starts when the MVC ROUTE event is triggered. There is a listener with priority 1(one) attached to this event that takes care to find a route match. What we can do is attach a new listener to the MVC ROUTE event but with higher priority. This way our listener will be executed before the actual matching process is started. In it we can check against a cache system if for the provided path of the URL there is already a cached data that contains the match parameters. In addition we can add a second listener to the MVC ROUTE event with lower priority. It will be executed after the matching is done and we can use it to save the route match data to our caching system. A good initial place to put those listeners will be in the Application Module.php ( module/Application/Module.php )

The initial version of our two listeners looks like this:

<?php
namespace Application;
 
use Zend\Mvc\MvcEvent;
 
class Module
{   public function onBootstrap(MvcEvent $event) 
    {
        $eventManager        = $event->getApplication()->getEventManager();
 
        //..
        $eventManager->attach(MvcEvent::EVENT_ROUTE, array($this, 'routeLoad'), 999);
        $eventManager->attach(MvcEvent::EVENT_ROUTE, array($this, 'routeSave'), 0);
    }
 
    /**
     * Method that tries to load cached routes and speed up the matching
     * @param MvcEvent $event
     */
    public function routeLoad(MvcEvent $event)
    {
        // @todo: check if we have data in our cache
    }
 
    /**
     * Method that tries to save a route match into a cache system
     * @param MvcEvent $event
     */
    public function routeSave(MvcEvent $event)
    {
        $match = $event->getRouteMatch();
        if(!$match) {
            return;
        }
 
        // @todo: save the route match into the cache.
    }

We should take care to cache the route match for URLs that produce the same result. A good example of a request for which the routing can be cached is the case when we have GET request and no query params. For such events we can set a flag route-cacheable. Additionally we should set a flag in the event that specifies if a cached route match was used or it was calculated during this request. That will help us avoid caching already cached routes. So the code will start to look like this

// ...
 
    /**
     * Method that tries to load cached routes and speed up the matching
     * @param MvcEvent $event
     */
    public function routeLoad(MvcEvent $event)
    {
        $request = $event->getRequest(); 
        if(!(
            $request->getMethod() == \Zend\Http\Request::METHOD_GET && 
            $request->getQuery()->count() == 0
            )) {
            // We do not cache route match for requests that can produce
            // different match.    
            return ;
        }
 
        $event->setParam('route-cacheable', true);
 
        // @todo: check if we have data in our cache
        $inCache = false; // @todo: get the actual value
 
        if($inCache) {
            $event->setParam('route-cached', true);
        }
    }
 
    /**
     * Method that tries to save a route match into a cache system
     * @param MvcEvent $event
     */
    public function routeSave(MvcEvent $event)
    {
        $match = $event->getRouteMatch();
        if(!$match) {
            return;
        }
 
        if($event->getParam('route-cached') || !$event->getParam('route-cacheable')) {
            return;
        }
 
        // @todo: save the route match into the cache.
    }

The real trick to speed up the route matching is not to bypass it but to put on the top a route definition that is very fast to match. This definition should use the Literal route type and should contain the route name and route parameters stored in the cache from the actual matching. Creating such a route can be done with:

$cachedRoute = \Zend\Mvc\Router\Http\Literal::factory($cachedData);

The router contains multiple routes ordered in a stack. And this stack is evaluated from top to bottom. On the top are the routes with higher priority and on the bottom are the ones with lower priority. We need to put this cached router on the top of the stack of routes that we have. This can be done with a code like:

$router = $event->getRouter();
$router->addRoute($cachedData['name'], $cachedRoute, 99999);

In the routeLoad method the new code will look like this:

/**
     * Method that tries to load cached routes and speed up the matching
     * @param MvcEvent $event
     */
    public function routeLoad(MvcEvent $event)
    {
        $request = $event->getRequest(); 
        if(!(
            $request->getMethod() == \Zend\Http\Request::METHOD_GET && 
            $request->getQuery()->count() == 0
            )) {
            // We do not cache route match for requests that can produce
            // different match.    
            return ;
        }
 
        $event->setParam('route-cacheable', true);
 
        // @todo: check if we have data in our cache
        $cachedData = false; // @todo: get the actual value
 
        if(!empty($cachedData)) {
            $event->setParam('route-cached', true);
 
            $cachedRoute = \Zend\Mvc\Router\Http\Literal::factory($cachedData);
            $router = $event->getRouter();
            $router->addRoute($cachedData['name'], $cachedRoute, 99999);
        }
    }

Saving the actual route match in the cache should be done in our routeSave method. We can use the var-cache service that you know from the “Learn ZF2” book code. The final version of our routeSave method will look like this:

/**
     * Method that tries to save a route match into a cache system
     * @param MvcEvent $event
     */
    public function routeSave(MvcEvent $event)
    {
        $match = $event->getRouteMatch();
        if(!$match) {
            return;
        }
 
        if($event->getParam('route-cached') || !$event->getParam('route-cacheable')) {
            return;
        }
 
        $path = $event->getRequest()
                ->getUri()
                ->getPath();
 
        // save the route match into the cache.
        $cache = $event->getApplication()->getServiceManager()->get('var-cache');
        $cacheKey = $this->getCacheKey($path);
        $data = array (
          'name' => $event->getRouteMatch()->getMatchedRouteName(),
          'route' => $path,
          'defaults' => $event->getRouteMatch()->getParams(),
        );
        $cache->setItem($cacheKey, $data);
    }

And the final version of the routeLoad method will look like this:

  /**
     * Method that tries to load cached routes and speed up the matching
     * @param MvcEvent $event
     */
    public function routeLoad(MvcEvent $event)
    {
        $request = $event->getRequest(); 
        if(!(
            $request->getMethod() == \Zend\Http\Request::METHOD_GET && 
            $request->getQuery()->count() == 0
            )) {
            // We do not cache route match for requests that can produce
            // different match.    
            return ;
        }
 
        $event->setParam('route-cacheable', true);
 
        // check if we have data in our cache
        $path = $event->getRequest()
                      ->getUri()
                      ->getPath();
 
        $cache = $event->getApplication()->getServiceManager()->get('var-cache');
        $cacheKey = $this->getCacheKey($path);
        $cachedData = $cache->getItem($cacheKey); 
 
        if(!empty($cachedData)) {
            $event->setParam('route-cached', true);
 
            $cachedRoute = \Zend\Mvc\Router\Http\Literal::factory($cachedData);
            $router = $event->getRouter();
            $router->addRoute($cachedData['name'], $cachedRoute, 99999);
        }
    }

Update: 2nd of April, 2015: We have create a composer package that you can use directly in your ZF2 application and take speed up your route matching. Take a look the github page of the project  for information how to install and setup the plugin.

Happy ZF2 coding and good luck with improving the performance of your ZF2 application!

Themes in Zend Framework 2

Creating visual themes in your Zend Framework 2 (ZF2) application and switching between them is easier than you think.

I am often asked the following question:

How to create a completely separate mobile theme for our application? Not just using a new layout but also being able to override separate view templates, if needed.

I will extend this question to a more broader one:

How to create different themes in ZF2? Is that possible at all?

The short answer is: yes it is possible. In the next paragraphs I will show you one possible solution. Bear in mind that I will use some terms from the ZF2 world and you may need a bit of support from books like “Learn ZF2″ or the online manual to understand the explanations better. It might be a good idea to read also the previous article about View Models and Rendering.

The solution below will be created in a separate module called “Theme”. But you can quite happily make it part of your Application module.

First in out Module.php we need to attach an event listener that is executed before the actual rendering is happening. This can be done using the following code:

namespace Theme;

use Zend\Mvc\MvcEvent;


class Module
{
    public function onBootstrap(MvcEvent $event)
    {
        $eventManager = $event->getApplication()->getEventManager();
        $eventManager->attach(MvcEvent::EVENT_RENDER,array($this,'prepareTheme'),100);
    }
    //...
}

The import line above is that one:

$eventManager->attach(MvcEvent::EVENT_RENDER,array($this,'prepareTheme'),100);

It says attach the method prepareTheme from the current class to be executed with priority 100. 100 is higher than 1, which is the default priority and that guarantees us that prepareTheme will be executed before the actual rendering.

Before we jump to our prepareTheme method let’s see how we can define a “theme” and specify the view templates that have to be different in this theme. One possible solution is to use syntax which is similar to defining template_map and template_path_stacks in a view_manager section.

module//module.config.php

return array(
 // ...
 'themes' => array (
        'mobile' => array(
            'description' => 'Application Mobile Theme',
            'screenshot' => 'http://learnzf2.com/wp-content/uploads/2013/10/logo.png'
            'template_map' => array (
                'application/index/index' => __DIR__ .'/../theme/mobile/application/index/index.phtml',
                'layout/layout' => __DIR__ .'/../theme/mobile/layout.phtml',
            ),
            'template_path_stack' => array(
                __DIR__ . '/../theme/mobile/',
            ),
        )
    )

  //...
);

What we have above is a key themes in the configuration. Under that key there is another key with the unique name of the theme that we describe. In the case above this is mobile. And the array inside describes what we override. We used the same syntax for defining view templates as in the view_manager section and we added two more fields description and screenshot. The first has the short description for the theme and the second, which can be optional, points to the location from where our theme screenshot can be viewed.

In the prepareTheme method what we will do is check if there is a theme that is set and if yes we will try to instruct the ZF2 resolver to use the templates for that theme.

    
    public function prepareTheme(MvcEvent $event)
    {
        $services = $event->getApplication()->getServiceManager();
        $themes = $services->get('theme');
        $config = $services->get('config');

        // From our themes service we get the current theme that is set, if any
        $themeName = $themes->getName();
        if (!$themeName) {
               return;
        }

        $themeConfig = $themes->getConfig();
        $themeConfig = $themeConfig[$themeName];

        // !! Here Comes The Magic (R) !!

        // We override the template resolver
        // Here we add the changes that need to be applied to the existing template map
        if (isset($themeConfig['template_map'])) {
            $map = $services->get('ViewTemplateMapResolver');
            $map->merge($themeConfig['template_map']);
        }

        //  And we put our theme paths on top of the stack.
        //     This way if there is template in our theme it will be taken and used
        //     Otherwise we will use the ones provided earlier from the application
        if (isset($themeConfig['template_path_stack'])) {
            $stack = $services->get('ViewTemplatePathStack');
            $stack->addPaths($themeConfig['template_path_stack']);
        }
    }

And the above code is where most of the magic happens. Using that approach we can have themes that override the layout or selected templates and do not require us to override all existing application templates.

You can check the complete source code from here: https://github.com/slaff/learnzf2-theme. It contains all the tiny details needed to be able to switch between different themes and to decide which theme is the current one. If you use composer you can require the learnzf2/theme package.

A sample theme using that module can be found here (github, packagist: learnzf2/example-theme ).
Disclaimer: The sample theme is there to demonstrate the configuration and file structure needed to create a theme. It is very far from being good visual example. And we would be very happy if someone with good designer skills is willing to change that.

Enjoy 🙂

View Models and Rendering Demystified

“View Models and Rendering Demystified” or the View Model is not your burger!

Often beginner Zend Framework 2  (ZF2) developers are confused about  view models and the whole rendering process.  In this article I will try to explain them making an analogy to ordering a burger at a restaurant. Bear in mind that I will use some terms from the ZF2 world and you may need a bit of support from books like “Learn ZF2” or the online manual to understand the explanations better.

Imagine that you went to a restaurant and ordered cheese burger. In ZF2 terms this will mean that your browser made an HTTP request to a ZF2 application and as a path in the URL it had  /order/cheeseBurger. Also you are not in a hurry and want to eat your burger at the restaurant. The HTTP request for this may look like that:

GET /order/cheeseBurger/?takeAway=0
Host: zf2burger.com

Routing Event

In a real restaurant the person at the desk will check if there is cheese burger in the menu(hopefully he knows that) and if it can be ordered. In ZF2 this means that the router checks the routing rules and tries to map your URL to a valid routing definition.

In the module.config.php file for the Restaurant module you should have something like this:

'routes' => array(
            'ordercheeseburger' => array(
                'type' => 'Zend\Mvc\Router\Http\Literal',
                'options' => array(
                    'route'    => '/order/cheeseBurger',
                    'defaults' => array(
                        'controller' => 'Restaurant\Controller\Order',
                        'action'     => 'cheeseBurger',
                    ),
                ),
            ),
        )

Dispatching Event

The restaurant is offering your favorite cheese burger and the person at the desk instructs the kitchen to prepare your cheese burger. In ZF2 this means that from the routing definition the application has found a controller and action that is responsible for preparing cheese burgers. The action knows what recipe (view name) to use and what ingredients( view variables ) to include in order to prepare the cheese burger.  This is where our View Model  (VM) is created. Think of the VM as a box. Outside of the box stays a label saying the recipe name(view name) to be used and inside of the box we have the ingredients( variables) to use. Every ingredient is labeled (view variable name). At that moment we still do not have the burger ready.

After the box (VM) is ready the person at the desk asks you if you want to eat in the restaurant. If you say yes he opens another box and puts your box in it. In the big box he puts a label saying: decoration. In ZF2 one VM (box ) can have multiple children ( other boxes inside of it) or be part of the content of a bigger box.

namespace Restaurant\Controller;

use Zend\Mvc\Controller\AbstractActionController;
use Zend\View\Model\ViewModel;

class OrderController extends AbstractActionController
{	
   	public function cheeseBurgerAction() 
	{
		$viewModel = new ViewModel();
		$viewModel->setTemplate('cheeseburger-recipe');
	       	$viewModel->setVariables(array(
		          'cheese' => $gourmetFrenchCheese,
		          'meat'  => $mincedSuperbBeef,
		          'onions'=> $sweetOnion 
		));

		if($this->params('takeAway', false)) {
		           $viewModel->setTerminal(true);
		}
		
		return $viewModel;
	 }
}

One day in the kitchen came an important person who wanted to optimize the delivery time. He asked all persons working at the front desk to put all orders inside a new box and add a note with the start time when the order was accepted.  In ZF terms this can be a Debug module that adds debug overlay by creating a new view model (box ) and putting the content of the current box inside of it.

public function onBootstrap(MvcEvent $e)
{
	// Below is how we get access to the service manager
	$serviceManager = $e->getApplication()->getServiceManager();

        // ..
		
	$eventManager->attach(MvcEvent::EVENT_RENDER,
                                 array($this,'addDebugOverlay'),
                                 100);
}
    
    
public function addDebugOverlay(MvcEvent $event)
{
    	$viewModel = $event->getViewModel();
    	 
    	$sidebarView = new ViewModel();
    	$sidebarView->setTemplate('debug/layout/sidebar');
    	$sidebarView->addChild($viewModel, 'content');
    	 
    	$event->setViewModel($sidebarView);
}

(See the Learn ZF2 book repository on github)

Rendering Event

Once the person at the kitchen sees that someone ordered cheese burger he tries to apply the recipe instructions and use the ingredients that are given for that burger. He either knows the recipe or looks in cook books to find it. The books are stacked in a pile. The last book to be added is the first book to be read. When he looks in the books he uses the first recipe for cheese burger that he finds.  In ZF2 we have a resolver. The resolver tries to find from the view template name( recipe name)  the actual template file. And it can use either a template map (the cook remembers the recipe) or search for the view template name in a template path stack( multiple stacked cooking books with recipes until he finds the right one).

'view_manager' => array(
    'template_map' => array(
        'layout/layout' => __DIR__ . '/../view/layout/layout.phtml',
     ),
     'template_path_stack' => array(
          __DIR__ . '/../view',
      ),
),

One conclusion from the information above is that a fast cook is one who remembers a lot of recipes instead of looking in cooking books for them. In ZF2 application  looking for view template from a template map is much faster than trying to find the template in a template path stack. Which is important for the performance of your application especially when you have a lot of templates. ( In Learn ZF2 you will find detailed explanation in the Performance chapter)

The cook has all the ingredients and the right recipe. He starts opening the boxes until he reaches the innermost one. It contains information about your cheese burger. He cooks your juicy burger. Then he sees that there is a bigger box and he uses that information to add some salad in your plate as a decoration. In ZF2 the rendering process tries to render(cook) the innermost VM(box), and the content from the rendered VM is used in the parent VM. The decoration is stored in the layout template. The rendered content is the result from rendering the outermost VM.

Event Finish

Finally your burger is ready and served to you with a nice decoration. In ZF2 this is the moment where the rendered content is delivered to the browser.

Enjoy 🙂