22 Apr
2010
22 Apr
'10
4:50 p.m.
Hi devs,
I'm working on a generic rendering cache system base on configuration.
You can see a first version on
http://jira.xwiki.org/jira/browse/XWIKI-5110 (The reason why there is
already a complete working POC is because it has been tested for a
client need and now i'm writing this proposal to integrate it in
standard).
The idea is to be able to list pages to cache without touching them
(that would be more cache macro in xwiki/2.0 syntax or
$context.setCacheDuration in xwiki/1.0) and whatever the syntax.
= Proposal =
1. The main configuration is a regexp patter based list of document
full references (wiki:Space.Page). Here is an example of
xwiki.properties configuration:
core.renderingcache.documents=xwiki:Blog\..*
core.renderingcache.documents=[0-9][0-9][0-9][0-9]_[0-9][0-9]_
The other proposed configuration for now are: is this feature enabled
(disabled by default IMO), size of the cache (the size include the
number of document and the number of panels for each document which
are separated cache entries as well and different languages etc... so
it's not the number of cached documents), time to live in the cache
(the same for the whole cache, it's a pain to configure something for
each document in a central configuration and i'm not sure we really
need that). I plan to provide configuration at xwiki.properties and
XWiki.XWikiPreference level so the configuration could be different by
wiki.
2. Caching is done at XWikiDocument#getRenderedDocument methods level.
Currently the POC I did also cache document panels (the result of the
panels in the context of the listed document), problem is that at
XWikiDocument#getRenderedDocument level it's very difficult to know
what is the real current document. All existing way would be hacks
since there is no official way to get the panel document from java.
Note that you have the same result with $context.setCacheDuration:
every rendering done after the call to $context.setCacheDuration is
cached and panels are generally rendered after the document content.
3. When a document is modified the cache values related to this
document are automatically invalidated. So you don't have to wait to
see new content.
4. Each cache value is unique based on the following informations
* current document reference
* current action
* current language
* calling URL query string
* source (that's how panels are supported, it's same informations
except for the source)
I insist on the fact that it does not cache the result of the html
page but each rendered content. For example all skin and template
related content is not cached (menu bar, comments UI, etc...).
= Nice to have but not easy currently =
a. Extends 2. to also support modifications on included documents.
That would be definitely nice and it should be done at some point I
think but currently we don't really have any clean generic way to get
all documents included for sure (includes inside other macros are not
listed by the existing API for example, that would need some
refactoring).
b. Separate document cache and panels cache. As I already witten
that's would need important refactoring to not be a hack.
= Side notes =
I. This proposal comes with a generic document reference based cache
component which take care of the event based cache invalidation
system (3.) and support cache keys based on document reference and
extensions (4.). We could reuse this component in other document
reference based keys caches like image plugin.
WDYT ?
--
Thomas Mortagne