[TYPO3-core] Taming the Performance in 6.2

[Ernesto Baschny]

Hi,

the CMS team is in mids of identifying and trying to improve the
performance of TYPO3 CMS until final 6.2 release. In this thread I want
to canalize the effort and make sure everybody is aware of the
importance of these tasks and also connect people working on different
fronts.

As much as I would love to make a last Code Sprint dedicated to
Performance and "last fixes" for 6.2 before the final release, I
personally won't have the time to organize such an event. If someone
wants to organize and maybe even host such an event, please get in touch
with me so that I can help! It could also be just a place to brainstorm
with 3-4 people. Let us know if you do that so that others could
participate (through Skype / etc).

Now let's talk about 6.2 performance:

We have this fruitful general discussion on the 6.x performance going on
here:

	http://forge.typo3.org/issues/52949

Some specifics:

Caching

There is already a front (Jan-Erik Revsbech, Helmut Hummel) working on
improvements in the Caching Framework when dealing with invalidating
lots of cache entries by tags (which happens when you save a page in the
backend for example). Contact them or open a discussion here if you are
interested in working on that. I invite Jan-Erik and Helmut maybe to
share the thoughts in public if possible. If I got it correctly, soon
Jan-Erik will propose a solution in a Review Request.

Our friend Tymoteusz Motylewski (no way to write that name without
Copy&Paste...) is also working on the Caching front and already has some
ideas.

Package Management

Since beta1 together with the Package Management we introduced a new
Caching Backend for loading PHP classes and it's class aliases. The new
concepts minimizes the amount of memory required by not keeping one huge
array in memory, but it seems that has still some performance drawbacks
due to heavy use of "require_once". Since this affects all hits (even in
frontend with all cached), tackling this area will most probably bring
us the biggest benefit. Tom Maroschik is working on that area, please
share your thoughts here or with us directly if you have some further
ideas on that. We should be at least as fast as 6.0 was in that area!

There have been other performance drawbacks from 4.x to 6.0 which are of
course still present in 6.2 which weren't tackled before. So analyzing
what happened in the step from 4.7 to 6.0 might also bring some valid
insights.

Backend

Most concerns and effort currently are aimed for fast "frontend
rendering". This is important, of course, but there are several areas in
the backend that also deserve some performance attention, as this is the
place where the editor works and will be considered when recommending
the product to others.

We are now slower than 4.5, which back then was also claimed to be
"dramatically slower" than all previous versions (due to the
introduction of ExtJS etc). We can get some speed back to make clicking
around the backend snappier than it is in today's master.

Some stuff that *could* be analyzed (there are my quick findings doing
some basic profiling, please share your thoughts and ideas about other
areas):

1) If you enable "Production Mode" (in the install tool, Preset
Configuration) you expect the modules to load faster (due to no
debugging code, no deprecation messages etc). But in fact the PHP
processing of a module like Web>Page gets slower due to the overhead of
concat+minify that seems to happen on every hit to the module and it
might use up to 25% of CPU cycles of a normal Web>Page module rendering
(PageRenderer::doConcatenate()). Caching? It seems that the culprid in
the concatenate method itself is the isValidUrl call which is called on
every file to merge and this calls the expensive idna_convert methods.

2) Extbase Backend Modules: In general it seems that on every hit which
bootstraps Extbase the BackendConfigurationManager::getTypoScriptSetup
will parse the whole typoscript over and over again. There is a
transient caching going on there, but this doesn't survive the request.
So we could try to stick a real cache here to avoid parsing the same
TypoScript on every request (i.e this makes about 13% of the Extension
Manager's processing time).

The Web>Page module might contain an instance of Sys-Notes (an extbase
module), so this performance could impact the regular editor that work
only with Web>Page. Simply deinstalling SysNotes makes every call to
Web>Page load dramatically faster - something to work on.

I know this might be a daunting task to make Extbase faster at this late
stage, but if we work concentrated on this we might be able to squeeze
something out of it.

3) Fluid rendering pops up in the "top list" when profiling once and
again. Is there performance Probably too late now to update to a (maybe
improved?) upstream Fluid... :(

4) PageLayoutView::isRTEforField is called on every record that is
displayed in a Web>Page. And this will call
BackendUtility::getPagesTSconfig($tscPID) every time once and again, and
thus parsing the PageTS over and over on the same hit. If you have 50
content elements on a page, this can get very expensive.

So as you see there are several possibilities to improve our performance
yet, and this is just a first list that came to *my* mind while
analyzing the situation. There is enough material for every taste so
please pick your area of interest, try out some things and talk with us
about it.

If you are working on certain aspect, please create an issue on forge
and send us the link here, or if it's too early for an issue, simply
tell us here in this thread.

Kind regards,
Ernesto Baschny

-- 
Ernesto Baschny
TYPO3 CMS Core Developer
Release Manager TYPO3 4.5 & 6.2 LTS

TYPO3 .... inspiring people to share!
Get involved: typo3.org