You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: amm [Submitted to the original trac issue database at 6.28pm, Tuesday, 9th June 2009]
With the load on tile.openstreetmap.org continuously increasing, there probably will be a need for having reverse proxies in front of it at some point. With the increased rendering frequency (minutely?) it isn't however possible to predict when a tile expires. Therefore a static tradeoff between up-to-dateness and cacheability is very difficult. In order to have long cache expiry on potential OSMF proxies and thus to maximise their efficiencies, an explicit cache expiry when tiles are known to have changed is necessary. This patch adds the first part of this to renderd. With it, when ever renderd renders a tile, it also (if configured) sends an HTCP cache clr to the proxy. Currently with metatiles, this will cause 64 HTCP packets (one per actual tile), per rendered metatile. I have no idea if there is going to be a scalability issue here with the number of metatiles being rendered per second. But given that each HTCP clr is a small UDP packet, hopefully it shouldn't be too bad.
A second part, that takes the actual .diffs into account is also necessary, as otherwise tiles that have changed and should be rerendered might not be, as the proxies could prevent mod_tile from seeing the request and calling renderd, which only then would expire the proxy.
The text was updated successfully, but these errors were encountered:
Reporter: amm
[Submitted to the original trac issue database at 6.28pm, Tuesday, 9th June 2009]
With the load on tile.openstreetmap.org continuously increasing, there probably will be a need for having reverse proxies in front of it at some point. With the increased rendering frequency (minutely?) it isn't however possible to predict when a tile expires. Therefore a static tradeoff between up-to-dateness and cacheability is very difficult. In order to have long cache expiry on potential OSMF proxies and thus to maximise their efficiencies, an explicit cache expiry when tiles are known to have changed is necessary. This patch adds the first part of this to renderd. With it, when ever renderd renders a tile, it also (if configured) sends an HTCP cache clr to the proxy. Currently with metatiles, this will cause 64 HTCP packets (one per actual tile), per rendered metatile. I have no idea if there is going to be a scalability issue here with the number of metatiles being rendered per second. But given that each HTCP clr is a small UDP packet, hopefully it shouldn't be too bad.
A second part, that takes the actual .diffs into account is also necessary, as otherwise tiles that have changed and should be rerendered might not be, as the proxies could prevent mod_tile from seeing the request and calling renderd, which only then would expire the proxy.
The text was updated successfully, but these errors were encountered: