On 04/03/11 02:10, Leon Volfson wrote:
Hi Amos,
thanks for answering.
NP: The safe way to save on traffic while obeying the standard is
"reload-into-ims". Which converts a full force-reload into an
efficient revalidation.
this is not done to save on traffic, but to not kill the web server with
all the requests.
To make it clearer, I have some .js or .css file which has a max-age
of 7 days. It's cached by squid and everything's great.
After a day I modify the file, but the squid keeps serving the old
version.
What are the possible solutions in these situations (besides
shortening the max-age)?
For this refresh_pattern to have any effect the Cache-Control: and
Expires: headers must be missing or unusable from the reply object
squid receives from the server. max-age control being too high with no
last-modified header makes more sense as the core problem.
Just so we're on the same page - this one's not a refresh_pattern, we're
setting the headers in the file itself/web server. By the way, the web
server is IIS 7.5 and the file is .ashx(for js and css). The squid
version is 2.7.9
Making those .js and .css non-dynamic would go a great way towards
stability and let the server present last-modified headers and correct
IMS handling. Otherwise implement some of it yourself in the scripts
which server them up.
I'm not sure I understand this one. Can you explain a bit better?
Making the .ccs and .js static files which are just picked up and duped
out unchanged by the ResourceHandler.ashx. (called server-side caching)
With some logic in ResourceHandler.ashx to detect If-* HTTP headers and
reply with 304 whenever possible instead of dumping the object out. The
most common being If-Match and If-Modified-Since (abbrev. IMS).
Both of these reduce back-end CPU consuption and raise the load it can
handle. 304 results allow proxies to dynamically adjust their caching
periods per-URL. So while each IMS request may in fact use the same CPU
etc resources as any full fetch the result of sending 304 back causes
less total fetches from the proxy.
No. refresh_pattern is a URL-staleness estimate calculation. The only
relevant things are the URL and some HTTP headers.
Regarding URL. It would be much, much easier if the following would work:
www.example.com/ResourceHandler.ashx?v=11030111&fileSet=JS_FW&type=text/javascript
this is the file. Now shouldn't changing the URL, i.e. the number in the
middle, make squid go to the web server?
Squid does consider them different ... unless you have some store-URL
re-writing going on to prevent it.
Also, squid-2 shipped with defaults which prevented query-string URLs
caching. Check that those have been removed as per:
http://wiki.squid-cache.org/ConfigExamples/DynamicContent
Because, what we see now is that squid doesn't care about the change and
just continues serving the old version as long as it's fresh.
I guess this started when I put in the refresh_pattern with
ignore-reload, but I'm not sure about it.
I don't think so. Those URL changes would make refresh_pattern consider
them two different objects even if it was used.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.11
Beta testers wanted for 3.2.0.5
