Re: [xwiki-devs] Cache needs

Hello XWiki devs, I may be diverging since this is not so much about the back-end caching infrastructure, but I would like to insist on one practice for caching which such a cache architecture should support: the most common use of a cache that we have been experimenting with is not that clients simply do not call again because it's in cache (this happens but not in most cases), they call with an added header If-Modified- Since, which contains a date. That date is the date the client last cached the given resource. The interest is when the server responds the status code 304 (Not Modified) which basically says "your cache is good". Think of something such as a javascript, CSS, or HTML file, cached in a browser,... this means no reparsing needed, a very useful statement to save CPU and memory (as well as bandwidth, but that is less a problem)! Note also that such a call is very tiny, 10 lines of headers up- stream, three-lines downstream, very little if the connection is kept- alive. And it does provide up-to-date-ness guarantees whereas the practice of not checking if a cached resource is up-to-date (because the cache is "fresh enough") fails at providing this guarantee. A way to implement this approach on the back-end would be to have some of the retrieval calls to contain such a parameter as "if-modified- since" and have an exception be thrown if it is not modified. I believe that even some of the tags with a page that I heard about in Vincent's talk are candidate to support such an infrastructure, being able, if mature, to look into their sources if there's anything changed since that date. As I understand, this is not what tomcat does on the default file- serving servlets and this is the reason we keep seeing these spurious loads (e.g. picture curtain of load). Don't ask me why Tomcat chose not to make it such. paul Le 27-mai-08 à 10:35, Vincent Massol a écrit :