[TYPO3-v4] Minutes from the 20th Skype meeting of the release 4.5 team

[Christian Kuhn]

Hey,

On 11/29/2010 11:32 PM, Xavier Perseguers wrote:
> Does someone has experience on using Extbase + Fluid in FE with full
> feature set? I mean not only for displaying data but for modifying them
> too? Actually even for displaying only, I've seen _much_ slower
> rendering than with standard methods and I guess it would be wise to
> have either some performance round on it too or at least some special
> documentation on how tweaking the server/php/... or the model to speed
> it up. Lazy loading for instance is not the definitive solution when one
> has to show a few attributes coming from "the whole domain" on a summary
> listing (aka LIST in tt_news).

No real numbers ahead in the post, furthermore I'm mixing up several 
things ...

-- extbase --
The fixed extbase caching bug (forge #9762) helps a lot to set up 
working mixed not-cached / cached extensions (we backport the change to 
our local 4.4. cores), parsetime for full cached pages with extbase 
content elements is from my experience not significantly higher than on 
a page without extbase plugins, which is expected.

A full bootstrap of extbase with one or two (pretty simple) plugins on a 
page currently easily eats up 500ms on a decent CPU with php 5.2 
together with an opcode cache. I'll try to throw a profiler to one of 
our extbase extensions somewhere within the next weeks to see if there 
is maybe some method which is either called very often or which takes a 
lot of time, maybe we can optimize some simple things.

I've had a session with Jochen on the dev days to discuss some caching 
issues for extbase, maybe the recent dispatcher refactoring could help 
with implementing a nice extbase content element / sub-content caching. 
We've already done some first and pretty naive steps in this area some 
month ago by connecting extbase with enetcache. If implemented right, 
extbase could do a lot of that automagically, but anything in this area 
would probably be targeted after 4.5, or done in an extension meanwhile. 
At e-net we currently have no project at hand which demands direct 
actions in this area.

-- server side --
I don't have real numbers for php 5.3 (I'd expect an advantage of <10% 
in direct comparison to 4.2). Still, I'd still suggest to go for php 5.3 
as it *is* quicker in several areas (will go stable with debian squeeze) 
and runs smoothly with decent TYPO3 versions.

 From my experience, an opcode cache has more impact the less overall 
computing is done, so I'd expect not more than 50% advantage by using an 
opcode cache on a non-cached extbase page in contrast to ~300% if a full 
cached page is accessed (something around 60-100ms down to 10-30ms). If 
you ask about server setups, I'd say that an opcode cache is *always* a 
must, this rule is true for years now. eaccelerator, xcache and apc do 
not differentiate *that* much performancewise (while eaccelerator does 
not have much upstream support anymore, I'd personally recommend either 
xcache or apc).

On http daemon side nginx is currently a favorite (much smaller memory 
footprint than apache), and I'm currently looking out for a setup where 
we can play with php-fpm SAPI (I'd at least expect some less memory 
impact in a virtual hosting scenario).

Must have is optimization of mysql daemon settings: If we think about a 
"TYPO3 performance howto" we must mention some mysql aspects!


So much from me on this overall topic for now
Christian