This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

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

Friday 16 December 2005 7:22:49 pm

First and foremost, use a PHPAccelerator with plenty (128MB+ recommended) of RAM cache. And activate ViewCache (if you find pages getting cached incorrectly, tune their cache-blocks), TemplatCache, TemplatCompile.

I get cached page load times of below 0.15s with those settings on a 3GHz P4 (Linux or FreeBSD).

Modified on Friday 16 December 2005 7:24:46 pm by Gabriel Ambuehl

Saturday 17 December 2005 6:14:09 pm

Great start Gabriel, thank you! Anyone else? What's the second most important issue? I can keep track of this thread as an actual document with all the techniques.

Saturday 17 December 2005 7:58:35 pm

Hi Denis,

This is good topic blunk.gif Emoticon

If possible use $node.children array if you need access to children or $node.parent if you need access to parent object. If you will reduce count of fetches this can give you some additional performance gain. Write proper code without notices, warnings, use deboug output for development. If you can do something on 2 same ways, check which one is faster.

For better performance, you can replace complex template code with custom operators that do the same in PHP code. For example instead of fetching whole objects for creating dropdown list use custom tpl operator which returns SQL array. Much faster ...

Use {cache-block} for optimization your pagelayout. If possible, use static cache, this will give you really good performance.

For the best performance, use Linux and MySQL.

Modified on Saturday 17 December 2005 7:58:57 pm by Łukasz Serwatka

Saturday 17 December 2005 8:16:57 pm

Gabriel, just a note on our experience with FreeBSD. PHP uses one stat call for every element in the path of an included file. This is done to check permissions and safemode settings in PHP. On FreeBSD these stat calls are very expensive. eZ publish is very modular and has several included files needed for rendering a page. For this reason you will not get the same speed out of eZ publish running on FreeBSD as on Linux.

For some machines we have noticed quite much faster load times on Linux compared to FreeBSD. So it might be work looking into Linux as the performance is noticeably better there.

As a note I usually see 0.05 seconds of load time of a fully cached page in standard eZ publish on my laptop (1.8 GHz Pentium M, 1GB RAM).


Sunday 18 December 2005 12:00:33 am

