[TYPO3-v4] Core performance for 4.6 and beyond

[Christian Kuhn]

Hey.

On 02/07/2011 09:35 PM, François Suter wrote:
> There's just one particular point which I am uneasy about and maybe I'm
> not the only one, so it's probably worth a discussion.

Thanks for this point. I'm juggling ideas at the moment and I'm glad 
about every input to validate that this is the right track.


>> * First and foremost the 'old caching' must be dropped: The caching
>> framework is *much* more flexible and gives tons of options for specific
>> needs. It should be instantiated earlier to make use of it very early in
>> the bootstrap process (eg. in the autoloader). This will actually drain
>> performance in the first place but will speed up a lot if we are able to
>> refactor other things.
>
> Ever since the new caching framework was introduced, I stayed on the
> impression (after Rupi's tests) that the new caching framework is slower
> than the old one, if it doesn't make use of other backends than the DB.
> Is that still true? If yes, what are the minimal requirements (in terms
> both of TYPO3 and server configuration) for the new caching framework to
> start delivering a performance improvement.
>
> I know that you wrote a lot of documentation about the new caching
> framework [1]. I went through it quickly and I don't think that it
> covers the question I raise above.

- The caching framework loads a couple of classes during bootstrap. This 
takes some time in comparison to the old way of caching data (stuffed 
directly to database without additional layers in between). In effect 
the caching framework *is* a bit slower if you only look at full cached 
pages with small cache tables.
- The caching framework speeds up in comparison to the old caching the 
more data is put into it. We're running installations which would DOS 
immediately if we deactivate the cf.
- Since Rupis first benchmarks the cf and especially the database 
backend improved a lot, we tackled all major bottlenecks.
- The more cf caches we use, the lower is the overhead: For example if 
extbase is installed all major cf classes will be loaded anyway, so 
enabling cf on core side is not very expensive anymore (argument works 
vice versa, too). Loading of classes is expensive: Call autoloader, 
lookup file, require file. But instantiating an already loaded class is 
cheap.

So, if we enable the cf by default, we have to expect a slight slowdown 
in the first place (something like as much as what was added by prepared 
Statement stuff which is loaded for every call since 4.5). But it opens 
the door for real refactorings, especially on boostrap level, which will 
improve performance in the end.

Frankly, I think there is no way around enabling the cf by default in 
the long run: It may require to load some additional base classes, but 
it gives us plenty of options to do caching right. One could for example 
stuff all global arrays into a APC backend which leads to a direct 
memory call when loading, shared between php processes. This would be a 
real benefit in comparison to the current temp_CACHED* stuff and all 
it's loadTCA() and addToAllTCATypes() calls. Bootstrapping currently 
costs up to half of the parsetime of a full cached page. We can only 
improve at this point if we refactor this and use the caching framework 
for those things.

Another reason why we need the cf by default: Tagging is actually a 
killer feature of the cf which can be used to invalidate cache entries 
properly. Example: You have an 'insert record' CE on a page which 
displays some other record(s) from other pages. We tag the insert record 
element (read: the created page cache entry) with the inserted elements 
and can clear page caches using the referenced element automatically if 
the referenced element is changed in BE. Basically, we could get rid of 
'clearCacheCmd' if done right and we could invalidate exactly those 
caches which must be invalidated, but not more.


 > So I think the first step might be to explain people why and -
 > especially - how they should use that new framework.

Maybe we should write some more sentences in the 'quickstart' or 
'introduction' part about why and under which circumstances the cf 
currently gives a benefit for existing installations.


Regards
Christian