[...]
> cache_peer bowerbird.cc.uq.edu.au sibling 80 3130 no-delay
[...]
> But SIBLING_HITs from bowerbird.cc.uq.edu.au are also fed to the
> client at 300 bytes/sec. Shouldn't they go at full speed, or am I
> misunderstanding the meaning of the no-delay option?
They are most definitely intended to go at full speed - but I think I see
where the problem is, this option was not updated when the code was changed.
My understanding is that all peer connections go through httpStart() and
that the code around line 812 of http.c (squid-2.0patch2 line number)
used to prevent the delay:
httpState->request = requestLink(proxy_req);
httpState->orig_request = requestLink(orig_req);
[...]
#if DELAY_POOLS
if (httpState->peer->options.no_delay) {
proxy_req->delay_id = 0;
} else {
proxy_req->delay_id = orig_req->delay_id;
}
#endif
This is probably not working anymore since the primary place
delay id's are looked up is in store client structures, which may
already be set from an earlier delaySetStoreClient.
It might be a little difficult to get this right. Even if we get it right
for the first store client hanging off an object, the second one might not
be able to tell easily what peer the object is coming from and therefore will
have delay set, and if the first store client disappears the rest of the
transfer may be delayed. This has to be thought out, I'd rather not just
jump in there and make a patch without thinking it all through.
Someone might want to look at all places delaySetStoreClient() is called
as well as the above code segment and consider the cases I've mentioned in
the above paragraph and propose a patch.
I think what needs to be done is:
(1) delaySetStoreClient() all store clients for the forwarded request when
setting the delay id, make sure this is at a point that all future
store clients will be able to see that the request is forwarded to a
no delay peer
(2) make sure all requests check if the object they are requesting is coming
from a peer who is a no delay peer by some method whichi is compatible
with (1)
Comments?
David.
Received on Tue Jul 29 2003 - 13:15:54 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:58 MST