While for political reasons I'm currently developping againt Linux (both 2.4 and 2.6), on similar spec'ed hardware I've noticed little difference between FreeBSD 4.11 and Linux 2.6 (Linux 2.4 isn't quite as good). However, I don't use safemode (it's an ugly, misguided hack with little security value when you come down to it). I also think that FreeBSD DOES cache the stat results if it got enough RAM to do so, so it shouldn't be that expensive (writes on UFS1 can be expensive because of the drives usually being synced instantly). Furthermore, claiming Linux is invariably faster isn't of much use without stating the filesystem in question (I've found JFS to be dog slow, for one and I wouldnt touch reiser, ever).

I don't manage getting much below 0.1s (nowhere close to 0.05s, anyway) on 3GHz P4/Athlon64 on either though. FWIW, there's a lot of variables involved. If you don't get below 0.5s something's likely wrong and might be tunable with proper cache settings/PHP setups, but if you dont get 0.1s over 0.2s it could mean your setup still is near it's peak.

I would love to see some formal benchmarks (especially once you get into big to huge sites with hundreds of thousand of nodes [1]) on different OSs

[1] Below that, throwing more hardware at it will let it scale pretty well to handle more users, but I'm not too sure what would happen with millions of nodes.

Tuesday 20 December 2005 10:42:11 am

How about system software environment configuration tips aside accelrators - PHP/DB/etc.? Does it have any significant influence on overall performance?

Tuesday 20 December 2005 11:15:53 am

We need to agree on the variables involved with optimisation. I've knocked up a small list
which should be expanded.


CPU         : 
Memory      :
Disk space  :

OS               :
SQL             :
WebServer    :
PHP             :
Accelerator   :
eZ Version    :






We also need to have several aims. Most of the site.ini settings here will boost speed *after* cache has been created. But, for example, DelayedIndexing helps to speed up the publishing process.

So, some priorities:

1. Browsing site.
2. Publishing.
3. Building cache after clearing.

Please add to this.


Modified on Wednesday 08 February 2006 12:31:09 pm by Paul Forsyth

Monday 09 January 2006 12:34:35 pm

Stolen here from Kåre:

It's extremly important you optimize the pagelayout when dealing with high traffic sites. You can check/controll this by counting the number of SQL queries for a cached page in the debug output. There should not have more than 3 SQLs for a cached page.

Sorry for being stubborn, just keep my eyes open for hints on the matter happy.gif Emoticon

Thursday 12 January 2006 6:19:01 pm

Some basic performance notes from the requirements page at :

- For the best performance, we recommend using Linux and Mysql. Some other factors that may influence the performance of your site are:
- The number of page views per unit time.
- The number of concurrent users.
- The number of nodes. This can affect search and navigation speed when you have several hundred thousand nodes.
- Update frequency, e.g. how often your content is changed.
- The complexity of your templates. (For better performance, you could replace complex pieces of template code with custom operators that do the same in PHP code.)

I still do not loose hope this thread will revive and eventually form a doc happy.gif Emoticon

Friday 13 January 2006 11:22:29 am

Hi all

Nice thread, let me just add this link.

It is an contribution on how to use the HTTrack website copier to make an copy of your eZ website and then use Apache (or anyother webserver) to serve your HTML files (copied form our eZ installation). This will however leave the user login and search unusable.

Or you could use the staticcache functionality of eZ as described in:


Modified on Friday 13 January 2006 11:23:51 am by Tore Skobba

Thursday 19 January 2006 1:20:09 pm

Paul Forsyths suggestion to do:





Unfortunately these settings messed up my whole site. Images and text disappeared and now, after removing those settings I cannot get the images back...

Edit: After manually handling the cache I now have everything back happy.gif Emoticon But why did stuff disappear from those settings?

Edit 2: It seems caching removes $node from my pagelayout.tpl. So in order to make use of caching I need to find a way to access these values in the pagelayout without touching $node:


Modified on Thursday 19 January 2006 1:27:26 pm by Christian Johansen

Thursday 19 January 2006 2:20:44 pm

It can be a shock when this happens.

Have a read of this doc:

to explain where variables change blunk.gif Emoticon


Thursday 19 January 2006 3:04:30 pm

Hi all,
Would UsePersistentConnection=enabled gain some more speed? Documentation says something about unwanted effects in the past. Is that information still relevant?

Thursday 19 January 2006 3:44:19 pm

I dont think you would see much speed here except if your use of MySQL was exceptionally high. MySQL use is fast. The use of PHP is the biggest speed drawback.


Thursday 19 January 2006 6:58:11 pm

Some performance metrix definitions can be found in this whitepaper with a reference to where cluster environment is described as yet another option to speed up your system.

Thursday 02 February 2006 11:26:59 am

Some excerpts from the old documentation on the topic. Hope most of them are still valid for 3.6+, caching issues omitted due to significant improvement in newer versions:
In Virtual Host setup the following Apache httpd.conf directives can influence performance:

php_value magic_quotes_gpc 0
php_value magic_quotes_runtime 0
One of the instruments to control the availability of system resources is Policy Omit Statements designed to speed up the system in service requests available for the world, e.g. PolicyOmitList[]=content/read. Use them to grant unlimited access to the following system functions, even if you are going to setup a rather paranoic authorization regime later on:


Place these statements in your - global - site.ini.append file (settings/override - directory), if you don't have good reasons to make more sophisticated use of Policy Omit Statements in different Site Access - definitions.
Because of performance reasons it's still advised to use the Apache module version of PHP if you have the possibility to do so, not CGI version of PHP.
If you need to have charset conversion for some reason you should compile PHP with the mbstring extension, this will go alot faster than the built in conversion done in eZ publish. If you don't need to do charset conversion you should make sure that eZ publish uses the same charset all over. The following settings/files should be the same.

[DatabaseSettings] Charset=iso-8859-15
[CharacterSettings] Charset=iso-8859-15
[CharsetSettings] DefaultTemplateCharset=iso-8859-15

You can remove the content_read workflow from OperationSettings to get a performance improvement. Recommended setting, if you don't need content read workflows.

[OperationSettings] AvailableOperations=content_publish;shop_confirmorder;shop_checkout
PHP Accelerators configuration tips.
Make sure PHP stores sessions operate correctly because it's used to speed up access to the site by storing often used information.

Thursday 02 February 2006 11:31:59 am

Comments for an speed boost and lowering number of fetches / sql quries from

If you need to display some information about the children or grand children in the node template this is possible with $node.children and $node.children.0.children (if any children exist this will loop thru any children of your first child)
To loop thru children:

{foreach $node.children as $nodechild}

The same thing can be done with parents: $node.parent

Remember to only use $node in node templates and not in your pagelayout file.
Because it's not available on cached pages (ViewCaching).

Tuesday 14 February 2006 2:23:11 pm

Some hardware impact on perfromance (hard drive speed and balancing, raid, file system and allocation) are discussed in this thread:

Major conclusions include:

- Lukasz: I don't think so that splitting content between two disks will give you additional performance ... Just choose the fastest disk and keep data on it.
- Gabriel: I'd venture to guess that ezpublish will likely NOT be disk speed limited very highly as you will usually be able to fit quite a lot of stuff into disk cache if you have any sane amount of RAM in a box

Monday 06 March 2006 4:51:09 pm

If eZ is used as the home page, you can preprocess it - which just converts it into an HTML image.

That will allow you to have a faster home page.

There is an article at Dr. Dobb's Journal, and supporting code at

I have used this general approach on some very high traffic homepages, with great success.

In addition, I used cache-blocks, and for very high speed content delivery, created specialized templates that had only enough code to deliver the content (single streamlined CSS, very limited HTML).

Another approach is to use eZ to create PHP that can deliver the content dynamically (this works well when the content is a component of another page).

Tuesday 07 March 2006 4:12:15 pm

@Betsy Gamrat > Sorry but I don't see any benefit in this approach compared to the natively supported static cache in eZ.


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

36 542 Users on board!

Forums menu

Proudly Developed with from