Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
LoadFromFileCacheTtlMs does not control how often the file-system is re-checked. #1626
There are several issues actually I want to mention here.
First. One may assume that
ngx_pagespeed seems to check files for changes upon every request which has a potential for improvement. We want to stop those mtime checks which happen on every request, as this would reduce I/O quite a lot on busy sites. Can we have a
Second, I found
So multiple issues there:
I think the gotcha here is that
Well, that's what I thought:
But my test environment is an idle system with a single HTML file and single CSS file. I can definitely see resource already optimized, when they are.
However, I can see that the mtime check happens any time I modify contents of the CSS file, as this reflects in a different hash of the .pagespeed CSS URL on next reload. So it doesn't seem like
So maybe, just maybe :) the extend cache filter is somehow kicking in always whereas others respect the
TL;DR: only use LoadFromFile on a local physical disk where stat() is cheap. Never use LoadFromFile on a mounted file system.
RE stat() overhead per-request: your observation is spot-on, and reflects the intended design, and does result in a stat() call on each resource every time it is referenced in an HTML file.
This is intended as an alternative to using HTTP-fetching and a file-cache. It avoids the HTTP fetch (and also side-steps any issues you might have with HTTPS fetching). A tradeoff is that it doesn't have access to the HTTP origin headers for your assets, so it doesn't know how often to re-check to see if the origin asset has changed. This also means that changes to assets take place immediately; they don't need to expire out of cache.
If stat() takes along time (e.g. it's a mounted system) then definitely don't use LoadFromFile; use HTTP fetching so we can get cache TTLs and periodic checking of how up-to-date the contents are, based on the origin TTL that you control per normal HTTP caching headers.
If you say
Hi. Sorry to jump into this specific query but I am trying to understand the updating system of sources of pagespeed when using the extended_cache filter related to the LoadFromFileCacheTtlMs
I posted a question on the google group (https://goo.gl/SgCWBj) but I'll try to briefly ask my question here as I am about to give up on it.
We are trying to improve a nginx cache proxy in front of various apache servers on containers. Our setup was intercepting static content... (css, js, images, etc) extending cache headers, proxying and caching:
client --> nginx proxy cache for css, js, images.. --> backend apache
Our intention now is to add pagespeed in order to improve in general and particularly css and JS further by concatenating (css + js) and properly versioning to extend caches which I understand is exactly what extended_cache filter does. (A list of our active filters bellow.)
Our doubts/issues are coming from some css and JS after treated by pagespeed do not get updated after a change and remain staled. This happens even if we've:
So a file as /ass/skins/def/css/bootstrap.min.css+main.gis.css.pagespeed.cc.7FZQ-V4k-L.css remains so after a change on the backend whatsoever.
This is what that root reports in the cache:
Even after clicking "delete" on that, no change. Only once I clear the whole pagespeed cache through the backend I get an updated version.
I'm probably not understanding something:
Deleting the metadata cache don´t delete the optimized resource from the cache.
Thanks @Lofesa, pagespeed is installed on the nginx proxy_cache. Thanks for the info regarding metadata but the issue remains. Actually even removing all cache services now and just using nginx as a proxy to our apache backend, issue remains, so trying to figure what else might be wrong in our setup.