eZ Publish Performance Optimization Part 2 of 3: Identifying Trouble Spots by Debugging

This section contains information on typical scenarios that can cause performance problems. We will describe how to spot and solve them.

Wrong character sets

When character sets are wrongly configured, eZ Publish will use charset conversion as shown in the picture below. This is not necessary and reduces performance:

An example time breakdown for charset conversion

The following example presents an incorrect charset configuration:

i18n.ini.append.php:
[CharsetSettings]
Charset=utf-8
template.ini.append.php
[CharsetSettings]
DefaultTemplateCharset=iso-8859-1

You can define character sets in three places: the database, internally and in templates. In this example, the databases and templates are using the latin1 charset, but the internal charset is set to Unicode. To remedy this problem, ensure that all the character sets used in eZ Publish are the same.

Disabled template compilation

When template compilation is disabled, eZ Publish parses all templates "on the fly". This is helpful during development when you are testing template changes frequently, but it takes a lot of server resources and significantly reduces performance. A common mistake is to forget to enable template compilation when transitioning to a "live" site. The example debug output below shows the template processing times when compilation is disabled.

You can see that time is spent parsing the text and constructing the internal template execution tree before the template is actually processed. This is not necessary.

To fix this, simply enable template compilation:

site.ini.append.php:
[TemplateSettings]
TemplateCompile=enabled

Disabled viewcache

Viewcache is the terminology we use for the cache that stores the complete HTML output of a view. This is similar to template compilation in that it avoids the complete regeneration of a view each time it is accessed. If a development site goes "live" with viewcaching disabled, this reduces performance and increases page load times. Live sites should always have viewcaching enabled.

Here is an example debug output when viewcache is disabled:

Example processing times with viewcache disabled

To fix this, simply enable viewcaching:

site.ini.append.php:
[ContentSettings]
ViewCaching=enabled

Incorrect folder permissions

If eZ Publish is installed on a Linux/UNIX-based system, some of the file permissions need to be changed. The most common issue is that the webserver does not have write access to the settings/, design/ and var/ directories. In this case, eZ Publish will report an error as shown in the picture below:

eZ Publish is bundled with a script called modfix.sh that sets the correct permissions. The script needs to be run from within the eZ Publish base directory:

$ cd /path/to/ez_publish
$ bin/modfix.sh

The modfix script recursively alters the permission settings of the following directories:

var/*
settings/*
design/*

You can also set these permissions manually. If you know the user and group of the webserver, it is recommended to use a different set of permissions. This is more secure, as it only allows write access for the webserver user and group.

$ chmod og+rwx -R var

$ chown -R example:example var

The "example:example" notation must be changed to the user and group of the webserver.

Slow database

The time spent accessing the database in eZ Publish is usually low (1-20% of the total page generation time, depending on how complex a given page is). If you disable viewcaching and look at the debug output, you can see how much time is spent on the database connection. Either the connection to the database or the database itself might be running slowly.

Here is some sample debug output on database timing:

Here is a slow SQL query (with SQLOutput enabled):

Many SQL queries

Redundant usage of the fetch function can produce a lot of unnecessary SQL queries. This reduces performance and wastes server resources. By using the debug output with disabled viewcaching, you can see how many SQL queries are performed. Below we present example template syntax used to fetch children and sub-children from a folder:

{foreach fetch(content, list,hash(parent_node_id, 2)) as $object}
   {def $sub_children=fetch( content, list, hash( parent_node_id, $object.node_id ) )}
  Child name: {$object.name}<br/>
   {foreach $sub_children as $sub_child}
       Sub-child name: {$sub_child.name}<br />
   {/foreach}
{/foreach}

This code produces a lot of unnecessary SQL queries and can be replaced with:

{foreach fetch(content, list,hash(parent_node_id, 2)) as $object}

  Child name: {$object.name}<br />
  {foreach $object.children as $sub_child}
      Sub-child name: {$sub_child.name}<br />
  {/foreach}
{/foreach}

Here is an example debug output with a large number of SQL queries: