[mapserver-dev] RFC 110: Mapcache HTTP REST Cache backends

[thomas bonfort]

Steve,


On 18 April 2014 16:47, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
> On 4/18/2014 10:14 AM, thomas bonfort wrote:
>>
>> Hi devs,
>>
>> Please have a look at RFC110:
>> http://www.mapserver.org/development/rfc/ms-rfc-110.html
>
>
> The RFC and the feature look great. This will be a nice addition.
>
> I'm just trying to get my head around how this works in practice. Is this
> just defining an alternate cache like a filesystem cache? So if I have say
> an openlayers layer that points to my mapcache instance and it is configured
> with a cloud cache, then when an incoming tile request is recieved mapcache
> does a HEAD or GET to check if the tile exists and sends it back if it does.
> otherwise it generated the tiles and PUTs then to the cloud and returns the
> requested tile in the process.
Yes correct. Such a usage makes sense when the mapcache server is also
hosted in the cloud, as in that case the bandwidth for transfer from
the cache to the server is free, you pay for the bandwith outgoing
from the mapcache server.

> In the case of a fully seeded cache, mapcache
> only needs to do 302 redirect to the tile in the cloud. Is this about right?
correct, but only if you've configured <use_redirects>

>
> If mapcache maintained a meta-image of the cache where one bit/pixel equals
> a meta tile for each zoom level, you might be able to make a fast local
> check if you have sent the tile to the cloud and redirect based on that as
> performance optimization.
That might be an idea. I'd imagine that the memory cost becomes too
important for high zoom levels, you'd need to maintain a more subtle
cache than a plain bit-array (zoom level 20 is roughly 1million times
1million tiles, that's a lot of bits to allocate)

cheers,
thomas

>
> -Steve W
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev