Wednesday 18 May 2005 2:25:08 pm - 66 replies
I tested a little eZ publish performance on Windows XP Professional and here are my results:
CPU: Athlon XP 3200+ (Burton) ~2195 MHz
Memory: 1 GB (2x 512MB dual channel)
Hard disk: IDE ATA 133
PHP 4.3.11 (DOM XML, MB STRING), Apache 1.3.33 (mod_php), MySQL 4.1.11, eAccelerator 0.9.2a
"First run" time test (empty var/cache, var/plain/cache dirs ):
eZ publish 3.5.2 "Plain" installation (english language) with all installed additional packages:
Time accumulators: Accumulator Elapsed Percent Count Average ini_load Load cache 0.2499 sec 2.9907% 16 0.0156 sec Mysql Total Mysql_queries 0.1191 sec 1.4253% 40 0.0030 sec Looping result 0.0056 sec 0.0665% 39 0.0001 sec Template Total 8.1402 sec 97.4% 2 4.0701 sec Template load 2.5195 sec 30.1549% 2 1.2597 sec Template parser: create text elements 0.1627 sec 1.9475% 155 0.0010 sec Template parser: remove whitespace 0.0430 sec 0.5144% 155 0.0003 sec Template parser: construct tree 0.8273 sec 9.9018% 155 0.0053 sec Template load and register function 0.0048 sec 0.0576% 9 0.0005 sec Template processing 5.6203 sec 67.2677% 2 2.8101 sec override Cache load 0.2537 sec 3.0369% 26 0.0098 sec Matching rules 0.0021 sec 0.0246% 4 0.0005 sec Sytem overhead Fetch class attribute name 0.0000 sec 0.0000% 0 0.0000 sec class_abstraction Instantiating content class attribute 0.0005 sec 0.0056% 10 0.0000 sec XML Image XML parsing 0.0006 sec 0.0071% 1 0.0006 sec General INI string conversion 0.0099 sec 0.1185% 42 0.0002 sec String conversion 0.0072 sec 0.0864% 46 0.0002 sec String conversion w/ mbstring 0.0032 sec 0.0379% 46 0.0001 sec Total script time: 8.3551 sec
On default eZ publish configuration with compiled templates and cached content was:
Time accumulators: Accumulator Elapsed Percent Count Average ini_load Load cache 0.0223 sec 18.3677% 10 0.0022 sec Mysql Total Mysql_queries 0.0010 sec 0.8183% 1 0.0010 sec Looping result 0.0000 sec 0.0410% 1 0.0000 sec Template Total 0.0473 sec 38.9% 1 0.0473 sec Template load 0.0127 sec 10.4802% 1 0.0127 sec Template processing 0.0342 sec 28.1551% 1 0.0342 sec override Cache load 0.0091 sec 7.4591% 1 0.0091 sec Total script time: 0.1216 sec
I would like to compare this results to your hardware/software configuration.
What are your results?
Modified on Wednesday 18 May 2005 2:32:28 pm by Łukasz Serwatka
Friday 04 November 2005 4:19:10 pm
Here's a few tips for your pagelayout:
- You can safely add the <i>ignore_content_expiry</i> to several of your cache-blocks.
- Looks like you might be able to use cache block with keys=(node_id, user_id) ( I'm not sure though, as I do not know exactly what is displayed there ).
- Try using <i>subbtree_expiry</i> where you can not use the <i>ignore_content_expiry</i> option.
See also : http://ez.no/doc/ez_publish/techn..._functions/miscellaneous/cache_block for more info.
Modified on Friday 04 November 2005 4:20:42 pm by Kåre Køhler Høvik
Friday 04 November 2005 5:00:15 pm
Thanks for your reponse.
We'll tweak the cache blocks and also see if we can reduce them. But I feel we have a more fundamental issue to deal with first.
You can see from pagelayout that pretty much everything is cached - so you'd think on consequetive loading of a page the load time would be quick, but we see template processing times of 1-2 secs.
I dont understand why this processing time occurs when the compile/cache is enabled - for me this seems to be the problem. We have enabled cache and compile, but when the pages load there seems to be some very heavy template processing occuring.
Is there any other way of debugging whats going on the pinpoint the issue?
Monday 07 November 2005 12:48:21 pm
I wonder if this could give an insight into the problem. I notice that if I try to run:
[onewaggr@web3 php]$ ./bin/php/eztc.php -s 2gc_intra -bash: ./bin/php/eztc.php: No such file or directory
[onewaggr@web3 php]$ ./bin/php/eztc.php -bash: ./bin/php/eztc.php: No such file or directory
It wont execute. If it won't execute via shell then perhaps its not doing so when executed via the admin panel?
What are you thoughts? Does this point to a ini misconfig somewhere?
Monday 07 November 2005 12:53:08 pm
Have just noticed the same with runcronjobs.php - first it was a perm issue, then once that was solved it gives the same error as with eztc:
[onewaggr@web3 htdocs]$ ./runcronjobs.php -bash: ./runcronjobs.php: Permission denied [onewaggr@web3 htdocs]$ ./runcronjobs.php : No such file or directory [onewaggr@web3 htdocs]$ ./runcronjobs.php
Monday 07 November 2005 4:38:26 pm
Yes, that worked great for runcronjobs - but for eztc.php I now get:
[onewaggr@web3 php]$ php eztc.php -s intranet PHP Warning: main(lib/ezutils/classes/ezcli.php): failed to open stream: No such file or directory in /disk1/www/sites.oneworldmarket.org/dev1.oneworldmarket.org/htdocs/bin/php/eztc.php on line 37 PHP Warning: main(): Failed opening 'lib/ezutils/classes/ezcli.php' for inclusion (include_path='.:/usr/local/lib/php') in /disk1/www/sites.oneworldmarket.org/dev1.oneworldmarket.org/htdocs/bin/php/eztc.php on line 37 PHP Warning: main(kernel/classes/ezscript.php): failed to open stream: No such file or directory in /disk1/www/sites.oneworldmarket.org/dev1.oneworldmarket.org/htdocs/bin/php/eztc.php on line 38 PHP Warning: main(): Failed opening 'kernel/classes/ezscript.php' for inclusion (include_path='.:/usr/local/lib/php') in /disk1/www/sites.oneworldmarket.org/dev1.oneworldmarket.org/htdocs/bin/php/eztc.php on line 38 PHP Fatal error: Undefined class name 'ezcli' in /disk1/www/sites.oneworldmarket.org/dev1.oneworldmarket.org/htdocs/bin/php/eztc.php on line 40 [onewaggr@web3 php]$
Monday 07 November 2005 4:57:36 pm
Thanks, I can now run the script - unfortunately it hasnt made any difference to the page load speeds - we're still dealing with 7-12 sec page load times.
I'm at a bit of a loss as to how to progress this... We still get huge page template processing times (6 secs) when the page loads even though it should now be pre-compiled.
Monday 07 November 2005 8:13:12 pm
you didn't answer the question if you are running an php accelerator like eaccelerator.
If you don't know it, take a look at the system information within the admin siteaccess.
As already mentioned you need to install it to decrease your load times.
If you have already installed one, I would check the permissions to the directory where the cache files are stored.
Tuesday 08 November 2005 10:23:48 am
No, we are not running an accelerator yet - I'm trying to get one installed on our production box via our ISP.
However, the reason I have still been persuing this speed issue is that - even if the accelerator doubles the performance - we would still have 4-6 sec page load times.
Tuesday 08 November 2005 5:16:10 pm
I dont see perm errors in the logs - there is a lot of other noise though:
Seems to be a lot of issues relating to extensions? Maybe these are slowing down the load time?
Wednesday 09 November 2005 11:36:34 am
Looks like you've got some problem on the template code.
P.S. I don't know if you use dreamweaver, but by experience, I find that you get a way more efficient code by writing it "by hand" with a text editor.
Wednesday 09 November 2005 5:17:05 pm
Many thanks for the input - it has shaved some time off the loading (about .5 sec).
I'm really pleased to say we have it solved Got some tips from PaulF and have added additional lines to our sites.ini file. Before we had:
[TemplateSettings] TemplateCache=enabled TemplateCompile=enabled
now we have:
[ContentSettings] ViewCaching=enabled [TemplateSettings] NodeTreeCaching=enabled TemplateCache=enabled TemplateCompile=enabled TemplateOptimization=enabled
...and its loading really quick!
Thanks for the input on this.
Wednesday 09 November 2005 9:13:47 pm
Good to see that you solved your problem
Could you share with other users that optimization tips?
All settings important for performance which you mention in post are enabled by default in settings/site.ini file and should be never disabled (unless you know what you are doing) on production site (someone miss something? .
Modified on Wednesday 09 November 2005 9:16:54 pm by Łukasz Serwatka
Sunday 13 November 2005 5:44:41 pm
We have a much better system, but its still not as good as I'd like it. The server is:
OS Name Microsoft(R) Windows(R) Server 2003, Standard Edition Version 5.2.3790 Service Pack 1 Build 3790 Other OS Description Not Available OS Manufacturer Microsoft Corporation System Name xxxxxxxxxxxxx System Manufacturer Dell Computer Corporation System Model PowerEdge 4600 System Type X86-based PC Processor x86 Family 15 Model 2 Stepping 4 GenuineIntel ~2387 Mhz Processor x86 Family 15 Model 2 Stepping 4 GenuineIntel ~2387 Mhz Processor x86 Family 15 Model 2 Stepping 4 GenuineIntel ~2387 Mhz Processor x86 Family 15 Model 2 Stepping 4 GenuineIntel ~2387 Mhz BIOS Version/Date Dell Computer Corporation A06, 06/06/2002 SMBIOS Version 2.3 Windows Directory C:\WINDOWS System Directory C:\WINDOWS\system32 Boot Device \Device\HarddiskVolume1 Locale United Kingdom Hardware Abstraction Layer Version = "5.2.3790.1830 (srv03_sp1_rtm.050324-1447)" User Name Not Available Time Zone GMT Standard Time Total Physical Memory 2,047.45 MB Available Physical Memory 1.47 GB Total Virtual Memory 3.85 GB Available Virtual Memory 3.45 GB Page File Space 2.00 GB Page File C:\pagefile.sys
As youcan see, its a beast! This site should be flying.
To get it to its current state (which is not too bad) we have:
- added the site.ini tweaks as per above (they weren't in siteacesss) - this gave the biggest boost by a long way
- changed the caches so we just have 2 big caches (both uri), one containing everything above maincontent, and one containing everything below. We'll have to break this up into a few more blocks as we have a bookmark function on the page as this cant be in the block.
- added eaccelerator, tho' so far we havent noticed much improvement
- we have php.ini at 28m memeory alloc (is there a benefit to increasing this further?)
Loading the homepage after its been loaded previously following as cache refresh we get:
Timing points: Checkpoint Elapsed Rel. Elapsed Memory Rel. Memory Module start 'content' 0.0000 sec 0.3191 sec 0.0000KB 0.0000KB Module end 'content' 0.3191 sec 0.0646 sec 0.0000KB 0.0000KB End 0.3836 sec 0.0000KB 0.0000KB Total runtime: 0.4480 sec Time accumulators: Accumulator Elapsed Percent Count Average ini_load Load cache 0.0829 sec 2.3245% 12 0.0069 sec Mysql Total Mysql_queries 0.0170 sec 0.4759% 14 0.0012 sec Looping result 0.0009 sec 0.0261% 7 0.0001 sec Template Total 0.3639 sec 10.2% 3 0.1213 sec Template load 0.0492 sec 1.3798% 3 0.0164 sec Template processing 0.3137 sec 8.7933% 3 0.1046 sec override Cache load 0.0412 sec 1.1551% 5 0.0082 sec Sytem overhead Fetch class attribute name 0.0000 sec 0.0000% 0 0.0000 sec Total script time: 3.5678 sec
Another page example is:
Timing points: Checkpoint Elapsed Rel. Elapsed Memory Rel. Memory Module start 'content' 0.0000 sec 0.2302 sec 0.0000KB 0.0000KB Module end 'content' 0.2302 sec 0.0270 sec 0.0000KB 0.0000KB End 0.2573 sec 0.0000KB 0.0000KB Total runtime: 0.3218 sec Time accumulators: Accumulator Elapsed Percent Count Average ini_load Load cache 0.0912 sec 5.3060% 13 0.0070 sec Mysql Total Mysql_queries 0.0222 sec 1.2947% 16 0.0014 sec Looping result 0.0011 sec 0.0618% 11 0.0001 sec Template Total 0.2331 sec 13.6% 3 0.0777 sec Template load 0.0497 sec 2.8905% 3 0.0166 sec Template processing 0.1825 sec 10.6237% 3 0.0608 sec override Cache load 0.0333 sec 1.9372% 3 0.0111 sec Sytem overhead Fetch class attribute name 0.0000 sec 0.0000% 0 0.0000 sec XML Image XML parsing 0.0101 sec 0.5881% 1 0.0101 sec class_abstraction Instantiating content class attribute 0.0001 sec 0.0042% 1 0.0001 sec General String conversion 0.0006 sec 0.0358% 2 0.0003 sec String conversion w/ mbstring 0.0003 sec 0.0161% 2 0.0001 sec Total script time: 1.7179 sec
AFAIK, we should be getting better results than this, tho' thanks god the system is now useable.
On another tip, I'm now scared of ever clearing the template cache - as soon as I do so the client has to deal with massive page load times when they view the page first time.
Is there no way of getting ez to re-generate all the pages via a script (PaulF was talking about wget to 'ping' all your site pages) - eztc.php gets some way there, but it doesnt get rid of these horrible initial load times...?
Any thoughts on this?
Sunday 13 November 2005 10:02:25 pm
Steve, which version of eZ publish do you use? This can be weird but ... have you tried with other version of eZ publish then your site uses?
Just test with plain installation of newest version.
Look also on:
You can also get better results with static cache. Check documentation and forum for more info.
Modified on Sunday 13 November 2005 10:14:31 pm by Łukasz Serwatka
Sunday 13 November 2005 11:42:14 pm
We run unix boxes as a norm - this happens to be an Intranet for a client (to run on internal box) and their pc support only run windows however, worth noting we've seen the same issues on the development version of the site on our unix box.
The version of Ez on the site is 3.6.0 - I'll look into trying another version.
I'll look into the contrib crawler, could be just what we're after.
You must be logged in to post messages in this topic!