Mohamed Lrhazi wrote:
>On Thu, 2006-03-30 at 14:17 -0500, Mohamed Lrhazi wrote:
>
>
>>I am trying to configure a bunch of SQUIDs as httpd_accelerators and
>>in my first tests I could never get a HIT from a sibling... though ICP
>>quesries are sent and UDP_HITS are recieved, SQUID always prefers to
>>fetch from the origine server! I would always get TCP TIMEOUT code ,
>>untill I changes the minimum_direct_rtt to set it to zero. Now I
>>always get TCP_MISS:DIRECT
>>
>>I enabled debuging of peer selection and it shows it clearly, please
>>see the output bellow.
>>
>>First my config, then the debuging output:
>>
>>icp_hit_stale on
>>icp_query_timeout 10000
>>
>>
Seriously? A 10 second icp_query_timeout?
>>minimum_direct_rtt 0
>>prefer_direct off
>>dead_peer_timeout 3600 seconds
>>
>>
And a dead peer timeout of an hour? Yikes.
>>http_port 80
>>httpd_accel_host 192.168.1.72
>>httpd_accel_port 80
>>httpd_accel_single_host on
>>httpd_accel_uses_host_header on
>>httpd_accel_with_proxy on
>>
>>cache_peer 192.168.1.224 sibling 3128 3130 allow-miss no-netdb-exchange
>>cache_peer 192.168.1.223 sibling 3128 3130 allow-miss no-netdb-exchange
>>cache_peer 192.168.1.222 sibling 3128 3130 allow-miss no-netdb-exchange
>>cache_peer 192.168.1.221 sibling 3128 3130 allow-miss no-netdb-exchange
>>icp_port 3130
>>
>>
>>
>>
SNIP
>>How can I get SQUID to use the peers if they have the object and only
>>use origine if not?
>>
>>Thanks alot, this is driving me nutts, while Googling around I found
>>my own post asking the acact same question right here on this list,
>>almost two years ago!!!
>>
>>Mohamed~
>>
>>
>Hello,
>
>I was trying to use multicast when I first run into this problem... so i
>moved to unicast to make solve the issue first... it turns our in
>unicast the problem was simple the http port number in the cache-peer
>param was wrong. SQUID was indeed trying to connect to the peers but
>fails and only then does it connect to the origin server. I had to use
>debug All,9 to see this mistake!
>
>Now I switched back to multicast and the problem is indeed still there.
>in the full debug mode I see the peer requets sent and then immidiately
>the DIRECT path is used... later the UDP_HIT arrives, but too late!
>
>
>
So what do your cache_peer statements look like now? Also, give that
you had a icp_query_timeout value of 10000, have you changed
mcast_icp_query_timeout? Most importantly, have you read the FAQ
section on Squid and Multicast
(http://www.squid-cache.org/Doc/FAQ/FAQ-13.html)? Since you "only" have
5 cache peers, I'm not certain that you are going to see much benefit to
multi casting ICP queries.
>icpHandleIcpV2: ICP_HIT from 192.168.1.223 for 'http://neo.your-sit...
>neighborsUdpAck: opcode 2 '05035B177B8F5803075FB0466EB6C8AA'
>storeGet: looking up 05035B177B8F5803075FB0466EB6C8AA
>whichPeer: from 192.168.1.223 port 3130
>neighborsUdpAck: '05035B177... already being fetched.
>
>
>Is this a bug?
>
>Thanks a lot.
>Mohamed~
>
>
>
>
Chris
Received on Sat Apr 01 2006 - 00:05:29 MST
This archive was generated by hypermail pre-2.1.9 : Mon May 01 2006 - 12:00:01 MDT