No subject

sports portal full of dynamic content, highly dynamic objects and bad perfo=
rmance on "high traffic" days, I started thinking about a good caching mech=
anism 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 simulatestaticdoc=
uments 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 pe=
r action via annotations. I read somewhere that Robert is already working o=
n a proper HTTP implementation with CacheControl support, so maybe that wou=
ld 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 s=
erialize template variables into a cache identifier handling circular refer=
ences 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 l=
ike that:
    @FLOW3\Around("within(\TYPO3\FLOW3\MVC\Controller\ActionController) && =
method(.*->processRequest())")
It creates a cache identifier from controller classname, action name, forma=
t and the (sorted) raw request arguments. If an authentication token is ava=
ilable, it's account identifier is also used. The caching settings are cont=
rolled 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: Us=
ing all request parameters, it would be possible to spam the cache with use=
less GET parameters. Is there some mechanism like the old typo3 cHash (Csrf=
ProtectionAspect maybe?) or is it a false concern here?

Next I also started the CacheControl aspect which ended up in the same Advi=
ceChain as the ActionCacheAspect because it just fits there the best. Howev=
er, since the CacheControlAspect is supposed to be run before the ActionCac=
heAspect (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 ch=
ain (with a priority maybe). Is there some method for it or a workaround an=
d 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 t=
hen I need to run through the whole action before being able to handle cond=
itional requests properly. This would take the whole possible performance g=
ain (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 s=
tart on that - or maybe more correct would be request caching, since it sho=
uld 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 b=
ig portion of the whole bootstrapping time (goes from ~10ms before that ste=
p 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 he=
re 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() & che=
ck 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=