[TYPO3-english] Speed T3 4.4 vs. 4.5 + thoughts about response times and event-driven caching

[Christian Kuhn]

Hey.

On 03/25/2011 09:31 PM, Boštjan Vlaovič wrote:
> 4.4.7: 402, 363, 385, 410, 387, average 444 ms
> 4.5.2:  537, 578, 555, 487, 511, average 542 ms
...
Next step would be to further analyze this with kcachegrind to see which 
part consumes more time. I've done some 'full cached' measurements 
between 4.4 / 4.5, it turned out that 4.5 overhead is between ~5 to ~10 
percent (which is not much in absolute numbers if we are talking about 
20 to 22 ms).

> I am wondering why cache
> regeneration is time-driven and not event-driven? We would love to have
> all or selected part of the content, that can be stored in such way, in
> static files. We want to proactively change cache and static files when
> the content on this pages changes (and only those) and make sure, that
> _all_ our costumers will access the cached version (even the one that
> accesses the page first).

This is hard to achieve in a generic way. For 'proactive' caching (read: 
actively call fe rendering in order to re-cache pages if content / 
records change) the backend needs to know where the changed record is 
used in the fronted.
While this might be easy for simple content pages, it is much harder if 
records (eg. news) influence content 'somewhere' on the page.
And this is not the only problem: There might be 20 plugins with 
thousands of records on one page, a single record-change might lead to 
hundreds of 'to-be-recached' pages. If a record is used for example on 
_all_ news detail pages, all of them would have to be re-cached.
You will need a queue system to handle this, and then your cache 
wouldn't be generated instantly, again. This method could also pollute 
caches with entries that are actually never fetched in frontend.

So, 'proactive' caching might be a solution for relatively simple sites 
with a specific cache setup for exactly this case, but changes are hight 
that it will blow up with more complex setups, imho.


> In such visitor-based or time-based "recaching setup" server's CPU  is
> always occupied with tasks that can be avoided or at least spread over
> time. Additionally, we can not achieve that all of our visitors access
> the static (or cached) content - unles we manually reload all effected
> pages right after the update. Requirements on the server hardware could
> drop in big installations, right? I know that cache clearing and
> regeneration is not a simple tasks, but T3 implementation already covers
> clearing for most situations (extentions with "Single view" approach are
> excluded, I suppose ;-).

If we drop the idea of 'active' caching for above reasons, we have the 
following options:
- Reduce parsetime of uncached pages by optimizing core, extensions, 
queries, throw more hardware on the problem, optimize system and so on.
- Make sure that cache setup is correct and parsetime of full cached 
pages is acceptable (say 20ms), never use user_int on important pages.
- Use a layer in front of TYPO3 that caches content (example: varnish).
- Clear needed caches only if records change. (especially only single 
view cache pages where the changed record is actually used).
- Use caching on content element level and re-use cached content 
elements over multiple pages if page cache isn't there.

The latter two points can be achieved with extension enetcache (TER) 
that implements a relatively easy API to cache and share content 
elements over multiple pages and gives a nice solution to only clear 
really affected cache entries in case of record changes.
We are using this approach with success for multiple projects, and I 
know that other do, too. Cache clearing is still not really simple and 
needs some thoughts when implementing, but it can help a lot.
Example: We have a frontpage that needs 4 seconds to render if page 
cache and element cache is empty (inacceptable for multiple reasons). It 
has about 40 plugins on it, none of it has a major performance leak. 
Fully cached parsetime is around 20-30ms, and if page cache is empty but 
only one or two elements must be recalculated (typical), parsetime is 
~500ms (and it is full cached after first access again). These are 
numbers we can accept. Our editors never-ever clear caches (they do not 
have the button), cache clearing is done fully automatically, without 
bringing the system down.

Regards
Christian