[TYPO3-v4] Core performance for 4.6 and beyond

[Christian Kuhn]

Hey,

On 02/08/2011 12:48 PM, Tolleiv.Nietsch wrote:
>> ** We could concatentate important (read: always needed) classes in one
>> file to reduce filesystem lookup overhead. Making makeInstance aware of
>> that shouldn't be too difficult (not tried yet). This will *add*
>> performance if we refactor important classes to smaller things from
>> which not everything is needed for full cached access.
>
> isn't APC/eAccelerator/Zend* supposed to help with that in a much more
> efficient way? I'd prefer not to do something like this.

Actually, this is just an idea and I didn't really benchmark very much 
in this area until now. In fact, a lot of time is consumed by 
autoloading and makeInstance logic and not by require() itself. AFAIK, 
APC and friends still usually do an mtime lookup to a require()'d file 
to ensure it didn't change since last access, so concatenating classes 
in less files would probably have 2 advantages:
- Less filesystem lookups
- Less additional overhead in makeInstance if major classes are pre-loaded.

I'm unsure on how those two effects relate to each other but I'd expect 
the latter one to have a bigger effect.

If it turns out that a class concatenation has real benefits, we would 
do it with the PhpFrontend anyway. This would be a transparent layer (no 
need to deliver concatenated classes in core packages).


> The other points sound reasonable. But before we refactor something,
> there should be some kind of regular public performance monitoring so
> that we've some way to compare results. Maybe at least a benchmark
> script could help to check wether supposed changes help to improve
> things or not.

Performance is often about specific needs, there are tons of variables 
playing the game: Current performance depends on access signature, php 
version, db size, server hardware, server software, daemon load, disk 
load, change frequency of content, content types (more dynamic / more 
static), number of extensions, cache sizes, cache access signatures, and 
so on.
This is one reason why the cf is designed to be so very flexible: To 
adapt it to needs. With enetcacheanalytics I have tried to hack up a 
module to at least compare different cache backends between each other 
by throwing the same problem to each and see how they scale, just to get 
some feeling on how they react for different usages (like: growing 
number of entries, of tags, of accesses, ...). Even this turned out to 
be not very easy, one has to take a close look to produced numbers to 
come up with sane conclusions.

A generic benchmark saying 'this change improved 10% performance' is 
simply impossible for complex systems. It can only be done for very 
small code fragments like a specific t3lib_div method or something like 
that, but it's much harder for the whole system.

All we can do is give admins a 'sane' default configuration together 
with a documentation on how thing could be changed to fit special needs 
and a flexible system to do this.


Regards
Christian