On 10/04/2013 03:39 PM, Marlen Caemmerer wrote: > Hello, > > [...] > gpsies.com stated they use the cache-control header which is sometimes > not set reasonably probably as far as I tried to see - i had a look at > these hikebike URL delivered from cmarq. > The will look at the problem closer on their side so I expect some more > details in the next days. > > I could set cache control headers in the nginx which acts as load > balancer for TS for tiles where it makes sense. Do you have any advices > on this? Which tiles dont change for what time about?
Mod_tile has some "sophisticated" heuristics to try and set the cache control headers. Hoever, since many years ago, the update schedule has moved from weekly to minutely, it is impossible to know when exactly which tiles get updated and hence the need for heuristics. Currently mod_tile sets the cache control headers to somewhere between 15 minutes and 7 days. The first distinction it uses is whether a tile is known to be "dirty". I.e. the data for that tile has changed in the database, but the rendering hasn't updated the corresponding tiles. In this case the served tiles are known to be out-of-date, and a rather short 15 - 30 minutes cache-control header is set. For clean tiles, it looks at when the tile was last modified, in the assumption that tiles that have recently changed (e.g. because they are in a high activity area) are more likely to get updated again soon than tiles that e.g. haven't changed in the last year. In this case the cache-control header varies between 1 and 7 days, depending on the age. All of these heuristics can be changed in the apache config. For toolserver, it probably is worth modifying the default values, as a couple of the assumptions don't really hold. E.g. the assumption for the short expiry for serving the dirty tiles is that rendering might not quite succeed in the 2 - 3 seconds timeout for serving stale tiles, but will finish shortly afterwards. Hoever due to the slow rendering, the overloaded server and the very long queueus on ptolemy, it might take days rather than seconds for the rendering request in the queues to finally get processed. So having a cache-control of only 15 minutes probably doesn't make sense in this case. For clean tiles, a timeout of only 1 - 2 days might also make little sense, if due to overload, it is unlikely that tiles can be re-rendered in a faster pace than that anyway. So perhaps it would make sense to simply set the cache-control headers to always e.g. 7 days. Or at least a minimum of 1 day. Kai > > >> >> At least on the munin graphs for ptolemy, I don't see much increased >> load. But if it is the hillshading tiles, or the WMA tiles, those don't >> get served through ptolemy as far as I am aware. > > Seems these tiles are delivered via ortelius/wolfsbane. Unfortunatelly > the high load times lead to munin not graphing anymore so I dont have > any accutal data but the error logs/loads via console. > >>> >>> I dont want to have this option configured forever - I rather hope we >>> can do something about caching or give the pictures they need to the >>> projects themselves (I doubt we have to deliver hill shading pictures >>> for everyone - this is Toolserver) >>> > > > > Cheers > nosy > > _______________________________________________ > Maps-l mailing list > map...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/maps-l _______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
