[TYPO3-core] RFC 17978 -.... 30% performance drop without discussion

[Ernesto Baschny [cron IT]]

Christian Kuhn schrieb am 05.02.2013 12:25:
> On 02/05/2013 12:14 PM, Ernesto Baschny wrote:
>> Ernesto Baschny schrieb am 05.02.2013 12:13:
>> Besides the 30% performance problem I appreciate the effort done on this
>> area and would really also welcome such a change which simplifies the
>> TCA handling once and for all. This has been a nightmare ever since!
> 
> And this is the exact reason for this patch. We need to simplify this
> mess in order to have a slight chance for a fast and maintainable
> version in the future. The current cache situation is a real problem in
> the frontend and it must be substituted by a transparent solution. If,
> during the development, we have to live with some impact, that is ok for
> me.
> 
> We're talking about full-cache pages without user_int here. They are
> usually somewhere around 30ms seconds or so. If that is now 40 ms ...
> well ... i don't care. This rare case means that you still can handle
> around 1k reqs/second on a server, since that is also not fully cpu
> bound, but some time is also wasted in waiting for db and so on. If this
> is not enough for your application load, you need a different layer in
> front of that anyway.

I understand, the overhead for these cases is big because the current
rendering time for fully cached pages is extremely fast already.

But TYPO3 used to render these pages in under 10ms in 3.8/4.0 times, now
it's 30ms and with 6.1 will be 40ms. The code is getting "optimized" but
the end-user result is getting worse.

It's not that these small simple sites need that kind of speed - not to
speak they don't need or won't have budget for a new caching layer in
front of it - but this will be the overall impression people will be
getting from newer TYPO3 versions: calling it "more bloated" or "getting
worse each version" etc - regardless if "under the hood" the code is
much cooler or easier to maintain.

I would consider this kind of impact too and maybe have a plan to handle
it: in this particular case - getting fully cached pages up to speed
again - after all one could argue "it should only be a matter of
fetching on record from DB and spitting it out to the client" (of course
I know it's not that easy, but it could be).

Regards,
Ernesto