Re: icp_no_misses

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

On Wed, 05 Nov 97 10:27:58 -0800 Duane Wessels wrote:

> martin@mrrl.lut.ac.uk writes:
>
> >I was thinking that for clusters of closely coupled caches dealing
> >with a very high volume of requests it might make more sense to have a
> >way of turning off the returning of ICP misses to nominated servers.
> >
> >This could put the requesting server in a sticky position, so I think
> >it would need to know that a particular peer wasn't going to be
> >returning ICP misses - say via an option in its cache_host directive.
> >It probably would also be necessary to be able to specify a
> >neighbor_timeout in terms of milliseconds rather than seconds, but I
> >don't know whether this is feasible.
> >
> >I'm wondering if there are any obvious flaws in this as an idea -
> >overlooking the actual implementation detail for now. What do people
> >think?
>
> I think the only possible problem would be with the timeouts.
>
> For Squid, the timeout handlers are now only checked once per select()
> or poll(). However, the ICP socket is checked much more frequently;
> for most versions its checked between every other filedescriptor we are
> selecting on. Squid-1.2 tries to be smarter than that....
>
> It could probably work by moving the FD timeouts to the event linked
> list, giving the event list sub-second resolution and checking it much
> more frequently than we do currently.

Sorry for the late answer.
Maybe we would need to configure different timeout values for different
neighbors.
As an examble we would (have to) accept higher timout values for
neighbors serving us with .com domain objects than for objects from
"European" sites.
And setting a value which is high enough for all neighbors could
indroduce high delays for all objects.

Ernst

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:44 MDT