This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Forums » General » eZ publish performance optimisation FAQ

eZ publish performance optimisation FAQ

eZ publish performance optimisation FAQ

Friday 16 December 2005 7:05:01 pm - 50 replies

Hello community members,

There are so many people moaning about EZ based systems performance here that they now probably form one frustrated crowd of web development professionals that we cannot allow to leave!

Isn't it time to collect development techniques and configuration tips for reducing page load time as a solid document that will help newbies and retain current speed-fighters?

It can be extremely useful including myself that struggle with this issue for the last year starting 3.5 even with all the accelrator, etc. in place! It feels like there should be a set of tricks to try because posts here indicate that it is either way under 1 sec or above 5, so what's the magic?

The useful threads I found are:

Let's start posting remedies in here, together we can produce complete list of those known!

Modified on Friday 21 April 2006 3:57:02 pm by Denis Igin

Tuesday 07 March 2006 5:49:05 pm

You're right, the static cache is the same as preprocessing, however - if there is an instance where you need dynamic content - you can use eZ to deliver the content as PHP or to a PHP application for adaptive high speed delivery.

My approach was to create a dedicated template that extracted the content from eZ and wrote PHP. This was called by a PHP script that further processed it and wrote it out.

Most people will not need to use these techniques - but they allow eZ to support a very high traffic site - delivering dynamic content on the home page and for other sites.

Modified on Tuesday 07 March 2006 6:32:28 pm by Betsy Gamrat

Thursday 20 April 2006 11:53:05 am


First of all, I am not an eZ Publish expert, but we have been suffering performance issues and we have partly solved them. But maybe there is room for improvement if we share our best practices.

We have drastically improved the performance doing so but maybe we can even go further so I share what we have done and you can comment, add your config files or rectify me.

<b>[Are the templates correctly cached]</b>

Activate the Debug Output for the Template.

If your template is correctly cached you should only see 3 templates loaded:

1/ setup/debug_toolbar.tpl setup/debug_toolbar.tpl design/standard/templates/setup/debug_toolbar.tpl

2/ setup/clear_cache.tpl setup/clear_cache.tpl design/standard/templates/setup/clear_cache.tpl

3/ setup/quick_settings.tpl setup/quick_settings.tpl design/standard/templates/setup/quick_settings.tpl

All other templates listed means that they are **NOT** cached (Thanks to eZ Sytems France for the hint)

Use cache-blocks. You can use cascading cache blocks.

Compile the templates everytime you flush the cache. I did a Cron to make sure the templates were compiled at night.

	cd /var/www/yoursite/
	Php bin/php/eztc.php


Make sure you use the same encoding everywhere (eg: utf-8).

There is a thread in the forum about that.

<b>[The site.ini file::ContentSettings]</b>

CachedViewModes : "full; sitemap; pdf"
This tells which files should be cached so if you have only « pdf » as we did !! Only PDF files will be cached.

CacheThreshold : 7200
The cache is regenrated every 2 hours

StaticCache : Disabled

<b>[The site.ini file:: DatabaseSettings]</b>
UsePersistentConnection : enabled
This should speed up a bit the database access.

Transactions : enabled
I guess this slows down the speed but it gives more safety.

<b>[The site.ini file:: SearchSettings]</b>
DelayedIndexing :enabled
(make sure you run runcronjobs.php at night to index the new articles)

<b>[The site.ini file:: TemplateSettings]</b>
NodeTreeCaching :enabled
TemplateCompile : enabled
TemplateOptimization : enabled
TemplateCache : enabled
TemplateCompression : Disabled

<b>[The Server]</b>

<b>Hardware requirements:</b>
1 GB of RAM
Fast Hard disk (SCSI recommended)

1/ We have activated hdparm to enable UDMA. By default this is not activated on many distributions.

2/ I installed Zend Optimizer and set it with 128 MB of RAM! Zend Platform tells us that sometimes the Optimizer uses more than 80 MB or RAM!

3/ PHP.ini

- Install Zend Optimizer
- Put 256 MB of RAM for PHP!! (eZ France recommended it)

4/ Logrotate
On certain vhost logs (and others) I have realised that there was not log rotation with I think with a file as big as 200 MB it can be a performance drag every time a new entry is added to the file.

5/ Apache2
<IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 20
MaxRequestsPerChild 0

<b>[Please ADD recommendations if you have]</b>

6/ MySQL 4.1

Starting from MySQL 4.x there is some caching enabled.

# * Fine Tuning
key_buffer = 32M # 16M by default
max_allowed_packet = 16M # 16M by default
thread_stack = 128K # 128K by default
# * Query Cache Configuration
query_cache_limit = 12M
query_cache_size = 128M
query_cache_type = 1

<b>[Please ADD recommendations if you have]</b>

Yvan ROY

Thursday 20 April 2006 1:23:18 pm

As Denis said ealier in this thread, node.children and parent can avoid a couple of quries.
One exampe of folder, image and galleri templates using this and json to speed up
ez can be found here:

Do you see better speed with TemplateCompression=Disabled ??
And what impact do you get from turning on Udma ?
And have you tried ?

Thursday 20 April 2006 7:10:54 pm

Hi André,

Qbig-smile.gif Emoticono you see better speed with TemplateCompression=Disabled ??

It 's very hard to know the impact of the performance gain from modifying an option after an option. But regarding TemplateCompression, it says in the documentation that compression has a perfomance drag but that it does save space.

Q:And what impact do you get from turning on Udma ?

As there are lots of disk access from MySQL and Apache with eZ Publish; Udma is recommended. One thing that I have notified using UDMA (along other hdparm options) was a decrease in the system resources especially regarding the process kjounald (the journaling system) that dropped significantly!

Q:And have you tried ?

We did, then I switched to Zend Optimizer until I was told this morning to use APC. Therefore I have installed APC but I don't see perfomance gain.

Take care,


Thursday 20 April 2006 7:27:16 pm

Im not sure TemplateCompression actually works. When i have it on i dont see any compressed templates.

Theoretically compression can make the reading of templates faster because of their smaller size but it depends on each case...


Thursday 20 April 2006 7:58:54 pm

On a reasonably speced (i.e. enough RAM) dedicated Server, template compression is most likely detrimental as the templates live in cache anyway and are nearly instantaneously available whereas compressed ones need to be decompressed first which is comparably very expensive. And on such servers, I've generally seen eZ be more CPU bound than IO bound (at least with reasonably small databases that still fit into RAM).

On a shared hosting account the picture is less clear.

Thursday 20 April 2006 9:04:13 pm


