Fwd: Re: blocking requests in squid

---------- Forwarded Message ----------

Subject: Re: blocking requests in squid
Date: Mon, 20 May 2002 00:45:10 -0700 (PDT)
From: Shlomi Yaakobovich <shlomiya@yahoo.com>
To: Henrik Nordstrom <hno@squid-cache.org>

Hi Henrik,

Your reply maqde many things clear. I tried the squid
again, and it behaved as expected. Then, I changed the
 neighbors_do_private_keys to 0, and for a while, it
worked very well. However, when heavier stress was put
on the squid, there was an assertion failure in
clientCacheHit, with (size>0) failing.

I investigated the issue some more, and I realized
that this fix was not exactly what I was after. It was
better than the previous situation (where request did
not wait at all), but still, users would not receive
anything until the first request was answered. What I
was interested actually, was a scenario where the
first user would go out, and until his outgoing
request is answered by the server, other users who
want the same object, would still receive the cached
content, although it is stale.

I made a change, that could possibly contribute to the
entire squid code. Ofcourse, this is determined by
configuration (let's call it return_stale_if_expired
(on/off). In clientProcessExpired, in the process of
creating a new StoreEntry, I've changed the expiration
time of the http->old_entry. This (if I am not
mistaken) should not affect the transfer of the new
entry, and all the users that will ask for this object
until the new content arrives, will still get cached
content (since it's expiration time was artificially
increased).

So far it looks to work fine for me. I'm going to
conduct some more tests with it, but I'd first like to
know what you think about this.

Thanks,
Shlomi

--- Henrik Nordstrom <hno@squid-cache.org> wrote:
> The second request is threated as the first.. if the
> cached reply
> isn't suitable a cache revalidation is initiated. If
> two such
> requests arrive at "the same time" then two cache
> revalidations will
> be inititated.
>
> Where things differ is after the reply headers have
> been received.
> The new object is then marked as "public"
> (storeSetPublicKey()), and
> any new requests received after this will hit the
> new object, even
> while data is still being received.
>
> This is in the default "neighbors_do_private_keys =
> true" scenario.
>
> If neighbors_do_private_keys is false then I am not
> entirely sure on
> what happens.. I have never tested the details
> without private keys,
> and I don't think any of the other developers have
> either..
> "neighbors_do_private_keys = false" is a Squid
> internal hack to work
> around non-Squid ICP peers not supporting the ICP
> request number
> field (covered by the ICP RFC, but was not
> implemented in the first
> ICP implementations of Harvest Cached from where
> many other ICP
> implementations have been derived).
>
> Regards
> Henrik
>
> On Monday 06 May 2002 09:39, you wrote:
> > Hi Henrik,
> >
> > I have been reading the squid mailing list for a
> > while, searching for a solution to a problem I
>
> have. I
>
> > saw that you had several responses and ideas on
>
> that
>
> > issue.
> >
> > What I'm talking about, is a scenario that 2 (or
>
> more)
>
> > requests for the same object come in the same
>
> time,
>
> > and squid should not go out with two requests to
>
> the
>
> > origin server. I know that squid should "behave
>
> well"
>
> > with this scenario, if the object is cachable, and
>
> if
>
> > it was not a refresh (cache-control: no-cache,
>
> etc.)
>
> > request.
> >
> > My problem is, that I never succeeded using this
> > feature of squid in the past. I am very familiar
>
> with
>
> > the squid code, and I was wondering where the
>
> decision
>
> > to treat the second request differently is made ?
> >
> > I know that if you use the
>
> neighbors_do_private_keys
>
> > hack then squid will create a new StoreEntry, make
>
> it
>
> > public key (and the previously cached one
>
> private),
>
> > and so the next request for this object will exit
>
> in
>
> > storeClientCopy2, because ENTRY_FWD_HDR_WAIT is
>
> set. I
>
> > don't understand where/how squid handles the
>
> second
>
> > request differently without this hack.
> >
> > Thanks in advance,
> > Shlomi
> >
> >
> >
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Health - your guide to health and wellness
> > http://health.yahoo.com

=====
signoff
gift certificates (join it !) at
 http://www.directleads.com/ad.html?o=862&a=cd18019

Visit The Israeli Diplomacy WebSite at http://www.diplomacy.org.il

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

-------------------------------------------------------
Received on Mon May 20 2002 - 05:43:33 MDT