[OpenLayers-Users] OT: wms-c

[Christopher Schmidt]

On Tue, Nov 07, 2006 at 03:59:54PM +0100, Trond Michelsen wrote:
> On Tue, Nov 07, 2006 at 09:47:41AM -0500, Schuyler Erle wrote:
> > * On  7-Nov-2006 at  3:55AM EST, andy said:
> >> Dear all,
> >> I have read about
> >> http://labs.metacarta.com/wms-c/
> >> It's very interesting. Is it will released in some way to the public?
> > Yes, later this week or next. Keep an eye on
> > http://labs.metacarta.com/blog/. Thanks for your interest!
> 
> I'm a little bit confused. What does wms-c provide that you can't
> already do with a caching server like Varnish in front of the WMS, and
> a tile based client (like OpenLayers)?

Varnish has a number of limitations that you mentioned for the normal
user: it basically requires a 64bit machine to use it well. Schuyler
also pointed out one of the other problems with caching using HTTP
Request strings: that is, that clients other than yours can fill your
cache. The labs WMS, when it was only being accessed by OpenLayers
users, was seeing about 80% hit rates against a URL-based cache.  However, 
after someone wrote a WorldWind plugin for the WMS server, the cache hit
rate went down to around 30%.

The WMS-C implementation we're working on doesn't depend on the ordering
of parameters, and won't cache things other than what you advertise as
cachable, and will be configurable to either reject invalid requests or
to fall back to non-cached data. 

The WMS-C specification allows you to define the data that is 'fast', so
that clients know how to request data. This is important when you are
attempting to make a fast WMS service available: although HTTP Request
caching works when you control all the clients, when you don't, things
tend to fall apart.

WMS-C is designed to fix that, and the implementation that Schuyler and
I have been working on makes it really easy to use it to do any number
of other things that a simple HTTP Proxy is not at all designed to do,
like accept a variety of request formats (TMS or WMS are currently
supported) while using the same rendering backend, using any caching
backend your'e interested in -- whether it be distributed memory
caching, local disk caching, or a plugin for storing files in S3 -- as
well as using any number of rendering backends, such as calling
mapserver via mapscript, or accessing data via a HTTP Request to another
WMS server.

In general, HTTP Proxies don't solve the problem of Caching WMS for all
clients. They work for one client, but tend to offer less control, and
less specific functionality that relates to WMS-related concepts. This
lack of control and lack of WMS knowledge both make them a poor match
for caching this type of data, and a specific implementation catered to
it makes life easier.

That said, the WMS-C specification makes no mention as to
implementation, just a way to describe things which *are* cached so that
clients know what to use. This means that using varnish, or Squid, or
anything else, will work fine. We've just gone a different route because
we've found from experience that throwing lots of clients at a simple
URL-based caching mechanism means you poison your cache with lots of
things you don't care about being fast.

Regards,
-- 
Christopher Schmidt
MetaCarta