Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Add the ability for an explicit cache expiry via HTCP to renderd #1944

Open
openstreetmap-trac opened this issue Jul 23, 2021 · 0 comments
Open

Comments

@openstreetmap-trac
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant