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

[Stephen Woodbridge]

On 4/18/2014 11:00 AM, thomas bonfort wrote:
> 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>

Ahh, this is all good to know. Thanks for the details on this. Good stuff!

>>
>> 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)

Right, that is why I was thinking meta-tiles but even that is a lot. My 
other thought was that these arrays could be stored as files in chunks 
that can be easily indexed from tile id to bit chunk file. this would 
need to be tested to see if there is any real performance benefit for 
adding the complexity of managing it like this. It would seem that doing 
a GET and then forwarding the tile is expensive compared to checking 
locally and doing redirect. Anyway it was just an idea.

Thanks,
   -Steve W