Open nrenner opened 5 months ago
No, dirty tiles do not get that cache age, at least not from upstream which is what we control. The expiry time for dirty tiles is 900s:
It's unclear to me what exactly you think you're showing in your extremely verbose report - as far as I can see there is no indication of whether a returned tile is dirty or not so are you trying to match a tile status call and a tile call and hoping nothing changes in between?
Ah I've seen the script now but that is useless because it makes a status call (which may well say the tile is dirty) and then a tile call, which may well re-render the tile and return a clean version and hence not return the dirty expiry.
as far as I can see there is no indication of whether a returned tile is dirty or not
That's why this is so verbose, as I'm trying to reason about it using indirect hints.
so are you trying to match a tile status call and a tile call and hoping nothing changes in between?
In the browser example I ran a loop to check the status every second while making the call and it didn't change until 16 seconds after (browser request started time 10:40:33; or 17 seconds according to Last accessed
):
2024-06-08T10:40:31+00:00
Tile is clean. Last rendered at Tue Jun 08 10:38:36 2004. Last accessed at Sat Jun 08 10:38:36 2024
2024-06-08T10:40:32+00:00
Tile is clean. Last rendered at Tue Jun 08 10:38:36 2004. Last accessed at Sat Jun 08 10:40:32 2024
...
2024-06-08T10:40:48+00:00
Tile is clean. Last rendered at Tue Jun 08 10:38:36 2004. Last accessed at Sat Jun 08 10:40:32 2024
2024-06-08T10:40:49+00:00
Tile is clean. Last rendered at Sat Jun 08 10:40:49 2024. Last accessed at Sat Jun 08 10:40:49 2024
Ah I've seen the script now but that is useless because it makes a status call (which may well say the tile is dirty) and then a tile call, which may well re-render the tile and return a clean version and hence not return the dirty expiry.
Could be, but unlikely because minimum time per tile for z13 on ysera was > 6 seconds, and timeout to wait for rendering seems to be 2 seconds?
What else would be the reason for those cache-control: max-age=604800
, when last rendered time in these examples was only minutes or a few hours before?
This is a mod_tile issue as nrenner rightfully found out. The 900s ModTileCacheDurationDirty config setting never gets applied in mod_tile for tiles that are marked dirty by the expiry mechanisms. And by that the dirty tiles returned by the tilerenderers have the way-too-high expiry time for the cdn edge server caches.
Actual
When expired tiles can't be rerendered on-the-fly, the old (dirty) version is returned.
Currently, these dirty tiles get a
Cache-Control: max-age=604800
and a correspondingExpires
response header, that will cache them for seven days.Expected
I would have expected dirty tiles to be cached for a very short time frame only, as described in #959:
Probably implemented in mod_tile.c and configured in tile.conf.erb?
Examples
Browser
Test case: z13 tile in a dense region with a very recent edit.
Tile is clean. Last rendered at Tue Jun 08 10:38:36 2004. Last accessed at Sat Jun 08 10:38:36 2024
Cache-Control: max-age=604800
:Tile is clean. Last rendered at Sat Jun 08 10:40:49 2024. Last accessed at Sat Jun 08 10:40:49 2024
confirming that we indeed got dirty tiles
Script
Script requesting tile status and headers every minute, for an active HOT task with ongoing edits.
cache-control: max-age=604800
when expiredetag
stayed the same and only changed with next call,rendering times around 30 s and 21 s (next
Last rendered
- responsedate
)Example sequence: