-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dirty tiles cached for 7 days #1096
Comments
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. |
That's why this is so verbose, as I'm trying to reason about it using indirect hints.
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
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 |
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:
The text was updated successfully, but these errors were encountered: