Try disabling the use of ICP. It is completely useless if you only have
one parent and cannot go direct, and there are some obvious issues with
packet loss and RTT variance between the peers. The best application of
ICP is sibling peerings between tightly connected caches.
Try this config:
cache_peer your.parent.proxy 80 0 no-query default
acl all src 0.0.0.0/0
never_direct allow all
And if you have some domains/servers which you'd like to handle locally:
acl intranet dstdomain intranet.your.domain
always_direct allow intranet
I also have a some patches to make Squid a bit more persistent in trying
to find a parent proxy when running inside a firewall (never_direct).
See http://squid.sourceforge.net/hno/
-- Henrik Nordstrom Squid hacker Dani Tal wrote: > > I would like to apologize for addressing directly to you, I have tried > the group but they did not notice me and I see you enjoy answering > squid staff , so what do you think on the following ? > > =è > > We are running squid/2.2.stable4, up and running for quit a while. > > There is only one annoying problem we where unable to resolve. > > When accessing our Siemens Intarnet via a cache_peer (Netscape proxy > located on the remote site, slow 128K line ) we get from time to time > only parts of the page displayed, the other parts display errors like > "Error The requested URL could not be retrieved" on parts of the page. > If I wait 30 seconds and try to follow the link, must of the time I > can resolve the problem. > > If I change my proxy configuration to point to the remote Netscape > proxy I always get the page correctly, so this must be a Squid > problem. > > I think that the problem is that Squid "gives up " to soon to resolve > the link. How do I set it to wait longer for the link resolve ? > > We are not on the same DNS zone and can't resolve DNS name directly, > The Netscape proxy is probably doing it for us when we surf on the > Intarnet, so this doesn't look like the DNS TTL described in the FAQ. > > Any suggestions ? > > Dani TalReceived on Sun Apr 09 2000 - 11:46:31 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:52:52 MST