Template compression works fine. Just enable it then compare size of dir var/(site)/cache/template/compiled with and without enabled compression. Difference is significant. Check also content of file after compression (don't preview it in MC, which decompress content before preview blunk.gif Emoticon. I think that bug can be closed.

Modified on Thursday 20 April 2006 9:05:23 pm by Łukasz Serwatka

Friday 21 April 2006 10:56:01 am

Ah, they are compressed. Darn editor. I was using 'less' but i didnt realise it decompressed files on the fly if it can... so, yes, reclose that bug. learn something every day, i do... happy.gif Emoticon

Personally i find the less I/O going on the better. If the CPU can take it then i would switch it on, and off if it cant. This flag does depend on hardware.


Thursday 27 April 2006 5:03:56 pm

Recent hardware and software (all recent stable versions of LAMP) upgrade in our primary hosting provider multiplied by our 3.7 version migration for all projects solved the speed problem to the extent when no errors occur with a slight yet acceptable delays from 1 to 3 seconds.

We are trying to investigate the major reasons further and locate past bottlenecks whether ours or providers', but it is now clear that timely and all-round upgrade is generally a fix for most problems happy.gif Emoticon

Friday 28 April 2006 12:23:04 pm


I think that has to be part of that great topic !

Wednesday 10 May 2006 10:34:36 pm

Here are 2 useful template functions which helps measure timings and generates statistics:



Monday 03 July 2006 4:11:50 pm

Hi, this thread has been very helpful in speeding up my general access pages. They still lag a little bit too much when they're not cached, but it's getting better. However, publishing is starting to become a real pain. I was hoping someone could offer some insight as my admin interface is very slow. See this example - this is from viewing Content Structure only:

Time accumulators:
 Accumulator	 Elapsed	 Percent	 Count	 Average
Load cache	0.4961 sec	4.3630%	12	0.0413 sec
FindInputFiles	0.1142 sec	1.0044%	12	0.0095 sec
Parse	0.0147 sec	0.1295%	2	0.0074 sec
Save Cache	0.0101 sec	0.0886%	2	0.0050 sec
Mysql Total				
Mysql_queries	2.3232 sec	20.4304%	739	0.0031 sec
Looping result	0.0898 sec	0.7896%	735	0.0001 sec
Template Total	10.8045 sec	95.0%	2	5.4023 sec
Template load	0.1505 sec	1.3238%	2	0.0753 sec
Template processing	10.6532 sec	93.6862%	2	5.3266 sec
Cache load	0.1080 sec	0.9499%	2	0.0540 sec
INI string conversion	0.0006 sec	0.0054%	2	0.0003 sec
String conversion	0.0002 sec	0.0014%	2	0.0001 sec
Total script time:	11.3711 sec	

That's probably hard to read but, the last line says it all - 11 seconds! That's way too much just to view things. When publishing an article it usually takes 30-60 seconds. Here's the details:

CPU: 2,4GHz Celeron
Memory: 512M
Disk space: about 30GB free

OS: Win XP
SQL: MySQL 4.1
WebServer: Apache 2
PHP: 4.4.0
Accelerator: eAccelerator with eaccelerator.shm_size="256"
eZ Version: 3.7.4

PreViewCache=disabled # Slows down publishing don't it?

TemplateCompression=disabled # caused me trouble before

DelayedIndexing=enabled # In fact, we don't use the search engine at all

I also switched the default tree menu with enhanced Ajax treemenu, extension called ezodcsm, saves a bit of time

From what I can gather, this should be the recipy for a relatively successful installation, however, with around 1000 nodes, the admin is becoming increasingly hard to work with. Any hints?

Monday 03 July 2006 4:43:07 pm

try the "[AJAX-TreeMenu] On demand tree menu"

it is known to reduce load times on larger eZ installations(many objects).

Modified on Monday 03 July 2006 9:31:12 pm by André R

Tuesday 04 July 2006 8:56:45 am

As I wrote I already use this extension. The problem however is more with the publishing and waiting times for POST requests in general. I really don't know what to do.

Tuesday 04 July 2006 9:01:32 am

In your case template processing takes 10s. Do you have any complex template code structures? How big is your content structure tree? Perhaps you should reduce amount of presented items using contentstructuremenu.ini

Tuesday 04 July 2006 1:02:45 pm

Well, I have reduced the number of nodes being fetched by using the ezodscm extension which replaces the content structure menu with an AJAX one. It's working fine. I haven't introduced any complex template code to the admin siteaccess. It's the standard admin design.

Friday 18 August 2006 1:57:01 pm

I have a little question to Yvan ROY comment about template cache.
Does his comment imply we should only see 3 "Loading template ... with resource ..." line in the debug output ?

I see this line for each template used in the page and I thought this was normal.
Is this the case and what should I check it if means templates are not correctly cached (Template cache option are enabled) ?

From Yvan ROY:

[Are the templates correctly cached]

Activate the Debug Output for the Template.

If your template is correctly cached you should only see 3 templates loaded:

1/ setup/debug_toolbar.tpl setup/debug_toolbar.tpl design/standard/templates/setup/debug_toolbar.tpl

2/ setup/clear_cache.tpl setup/clear_cache.tpl design/standard/templates/setup/clear_cache.tpl

3/ setup/quick_settings.tpl setup/quick_settings.tpl design/standard/templates/setup/quick_settings.tpl

All other templates listed means that they are **NOT** cached (Thanks to eZ Sytems France for the hint)

Friday 18 August 2006 2:15:12 pm

Here are some suggestions links for optimization:

Wednesday 30 August 2006 10:53:09 am

Two more server configuration articles by Bård Farstad that might influence performance:

Clustering in eZ publish 3.8
Server Architecture for eZ publish Hosting
Tuning MySQL for eZ publish


This thread has been providing a source of comprehensive perfomance guidelines as a result of our common efforts. Some checklists and overview articles were created along the way on the topic. My suggestion now would be to allocate a permanent place for this info and keep on adding to it.

For example, it can be a stand along chapter 'Performance optimisation' in , divided into specific topics such as server-side configuration, eZ configuration, templates, etc.

Anyone from eZ crew with access to this area supports the idea?

Modified on Thursday 31 August 2006 10:00:50 am by Denis Igin

Wednesday 11 October 2006 1:10:10 pm

Advice by Damien POBEL from this thread on eZ set-up with custom translation:

<i>install the PHP domxml module which should accelerate the generation of translation cache as translation file use XML documents</i>

Modified on Tuesday 07 November 2006 11:33:03 am by Denis Igin


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from