I've been thinking a bit about how we can bring GeoWebCache in to 
GeoNode, to get at some of the great performance enhancements it can 
bring.  Ideally we seamlessly cache all layers viewed in GeoNode, both 
local and remote, even when those change.   There are twists with each, 
and both revolve around stale caches.

With local caches we need a way to truncate the cache if the style 
changes.  Ideally when one is in style edit mode we don't use GWC at 
all, only when someone does a final 'save' does it start caching the 
change.

With remote caches we need a way for a user to manage the cache, to 
invalidate it when the remote server changes, either data or style. 
Ideally it would have a GeoRSS feed of changes that GWC automatically 
truncates based on.  Less ideally there's a manual way to restart the 
caching.

A rough roadmap of how we might achieve the end goal:

* Start with just caching remote layers.  So when anyone puts in a 
remote WMS it automatically gets added as a GWC layer.  Gabriel is about 
to commit a Least Recently Used cache to GWC, which will allow an admin 
to set a total max for the cache.  So we could let people add any layer, 
but the admin of GeoNode can configure it to just cache the most used 
tiles, up to a limit they set, be it 100 megs or 2 terabytes.  For this 
first step the caches may just get invalid, but the admin would have the 
ability to truncate them in the GWC admin.

* Cache local layers, coordinating with Style changes.  I think Arne may 
have coded this up, at least for the embedded GWC.  We could perhaps 
start with just doing the cache on the embedded maps, since those won't 
have people switching to 'style mode'.  Maybe that intermediary step 
isn't necessary, but when we're in the map composer view we want to be 
sure that when people are styling they're not seeing GWC tiles.  When 
they finish styling we should then truncate the existing cache and start 
over.  Another simplifying assumption we could also consider making is 
only cache on the default style.  Not sure how much that actually helps.

* Remote layer management.  This is sort of more general, I think in the 
future we should figure out some more full representation in each 
GeoNode of a remote layer.  Right now remote layers can be added, but no 
metadata can be found out about it.  This is another whole topic, but 
the implication for here is that such a page should/could have a way to 
manage the cache of the local GeoNode.  So you could truncate the cache 
there (maybe just the person who added?  Maybe you can set permissions 
of who can truncate?).  And then possibly also add a GeoRSS location to 
automatically truncate from.


The cool thing this set of things should lead to is to give a benefit to 
people adding remote servers.  They get increased speed and reliability 
if they just add it to a map on a geoNode.  So we can come in with a 
GeoNode to an existing nice SDI implementation that already has a bunch 
of WMS services, and then people can start creating maps on top of it, 
and those maps perform even faster than the straight WMS.

Thoughts?  I think this could be a nice performance win, as most all our 
maps are tiled.  Should obviously be complemented by other 
optimizations, like on the javascript side, but the two together should 
make things quite zippy.

Reply via email to