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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
