[mapserver-dev] Tile Access API

[Christopher Schmidt]

On Thu, Apr 17, 2008 at 01:46:57PM -0400, Daniel Morissette wrote:
> Christopher Schmidt wrote:
> >On Tue, Apr 15, 2008 at 05:22:48PM -0400, Daniel Morissette wrote:
> >>In my opinion, tiling requires caching in most cases 
> >
> >Why? 
> >
> 
> Performance... non-cached tiles via CGI don't cut it in my opinion... 
> they are fine for a toy project in your basement or perhaps for an 
> intranet with only a few users, but in real life production sites 
> caching is almost a must.

I serve 200,000 uncached tiles a day for the various OpenLayers users on
the web. (This is in addition to the ~800,000 a day that are cached.)
Even when the numbers were closer to being revered, the server that was
serving them never had any serious performance issues that I was made
aware of. This isn't a 'ton', I suppose, but it's more usage than a lot
of small WMS sites probably get. 

MapServer can be damn fast if you make it that way, even without caching.
Now, admittedly, that Mapfile was written explicitly *to* be fast -- the
graphs that Schuyler did of performance of various vmap0 layers was
pretty comprehensive -- but there are a lot of cases where serving
limited data up to Google Maps is important, where high performance is
not. 

> >Still wouldn't solve the problem of idiotproofing configuration, which
> >is the reason I'm in favor of the RFC.
> >
> 
> I guess that's the point I don't get. If the benefit of idiotproofing 
> the config of a tile server is higher than the performance costs then I 
> agree that there is value to this addition.

Certainly, my reason for being in favor of this RFC is entirely related
to the fact that it makes things easier to set up. Performance is
typically just not that important for most use cases I'm aware of -- and
when it is, then a cache (like TC) can enter the picture.

Regards,
-- 
Christopher Schmidt
MetaCarta