[Tilesathome] Memcached?

[Kai Krueger]

Grant Slater wrote:
> Ian Dees wrote:
>> Spaetz, do you have enough access rights to the tah.osm.org 
>> <http://tah.osm.org> server to install memcached? I'm thinking we 
>> should cache the tile images just before we send them to the user, and 
>> then check the cache when we get a tile request. Even with a 25 or 
>> 30MB cache, I imagine we could cache in memory some of the 
>> most-visited areas. When a tileset uploads, we could make sure and 
>> invalidate the cache enty for it (if it exists).
>>
>> I could spend some time working on this if you have rights to install 
>> memcached and the python bindings.
> 
> Serving tiles is unlikely to an expensive process. OS will cache 
> filesystem reads regardless.
> 
> It would be better to optimise HTTP headers to improve caching (and 
> hence offloading the server) and also support Conditional "304 Not 
> Modified" HTTP Requests.

Although I also think that is probably the best way to go, unfortunately 
I think t at h has one big disadvantage, with respect to caching, compared 
to the mapnik rendering, which is that there is no defined expiry time. 
It is therefore not possible to tell the caches a freshness period and 
the caches will always have to check back with the server to see if 
things have changed. This will thus still generate a server request and 
a round trip time for every request. But with the 304 return codes, one 
can at least save save download bandwidth and time.

If I have seen it correctly, mod_tile now uses a md5 hash of the content 
as an ETag and therefore can send 304s even past a re-render if nothing 
has changed. However I guess that requires to actually load the file and 
compute the md5, so that presumably wouldn't save any server resources 
other than download bandwidth. So I guess how good and idea this is 
depends on what resource one wants to reduce.

I have implemented a patch to generate at least the modified-since 
headers for the new t at h server and correctly reply with "304 Not 
Modified" and sent it to Sebastian. So hopefully if he gets around to 
reviewing it and it doesn't break too much, a first solution to this 
could be running soon. One could probably do more elaborate things with 
Etags, but I wasn't sure what the best strategy would be.

This patch also contained the cache-control: max-age header to set an 
explicit freshness of 1 hour. I.e a cache does not have to check back 
with the server at all during that hour and can just hand out the stored 
tile. As said above, we don't actually know if this is true though, as 
there could be a rerender in between and caches may therefore serve 
outdated tiles. So I guess it is a policy decision to decide if this is 
a sensible compromise between freshness and saved download time and 
server resources.

But it is also not completely clear what is the main thing one wants to 
achieve with the caching. Is it mainly to reduce the download time for 
clients or to conserve server resources and in the second case which 
resource. Disk, CPU or network bandwidth? I think depending on the 
answer to these questions, the exact way of how to calculate the headers 
  may change, so I tend to agree with Sebastian that it might be a good 
idea to leave the system running for a few days first and actually see 
what the next big bottleneck for the new server is.

Kai

> 
> See how JonB solved this for the OSM Mapnik layer:
> http://trac.openstreetmap.org/ticket/1022
> http://trac.openstreetmap.org/ticket/1023
> http://trac.openstreetmap.org/ticket/1024
> http://trac.openstreetmap.org/ticket/1040
> 
> 
> / Grant
> 
> 
> _______________________________________________
> Tilesathome mailing list
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome