Opened 11 years ago

Last modified 7 years ago

#1944 new enhancement

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

Reported by: amm Owned by: jburgess777@…
Priority: minor Milestone:
Component: mod_tile Version:
Keywords: mod_tile caching Cc:


With the load on 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.

Attachments (1)

htcp.patch (9.9 KB) - added by amm 11 years ago.
HTCP cache expiry in renderd

Download all attachments as: .zip

Change History (2)

Changed 11 years ago by amm

Attachment: htcp.patch added

HTCP cache expiry in renderd

comment:1 Changed 7 years ago by Andy Allan

Component: mapnikmod_tile
Note: See TracTickets for help on using tickets.