[TYPO3-dev] Apache/PHP TYPO3 Caching-Module
Ernesto Baschny [cron IT]
ernst at cron-it.de
Wed Mar 17 09:54:09 CET 2010
Jigal van Hemert schrieb am 16.03.2010 23:59:
> Ernesto Baschny [cron IT] wrote:
>> Jigal van Hemert schrieb am 16.03.2010 21:15:
>>> Why would we store a serialized "cObj" instead of copying an instance of
>>> a cObj? At the time the _INT markers are processed there is already
>>> content object which is initialized.
>>
>> Not in case the page is coming from cache and only the _INT objects need
>> to be "re-rendered". We need to "initialize" the object first, and
>> having the available somewhere (e.g. serialized..) is the easiest option.
>
> It seems that with a substantial number of _INT objects the
> unserializing (and resuscitation of included objects) is taking more
> time than rendering an entire page.
>
> The situation seems to be:
>
> - no _INT objects: page cache, pretty fast
> - one or a few _INT objects: page_cache + rebuilding of content objects,
> reasonably fast
> - no page caching: reasonably slow
> - multiple _INT objects: page_cache + rebuilding of content objects, slow
>
> Caching at the content element (plugin) level can speed up rendering of
> _INT objects dramatically, but if rebuilding the objects takes longer
> than creating them plus letting them render the content then any
> attempts at plugin level caching are futile.
Yes, that is indeed a problem. Usually "one _INT" is sufficient to add
lot of overhead to a cached page. So cached without _INT = 5ms, cached
with one _INT might be 50ms. So even if the _INT would cache its output,
the mere fact that it is there already causes "damage".
One potential solution would be an "in between output cache", I think
there have been attempts or maybe even solutions for this problem.
This is something worth to discuss and brainstorm in a "team" (for
example at the T3DD10).
Cheers,
Ernesto
More information about the TYPO3-dev
mailing list