[FLOW3-general] Some questions regarding AOP and a Caching mechanism

[Robert Lemke]

Hi Alexander,

very good thoughts and … exactly what I'm currently working on ;-)

I suggest that we meet in a Google Hangout or Skype beginning of next week and exchange some ideas. Last night I have pushed some big refactorings which will act as a basis for all this (there's a new Http sub package in FLOW3). It doesn't provide a lot of functionality yet, but it was all made with some proper caching in mind, pretty much like you described. Also the new bootstrapping mechanism I developed last December was targeting at that.

So, if you like, ping me in #flow3 IRC on Monday or so (irc.freenode.net).

Cheers,
Robert


On 28.03.2012, at 22:10, Alexander Berl wrote:

> this is gonna be one long mail, so sorry for that already, but I hope some of you bear with me ;)
> 
> I'm currently in the process of building the base for a community portal around FLOW3 in my free time.
> From the experience I made with extbase in my work project, which is a big sports portal full of dynamic content, highly dynamic objects and bad performance on "high traffic" days, I started thinking about a good caching mechanism for FLOW3 and took the ruby on rails scheme as a the base concept:
> http://guides.rubyonrails.org/caching_with_rails.html
> 
> In short, the caching is splitted into three parts:
> 1) page caching - which comes close to the concept of the simulatestaticdocuments concept of Typo3, but lies a level higher and still handles routing correctly
> 2) action caching - where the full result of an action is cached, but takes any filters (aspects) into account - so security etc. is still active
> 3) fragment (template) caching - where parts of templates output are cached
> 
> As an additional step, I'd also like to add a flexible CacheControl headers mechanism that works together with 1) and 2) and is easily configurable per action via annotations. I read somewhere that Robert is already working on a proper HTTP implementation with CacheControl support, so maybe that would be a good point for feedback and inspiration, but more on that later.
> 
> Step 3) is trivially solved with a viewhelper apart from a good method to serialize template variables into a cache identifier handling circular references and the likes (is there already a function that does this?).
> So I started with 2) because it looked like a perfect job for AOP and is a good opportunity for me to learn it. Hence I created an ActionCacheAspect like that:
>    @FLOW3\Around("within(\TYPO3\FLOW3\MVC\Controller\ActionController) && method(.*->processRequest())")
> It creates a cache identifier from controller classname, action name, format and the (sorted) raw request arguments. If an authentication token is available, it's account identifier is also used. The caching settings are controlled via an annotation which allows setting a TTL and tags and optionally deciding if authentication is an invariant to this action.
> 
> So far this works out nicely, but here comes the first point of thought: Using all request parameters, it would be possible to spam the cache with useless GET parameters. Is there some mechanism like the old typo3 cHash (CsrfProtectionAspect maybe?) or is it a false concern here?
> 
> Next I also started the CacheControl aspect which ended up in the same AdviceChain as the ActionCacheAspect because it just fits there the best. However, since the CacheControlAspect is supposed to be run before the ActionCacheAspect (I need to handle conditional requests properly and only send 304 responses), I need a way to control the order of aspects within the same chain (with a priority maybe). Is there some method for it or a workaround and if not, would this be a reasonable feature request?
> 
> Also, I'm a bit stumbled with how to properly handle lastModified dates for dynamic content pages. My first idea was to make this possible to set from actions (or from the ActionCacheAspect if the action is cached), however then I need to run through the whole action before being able to handle conditional requests properly. This would take the whole possible performance gain (apart from the little data transfer gain). Anyone got an idea for this? I guess else the conditional request only makes sense with cached actions then.
> 
> The last thing I would like some feedback on is the page caching before I start on that - or maybe more correct would be request caching, since it should cache the request response depending on the request URL. After a little bit of performance measures I found that the best point for checking this cache is latest before the getReflectionData call, as that takes a really big portion of the whole bootstrapping time (goes from ~10ms before that step to ~77ms after that step).
> However, without the reflection it's hard to do most of the code magic that FLOW3 is all about. I guess a working cache frontend would be enough, but I'm not sure if it will work properly before reflection. So my questions here are:
> - Where would you put a high performance request caching mechanism in place without getting into too dirty coding (e.g. a plain if file_exists() & check against filemtime inside the index.php)?
> - What dependencies are required for a working cache frontend?
> - Would you take POST and/or COOKIE parameters into account for the caching also?
> 
> 
> Thanks in advance for any input.
> 
> Greets,
> Alexander Berl
> _______________________________________________
> FLOW3-general mailing list
> FLOW3-general at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/flow3-general

-- 
Robert Lemke
Lead Developer TYPO3 Phoenix and FLOW3
Co-Founder TYPO3 Association

Blog: robertlemke.de/blog
Get involved: typo3.org – flow3.org