Hello,
Henrik Nordstrom wrote:
> sub-minute caching of content that cannot be revalidated only makes sense in 
> accelerators. But in accelerators they can make a lot of sense if you have a 
> handful of such pages that is accessed very frequently.
Yep. A thought: Why not make sub-minute caching default when in 
accelerator mode?
> Another alternative to hacking the source is to have the origin server 
> provide a Last-Modified: <now> header, combined with a suitable Expires 
> header. This will completely bypass the sub-minute check in Squid.
I chose to go forward with my patch for src/refresh.c (attached). Turns 
out that my patch hadn't been applied properly in my latest Squid 
builds; that's why it didn't seem to work any more...
> Also, make sure the clocks are properly in sync. Use NTP on all your servers 
> and accelerators. When you are dealing with sub-minute caching, even a few 
> seconds clock drift may be quite important.
Keeping clocks in sync is a good idea, yes. However, I have learned that 
the Expires-header is not as nice as the Cache-Control header, used in 
the following way (just an example):
Cache-Control: public, max-age=60, s-maxage=30
(Browsers may cache for a minute; proxies may cache for ½ a minute.)
Concentrating on age-related headers eliminates problems with servers 
being out of sync clock-wise.
-- Greetings from Troels Arvin, Copenhagen, Denmark System administrator at TV 2/interaktiv
--- squid-2.4.STABLE1-orig/src/refresh.c	Sun May 13 03:38:24 2001
+++ squid-2.4.STABLE1/src/refresh.c	Sun May 13 03:38:50 2001
@@ -327,7 +327,7 @@
      * 60 seconds delta, to avoid objects which expire almost
      * immediately, and which can't be refreshed.
      */
-    int reason = refreshCheck(entry, NULL, 60);
+    int reason = refreshCheck(entry, NULL, 1);
     refreshCounts[rcStore].total++;
     refreshCounts[rcStore].status[reason]++;
     if (reason < 200)
Received on Tue Nov 06 2001 - 21:12:07 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:03:56 MST