eZ Community » Forums » Setup & design » Improving eZ publish environment and...
expandshrink

Improving eZ publish environment and performance

Improving eZ publish environment and performance

Tuesday 11 July 2006 12:36:46 pm - 16 replies

Here are some of the conclusions/notes about improving the eZ publish deployment environment.

<b>1. Apache</b>

<b>1.1. Version</b>
According to Bertrand Dunogier's article "eZ publish: Performance Best Practices" ( http://ez.no/community/articles/ez_publish_performance_best_practices ), Apache 1.x should be used. If 2.x version has to be used, it should be run under pre-fork mode, which prevents Apache 2 from using threads.

Intel ICC compiled Apache should be used (Bård Farstad: eZ publish Performance.pdf). Apache/PHP/APC compiled with the ICC compiler shows eZ publish template processing is faster from 17.4% to 19.6%. Total script runtime measured with ab ranged from 6.3% to 12.7% faster. ( Bård Farstad: http://papelipe.no/tags/ez_publis...ntel_compiled_icc_apache_php_and_apc )

<b>1.2. configuration</b>

Correct configuration of the following parameters is extremly important for good performance.

* MaxClients - this parameter sets the limit of total number of worker processes - it defines how many simultaneous requests can be supported. The more processes apache is allowed to run, the more simultaneous requests it can serve. As you increase that number, you increase the amount of RAM that Apache will take. So, the optimal value depends on the resorces of the server (RAM).

MaxClients can be calculated by the following formula:

MaxClients = (TotalRam - MSRPC) / (MaxProcessSize - MSRPC)

TotalRam - estimated total RAM available to the Apache
MSRPC - Minimal Shared RAM per Child

Check http://modperlbook.org/html/ch11_01.html for more explanations and examples.

If MaxClients is set too high, this will cause the server to start swapping and become unresponsive.

If MaxClients is set to low, connections will be unnecessarily queued (and maybe some of them will time-out), while server resources are left unused.

Any connection attempts over the MaxClients limit will normally be queued, up to a number based on the ListenBacklog directive ( http://www.apacheref.com/ref/http_core/ListenBacklog.html )

* KeepAlive - Turn On KeepAlive. It allows multiple requests to be sent over the same TCP connection so it reduces the overhead of frequent connects.

* KeepAliveTimeout
If server oftenly hits the MaxClients limit, KeepAliveTimeout should be reduced (default is 15 seconds, try with 2-6 seconds). This will allow Apache to terminate the connection soon enough and to be able to handle other queued connections. If there are a lot more clients than available apache children, KeepAlive On will decrease performance and should be turned off.

* MinSpareServers (default 5). It takes time to start the apache process which is ready to serve incoming requests. So if server load varies, this should be set to higher value to assure quicker response in that situations.
* MaxSpareServers (default 10). Keeping it low allows OS to use RAM for other tasks. Could be kept higher if it's a dedicated machine.
* StartServers (default 5). If it is set to high, it will assure that if you get a high load just after the server has been restarted, the fresh servers will be ready to serve requests immediately.
( http://modperlbook.org/html/ch11_03.html )

* MaxRequestsPerChild. Sets the limit on the number of requests that an individual child process can handle during its lifetime. Setting to non-zero value solves memory-leakage problems, by forcing the apache to restart child process. ( http://modperlbook.org/html/ch11_02.html )
I am not sure what's the best practice here regarding eZ publish. Please advise.

* MaxKeepAliveRequests: how many total requests a client can issue across a single connection. Please advise is there any need to change the default value (100).

Some methods how to determine correct values of above options can be found at http://www.apacheweek.com/features/mod_perl14

<b>1.3. Modules</b>
Only required modules should be loaded. This reduces memory footprint. For instance, if Perl or CGI isn't used, get rid of it.

<b>2. PHP</b>
<b>2.1. Version</b>
eZ publish requires PHP 4.3.x for the 3.6 branch, PHP 4.4.x for the 3.7+ branch
Use Intel ICC compiled binary.
Statically compiled PHP module is faster than a DSO module for about 10% ( http://ez.no/community/blog/php_as_dso_or_as_static_php_module )
Compile with --disable-memory-limit to gain some more speed (Derick Rethans on ez forum)

<b>2.2. PHP extensions</b>

Required PHP extensions for eZ publish)
- session
- mysql or pgsql
- gd2 or the ImageMagick program

Optional PHP extensions
- gd2 with FreeType support
- zlib
- mbstring
- exif
- domxml (this will speed up performance in some cases)

<b>2.3. Configuration</b>

Required:
- max_execution_time should be set to at least at least 30 (300 recomended)
- memory_limit should be set high enough (more than 64 MB is recommended) (Bertrand Dunogier). I have expirienced very large memory consumption when using ezodcsm (I had to set memory_limit to 384 MB)
- Safe mode should always be disabled (safe_mode Off)
- open_basedir ""
- magic_quotes_runtime Off
- allow_url_fopen On
- file_uploads On
- AcceptPathInfo On (only for Apache 2)

Optional:
- register_globals Off
- magic_quotes_gpc Off

(Please notify if something is missing)

<b>3. MySQL</b>

Intel ICC compiled binary are allready availble for download (Linux Intel C/C++ compiled section)
http://dev.mysql.com/downloads/mysql/4.1.html
http://dev.mysql.com/downloads/mysql/5.0.html
Some issues with stability have been reported with the Intel CC compiled version.

Comparison between GCC compiled vs. Intel ICC compiled MySQL when inserting objects into eZ publish
( Bård Farstad: http://papelipe.no/tags/ez_publis...ter_running_on_intel_optimized_mysql )

In order to use UTF-8 use MySQL 4.1 or later, previous versions only support the ISO character set.

<b>3.1. Tuning</b>
(Bård Farstad: eZ publish Performance.pdf)
- Re-compile with optimization
- Optimize settings
- Key buffer
- Table cache
- Sort buffer
- Query cache
- Max connect ions
- No flush at commit
- InnoDB buffer pool size
- InnoDB additional mem size
- Log buffer size

*Edit: This is now an article: Tuning MySQL for eZ Publish - http://ez.no/community/articles/tuning_mysql_for_ez_publish

<b>4. Opcode cache (eAccelerator / APC configuration)</b>

<b>4.1. eAcceleator</b>
I suppose that eAccelerator can also be compiled with the ICC compiler, but didn't try it (i am using the 0.9.4 binary release).

<b>4.2. eAccelerator configuration</b>
Adjust eAccelerator options (which are configured through php.ini). This is how I'm currently using it (please notify if you have any configuration advices here):

 eaccelerator.shm_size="128"
 eaccelerator.cache_dir="/home/eaccelerator"
 eaccelerator.enable="1"
 eaccelerator.optimizer="1"
 eaccelerator.check_mtime="1"
 eaccelerator.debug="0"
 eaccelerator.filter=""
 eaccelerator.shm_max="0"
 eaccelerator.shm_ttl="1200"
 eaccelerator.shm_prune_period="0"
 eaccelerator.shm_only="0"
 eaccelerator.compress="1"
 eaccelerator.compress_level="9"
 

Explanaton of this parameters can be found on http://eaccelerator.net/wiki/Settings.

To be effective, eaccelerator should be able to allocate enough memory (shm_size). If you can't set shm_size to more than 32 MB, read the http://eaccelerator.net/wiki/Faq.

<b>4.3. APC</b>
Compile APC with the ICC compiler.
I didn't use APC. Please notify if you have better results or better control with APC (or any other pros/cons).

<b>4.4. Zend Optimizer</b>
Although eAccelerator works with Zend Optimizer, it won't give any extra performace. So, Zend Optimizer should be loaded ONLY if you have to run encoded PHP scripts. Some performance comparisons between Zend Optimizer and eAccelerator can be found on http://blog.robinz.info/archives/...optimizer-and-eaccelerator-together/

<b>5. Squid Cache</b>
(from the Bård Farstad: eZ publish Performance.pdf)
- Cache CSS, JavaScript , images and files
- Cache complete XHTML pages
(didn't use it yet, but planning to)

<b>6. HDD/filesystem tuning</b>

<b>6.1. noatime option</b>
(Bård Farstad: eZ publish Performance.pdf). Effect of using noatime is explained here: http://www.faqs.org/docs/securing/chap6sec73.html

<b>6.2. hdparm</b>
Default Linux installs are also notorious for setting hard disk default settings which are tuned for compatibility and not for speed. Use the command hdparm to tune your Linux hard disk settings. ( http://phplens.com/lens/php-book/optimizing-debugging-php.php )

So girls & guys, share your information happy.gif Emoticon

<b>Resources</b> (except allready mentioned)
http://httpd.apache.org/docs/1.3/misc/perf-tuning.html
http://www.howtoforge.com/configuring_apache_for_maximum_performance
http://virtualthreads.blogspot.com/2006/01/tuning-apache-part-1.html
http://emergent.urbanpug.com/?p=60
http://www.perlcode.org/tutorials/apache/tuning.html
http://linuxgazette.net/123/vishnu.html
http://blog.coomanskristof.be/2006/07/07/ezpublish_requirements/
http://ez.no/content/download/134...ile/ez2006_ezpublish_performance.pdf

Modified on Tuesday 11 January 2011 9:55:32 am by Nicolas Pastorino

Tuesday 11 July 2006 12:56:34 pm

Vjeran, nice summary blunk.gif Emoticon

Tuesday 11 July 2006 6:04:15 pm

Very good indeed! This article should get a permanent place on the ez.no site.

Monday 24 July 2006 10:48:41 am

I agree, this thread should be used to update a performance pdf document available on the community. It's always boring and time consuming to search for that kind of information in different places. One document with paragraphs just like that one and regular updates should do it !

This is great work !

Monday 24 July 2006 10:55:17 am

Another useful reference might be this:

http://www.ipersec.com/index.php?q=en/bench_ea_vs_apc

Paul

Wednesday 16 August 2006 1:56:57 am

Great post - thanks Vjeran.

I agree that this would be useful as a standalone "checklist" document. We're in the middle of publishing a series of performance articles right now. After we're finished, with Vjeran's permission, I'll look at updating this checklist with information from those articles and publishing it as a reference document.

In the meantime, I've added comments that point to this forum thread from all the relevant articles, so hopefully this will be easy for people to find.

Wednesday 16 August 2006 7:32:33 pm

Hi Jennifer,
of course I agree happy.gif Emoticon

It would be also nice to include some conclusions from this thread http://ez.no/community/forum/developer/php_modules_needed_fo_ez_3_8_1

Thanks for the feedback!

Thursday 17 August 2006 12:33:12 pm

Yes, the summary post would be usefull as the separate document. But only after it's completed, that is when the "Still unanswered" and "Still under investigation" parts are resolved.

Tuesday 22 August 2006 2:28:20 pm

Great summary! Thanks for makin' it!

Monday 04 September 2006 5:32:13 pm

Some additions to my first post:

<b>gcc version and flags</b>
If php is compiled with the gcc compiler, it seems that GCC 4.1.0 produces slightly slower code than GCC 3.4.5. Sebastian Bergmann benchmarked the PHP 5.1 with gcc 3.4.5, gcc 4.0.2 and gcc 4.1.0 (I suppose that results with php4 would be similar). Check out his post: http://www.sebastian-bergmann.de/...66-PHP-5.1-GCC-Benchmark-Update.html

Also, you can set some gcc flags for better performance.
Example:

export CFLAGS="-O3 -pipe -mcpu=pentium4 -march=pentium4 -fomit-frame-pointer"
export CXXFLAGS="${CFLAGS}"
export MAKEOPTS="-j2"
export LDFLAGS="-Wl,-O1"

( from http://forums.ev1servers.net/printthread.php?t=48880 )

<b>Zend Optimizer</b>

Disable any unnecessary optimization passes by zend optimizer if you are using it together with the eAccelerator (for running encoded PHP scripts).
Just put in your php.ini:

zend_optimizer.optimization_level=0

 

Modified on Monday 04 September 2006 6:09:14 pm by Vjeran Vlahovic

Tuesday 10 October 2006 12:44:18 am

Hi,

I'm not an eaccelerator expert but as this <b>eaccelerator.compress_level="9"</b> is about compression, wouldnt it be more effective to have it set to 0 ?
Compression means that you'll have to decompress at a given moment. Or...?

Tuesday 10 October 2006 12:50:04 am

Hi,

Yes, but on the other hand, the files are smaller and could therefore load faster, depending where is the bottleneck, IO bound or CPU.

For what I saw, not a big difference in speed with compress =7, huge difference on the size of the cache.

YMMV.

X+

Saturday 30 December 2006 8:54:58 am

Thanks Vjeran for such a wonderful checklist. You covered almost everything for improving the eZ environment and performance... thanks for it.

Tuesday 03 July 2007 2:37:47 am

Great!
Thanks!

OnlyBlue

Tuesday 13 November 2007 11:32:01 pm

eaccelerator.check_mtime="1"

If you set this to sero, you will have faster pages and better throughput on high loads.
But it means your ea cache file is not refreshed when the underlying php page is changed (eg. as regenerated by eZ caching mechanism), so you will have to do some tuning / set up some scripts to do it.

domxl is HIGHLY recommended

Apache MaxRequestsPerChild: I usually set it to 5000 - 10000. It is just a safety measure against memory/resource (eg. db connections) leaks. If you set it too low, when traffic surges you will have a lot of useless recycling of apache processes (although using big Min/Maxspareservers will alleviate the problem of apache processes being recycled at the very moment they are needed)

Wednesday 05 December 2007 8:28:13 am

Hi Gaetano,

Do you have the tuning code you mention in a public place ?

X+

Wednesday 05 December 2007 10:18:48 am

If you use APC like I sometimes do ( easier to install on *nix, and about the same performance ), hers the similar setting:

apc.stat = "0"

apc.stat is the same as eaccelerator.check_mtime, basically if you want APC to check if the file has changed or not. Only enable this on production servers where php ( eZ Publish / extensions ) files never change.

apc.file_update_protection = "0"
apc.include_once_override = "1"

apc.file_update_protection on the other hand is how many seconds APC should wait until it flushes cache for a changed file, protecting against the delay svn up and other update methods has when updating files.

I have not tested apc.include_once_override extensively, but it might give a noticeably speed up for eZ Publish 3.x installs since ezp 3.x has a lot of include_once calls...

Modified on Wednesday 05 December 2007 10:20:34 am by André R

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from