From looking at
http://www.mnot.net/cache_docs/
, and based on ideas at
http://sourceforge.net/mailarchive/message.php?msg_id=13467125, I've implemented a caching-header management system for geoserver.
Each FeatureType can optionally enable caching headers for maps created from that FeatureType as well as specifing a number of seconds that such maps should remain cached.
On the "Edit FeatureType" page, this patch adds two new fields:
- a checkbox which enables/disables the "Cache-Control: max-age" header
- a text field which allows a user to specify the number of seconds which will be placed in the "Cache-Control: max-age" header
For maps which are made up of multiple layers, the lowest "max-age" is used, and if any layers in a multi-layer map are not cacheable, the entire map is not cacheable.
-
-
- SOME IMPORTANT CLARIFICATIONS ***
Caching is a tricky and sometimes sensitive topic, and I want to add some clarifications about what this patch does and doesn't do.
This patch:
DOES NOT cause geoserver to store images after they've been created
DOES NOT make maps generated by geoserver possibly be out of date
DOES NOT speed up or slow down geoserver in any meaningful way (I guess it might slow it down by a couple of microseconds as it calculates a tiny bit of information per-layer)
This patch:
DOES use well-known, well-defined standards (see http://www.mnot.net/cache_docs/) to instruct an interenet-wide content-distribution network to more efficiently cache maps which change very infrequently
DOES allow applications like ka-map (http://ka-map.maptools.org) and squid (www.squid-proxy.net) to make awesome googlemaps-like interfaces possible with geoserver
DOES absolutely nothing by default. It assumes that all layers are extremely dynamic, and causes none to have appropriate caching headers added unless explicitly enabled.
Any comments or suggestions would be very welcome! The outgrowth of this will be a tutorial explaining how to set up a cluster of geoserver boxes, interconnected squid proxies and a load balancer to create very fast, very efficient google-maps-like geoserver-backed web-based mapping applications.
New Feature
Closed
Major
Cache-Control based WMS map caching
I had a number of questions, thought of after I first heard of this, but I can't recall them all right now. I'll add them if/when I think of them.
One is have you given any thought to tracking the transactions against each layer as the sign to kill the cache, instead of using a user defined seconds thing? Right now it would have to be sort of hacked in, but it wouldn't be too bad a hack. In the future for a versioning WFS we're thinking of making a pluggable processing chain, so you can define validations, peer reviews, email updates, versioning tables, ect., and ideally this could slot right in - notify cache. But I think you could just add a bit of code in the current Transaction Response (which may be the current candidate for most in need of a refactoring), to reset the cache if a transaction on that layer came in. Eventually we could maybe even do complex checking of bounds so as to only update the cache on areas that were affected by the transaction, but that's probably a ways away. (hmmm... should send this to the email list, due to the 'no conversations in the bug tracker' advice.)