Re: [squid-users] delivering stale content while fetching fresh
On 2006/09/05, at 2:33 PM, Henrik Nordstrom wrote: The drawback of enabling collapsed_forwarding is that concurrent requests for uncachable content will get delayed a bit until Squid sees that the response can not be cached (response headers required), at which point all pending collapsed queries for that URL will all start a new request each.. I'm guessing that's the full URL. It would be nice if there were an option to ignore the query string for this purpose; E.g., if Squid sees http://example.com/search?q=foo and finds it's uncacheable, it would then stop collapsing other requests with the same base, e.g., http://example.com/search?q=bar Even better, a response cache-control extension could control this... Cheers, -- Mark Nottingham [EMAIL PROTECTED]
Re: [squid-users] delivering stale content while fetching fresh
tor 2006-09-07 klockan 15:12 -0700 skrev Mark Nottingham: I'm guessing that's the full URL. Yes, of course it is. It would be nice if there were an option to ignore the query string for this purpose; E.g., if Squid sees http://example.com/search?q=foo and finds it's uncacheable, it would then stop collapsing other requests with the same base, e.g., http://example.com/search?q=bar A bit hard as it requires keeping a cache of uncacheable content, and to make multiple cache lookups before knowing what to do with the request. Normally query requests is set uncachable by default in squid.conf by the cache directive, making the collapsed_forwarding directive a noop on those requests as it only applies on requests which may be cached to begin with. In accelerator setups which this is primarily targeted for I don't think it's that hard to add some rules telling which query URLs are cachable and which are not if you want to collapse requests for some query URLs. Even better, a response cache-control extension could control this... Personally I think that only complicates matters. If doing this speculation abour URL relationships then I suspect results is sufficiently good deducing it automatically. Adding a new response directive to hint about this is only relevant in cases where the same base URL sometimes is cachable sometimes not, and having it automatically toggle based on what was last seen is probably optimal as it may be a bit hard for the server to guess what the next request pattern will look like.. Note: Same reasoning can be made about file extensions, directories etc. Question is how far to go into this guessing of likelyhood that the response will be cachable. Currently we don't speculate at all and collapsed_forwarding always assumes responses will be cachable until proven otherwise. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] delivering stale content while fetching fresh
On 2006/09/07, at 4:33 PM, Henrik Nordstrom wrote: In accelerator setups which this is primarily targeted for I don't think it's that hard to add some rules telling which query URLs are cachable and which are not if you want to collapse requests for some query URLs. Fair enough, good point. Even better, a response cache-control extension could control this... Personally I think that only complicates matters. If doing this speculation abour URL relationships then I suspect results is sufficiently good deducing it automatically. Adding a new response directive to hint about this is only relevant in cases where the same base URL sometimes is cachable sometimes not, and having it automatically toggle based on what was last seen is probably optimal as it may be a bit hard for the server to guess what the next request pattern will look like.. My goal was more to move configuration off the box and into the hands of the server, which is useful for shared accelerators. Of course, there are other ways to achieve that; having response headers for one object affect another's handling is useful, but does add a lot of complexity. Note: Same reasoning can be made about file extensions, directories etc. Question is how far to go into this guessing of likelyhood that the response will be cachable. Agreed. I was thinking more about a general mechanism using a template; http://www.ietf.org/internet-drafts/draft-nottingham-http- link-header-00.txt Cheers, -- Mark Nottingham [EMAIL PROTECTED]
Re: [squid-users] delivering stale content while fetching fresh
tor 2006-09-07 klockan 17:01 -0700 skrev Mark Nottingham: Agreed. I was thinking more about a general mechanism using a template; http://www.ietf.org/internet-drafts/draft-nottingham-http- link-header-00.txt A template if I understands it correctly in this context reduces into a pattern, as it's reverse lookup, not forward. You need to find if there is another object having a matching template with instructions for this object. Such lookups tends to be very complex unfortunately. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] delivering stale content while fetching fresh
ons 2006-09-06 klockan 07:50 +0200 skrev Gregor Reich: Please tell me: is there any possibility to have this client also being served with the stale content instead of waiting for the fresh one? Maybe, with some coding. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] delivering stale content while fetching fresh
Henrik Nordstrom schrieb: See the current STABLE release. (2.6). Squid-3 is still under development and not all features of 2.6 is available in Squid-3 yet. I checked out squid 2.6 STABLE and I found the feature in question and the associated comment in the squid.conf file. Thank you. Please correct me, if I'm wrong assuming that: * refresh_stale_hit makes stale content (within the refresh_stale_hit-defined period) to be accessed, while - in this moment - the fresh content is fetched from the backend servers to be cached * refresh_stale_hit is independent of collapsed_forwarding, i.e. it doesn't matter wether collapsed_forw. is enabled or not * collapsed_forwarding bundles concurrent request for the same URI into one; but what means concurrent? Within a certain time slot? If yes, how long is this time slot? Thanks a lot, Gregor.
Re: [squid-users] delivering stale content while fetching fresh
tis 2006-09-05 klockan 08:31 +0200 skrev Gregor Reich: I checked out squid 2.6 STABLE and I found the feature in question and the associated comment in the squid.conf file. Thank you. Please correct me, if I'm wrong assuming that: * refresh_stale_hit makes stale content (within the refresh_stale_hit-defined period) to be accessed, while - in this moment - the fresh content is fetched from the backend servers to be cached Correct. It means that only one client will wait for the refresh, the others will get the stale copy. * refresh_stale_hit is independent of collapsed_forwarding, i.e. it doesn't matter wether collapsed_forw. is enabled or not Correct. * collapsed_forwarding bundles concurrent request for the same URI into one; but what means concurrent? Within a certain time slot? If yes, how long is this time slot? While Squid is waiting for the response headers from the web server, or at most 30 seconds. If it takes more than 30 seconds for the server to answer then the next incoming request will create a new request to the web server and future clients will collapse into that one.. The drawback of enabling collapsed_forwarding is that concurrent requests for uncachable content will get delayed a bit until Squid sees that the response can not be cached (response headers required), at which point all pending collapsed queries for that URL will all start a new request each.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] delivering stale content while fetching fresh
Henrik Nordstrom schrieb: Gregor Reich schrieb: * refresh_stale_hit makes stale content (within the refresh_stale_hit-defined period) to be accessed, while - in this moment - the fresh content is fetched from the backend servers to be cached Correct. It means that only one client will wait for the refresh, the others will get the stale copy. Please tell me: is there any possibility to have this client also being served with the stale content instead of waiting for the fresh one? Thanks, Gregor. Mit freundlichen Grüssen Gregor Reich -- Jud Grafik+Internet Grynaustrasse 21 8730 Uznach Tel. 055 290 16 59 Fax 055 290 16 26 Skype: gregreich (Internettelefonie www.skype.com) www.juhui.ch
Re: [squid-users] delivering stale content while fetching fresh
Henrik Nordstrom schrieb: tor 2006-08-31 klockan 16:14 +0200 skrev Gregor Reich: But is there a possibility to have squid responding - to a client that request a document that is (in some way) expired - with the stale document while - at the same time fetching the new one and storing it to cache: ready to deliver to the next requesting client. Kind of. See the collapsed_forwarding and refresh_stale_hit options. Thank you for the hint; I searched the archives, googled and searched squid.conf (Squid3) but I didn't found any description of these options (what do they do, how to configure, possible pitfalls and so on). Can anyone -possibly Hendrik - give me a hint where to look? (In the source code of course; but I'm not really able to do so...) Thanks, Gregor. -- Jud Grafik+Internet Grynaustrasse 21 8730 Uznach Tel. 055 290 16 59 Fax 055 290 16 26 Skype: gregreich (Internettelefonie www.skype.com) www.juhui.ch
Re: [squid-users] delivering stale content while fetching fresh
On Fri, 2006-09-01 at 09:37 +0200, Gregor Reich wrote: Kind of. See the collapsed_forwarding and refresh_stale_hit options. Thank you for the hint; I searched the archives, googled and searched squid.conf (Squid3) but I didn't found any description of these options See the current STABLE release. (2.6). Squid-3 is still under development and not all features of 2.6 is available in Squid-3 yet. Regards Henrik
[squid-users] delivering stale content while fetching fresh
Hi all I'm looking for a reverse proxy solution for a dynamic website, where page generation is where ressource intensive and therefore slow (even if there's no heavy load on the servers, i.e. where minimal generation time is high). Know this website is fairly dynamic an caches would have to be updated at least every 10 minutes. And as I've read, squid stores it's cache content table in md5 and can't therefore update it's cache content without having a request from a client giving its explicit URL. But is there a possibility to have squid responding - to a client that request a document that is (in some way) expired - with the stale document while - at the same time fetching the new one and storing it to cache: ready to deliver to the next requesting client. This would prevent any client from waiting for a page being generated because it's stale and still having dynamic content. Thank you for replying! Regards, Gregor. Mit freundlichen Grüssen Gregor Reich -- Jud Grafik+Internet Grynaustrasse 21 8730 Uznach Tel. 055 290 16 59 Fax 055 290 16 26 Skype: gregreich (Internettelefonie www.skype.com) www.juhui.ch
Re: [squid-users] delivering stale content while fetching fresh
tor 2006-08-31 klockan 16:14 +0200 skrev Gregor Reich: But is there a possibility to have squid responding - to a client that request a document that is (in some way) expired - with the stale document while - at the same time fetching the new one and storing it to cache: ready to deliver to the next requesting client. Kind of. See the collapsed_forwarding and refresh_stale_hit options. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
