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
Maps-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/maps-l