[TYPO3-project-4-3] 4.3.0 vs. 4.2.7

Rupert Germann rupi at gmx.li
Thu Jun 11 22:02:46 CEST 2009


hi Francois,

Francois Suter wrote:
> Thanks a lot for these extensive tests. The results are worrying. Did
> you run any profiling? If not, is it something you can do, since you
> already have such a complete test setup now?

besides testing pure throughput with siege or ab I did of course some php
and mysql profiling, too. 
the patches mentioned in TYPO3_4.3.0_vs_4.2.7.pdf are already a result of
this.
I did "php profiling" only concerning processing time values/ratios (and
function invocation counts) I didn't analyze the memory consumption yet.
(but control.php from eaccelerator showed me that 4.3 actually uses slightly
less eaccelerator memory. Means, it includes slightly less files than
4.2 -> thanks to the autoloader)
The zend studio profiler is a good tool to spot which functions need a
significant amount of processing time or are called very often. If I found
such a function I add a simple stopwatch to it and debug its parsetime and
debug_trail directly or write it to the great devlog ext (thanks
maintaining this, btw).

I do mysql profiling with JetProfiler (http://www.jetprofiler.com/) cool
thingy! It shows many helpful informations about whats going on inside the
mysql server while torturing it with siege or ab. Eg. how many full table
scans are done or how good the cache hit rate is.

I learned quite a lot about mysql indizes while using this tool ;-)

these tests resulted in what I call "TYPO3 4.3 patched" in the document. 
Changes:
* re-implemented old caching (caching framework not involved anymore),
* autoloader ux_ loading fixed,
* using serialized autoloader registry,
* use ACCESS_TIME in cache queries

Disabling the caching framework is no option, but the remaining 3 patches
might be worth a closer look (autoloader ux_ loading fix is already pending
in the corelist).

The next candidate to have a closer look to is the fe_user/groups
initialisation which eats up 30% of the time which is needed to render a
cached page. Always, at each request - no matter if a user is logged in or
not or loginmode is set to "disabled". According to this JetProfiler shows
that mysql spends more time in fe_seesions(_data) than in cache_pages when
delivering cached pages. 

greets
rupert




More information about the TYPO3-project-4-3 mailing list