Hello, Kai, thank you for your prompt and informative response. On Thu, 3 Oct 2013, Kai Krueger wrote: I can send you some example log lines of the throttled IPs: 2013/10/04 08:11:30 [error] 28822#0: *53658093 limiting requests, excess: 55.240 by zone "hikebike", client: 213.73.96.44, server: toolserver.org, request: "GET /tiles/hikebike/15/17169/11177.png HTTP/1.1", host: "toolserver.org", referrer: "http://www.gpsies.com/map.do?fileId=gbcojbhrdfqlglbc" 2013/10/04 08:11:02 [error] 28822#0: *53650597 limiting requests, excess: 55.120 by zone "hikebike", client: 85.0.37.63, server: toolserver.org, request: "GET /tiles/ osm/3/4/0.png HTTP/1.1", host: "c.www.toolserver.org", referrer: "http://toolserver.org/~kolossos/openlayers/embed.html?layer=mapnik&bbox=39.68865498340449,43.5524339 5214844,39.778011016595514,43.614232047851566&marker=43.583333,39.733333 If you want to get more logs I'd send them to you in private. It seems to relate especially hikebike/cmarq tools. Sounds plausible. 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? 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. Cheers nosy

On 10/04/2013 03:39 PM, Marlen Caemmerer wrote: 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