[dokuwiki] Re: Cache Expiry Standardisation

> Chris Smith wrote:
> > I realise I am being lazy and the answers to the above two questions
> > are probably maybe and yes, in which case I should probably propose 
> > something so cache management can be centralised.  Maybe someone
> > else  has some ideas, inspiration and time.
> This inspired a whole lot of comment. :-)

:-)
 
> I have done some checking.  Dokuwiki does a lot of filemtime checks in
> order to deliver a page, its css and its js.  In addition to checking 
> the filemtime of the particular file, Dokuwiki also checks:
> 
> for renderer instructions:  4 files
> for xhtml:  5 files
> for js: 10 + each plugin styles.css (not including the two for write
> option) for css: 4 + each template css file + each plugin css file
> 
> Is this a lot of checks? Will it make any significant difference to 
> reduce them?

I don't think so and we should test this before putting too much effort
in it. Linux (and I guess every other OS as well) will cache stat info
for frequently accessed files in memory, so accessing those timestamps
should be really fast.


> Say to have a cache checking value in config, so developers could have
> it set it to exhaustive and stable wiki's could have it set to
> minimal?

that could work - hower I could also live with a manual cachrefresh
while developing. In my experience developers have no problem with
refreshing caches... the problem is with the user - she always expects
to see an immediate change if she changes something - so everything that
is changeable through the interface should be autochecked.
 
> Putting aside the template CSS files which are there for user change,
> in  a stable wiki how often will any of the other files get changed 
> independently of a dokuwiki upgrade?
> 
> I think not very often.  In which case, I'd reckon the number of
> checks  for a stable wiki could be reduced to three files:
> - dokuwiki.php  (above four all check this file and it will be updated
> with a dokuwiki upgrade).
> - local.php (above four all check this file, and it represents user 
> config changes)
> - new file, $conf['data']/meta/<thiscache>.cache
> 
> A cacheutils function ... cache_expire($cache_name) would provide a 
> defined interface for expiring caches.

sounds good.
 
> To expire all caches, it will touch local.php

what wehn local.php isn't writable by the webserver? why not add
meta/local.cache (I know - another file to check)

> It looks like the js handler sends headers which tells the browser not
> to cache css & js.

Uhh that shouldn't be the case and needs to be investigated.

>  Might it be better to allow the browser to cache 
> these files, or at least for this to be configurable - again, for a 
> stable wiki there should not be a problem with the browser caching the
> CSS or 90% of the JS.  That may mean split the js files into two, 
> browser cacheable and browser not cacheable?

for now I always did put the not cachable stuff in a small <script>
section in tpl_metaheaders

Andi

Other related posts: