Hi, Thanks for the tips. After disabling digest I believe performance improved. However, I found that randomly requests were being routed to parent even when siblings had the data cached. >From access.log I found TIMEOUT_CARP. I assumed this meant HTCP timed out and squid was forced to go to fetch the data. So I increased icp_query_timeout to 4000 milliseconds, and the hit rate increased further. But I still find that sometimes, even after getting a HIT response from a sibling, squid, for some reason still decides to go to the parent for requested object. Are there any other reasons why squid will decide to go to parent servers? And another question: When the hash key is computed for storing cache objects, does Squid use the hostname(or IP address) also as part of URL, or just the part that appears after the hostname/IP:port numbers? For example: if ip address is squid servers is 10.135.85.2 and 10.135.85.3, and a request made to 1st server would have had the IP address as part of the URL. However, next time same request is made to server2, a different IP address would be used. Does this affect cache hit at the sibling server? I think it should not, but is this the case? We will have a load balancer that sends requests to each squid server, and we want cache peering to work correctly in this case. thanks, Sreenath On 12/16/15, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 16/12/2015 7:16 a.m., Sreenath BH wrote: >> Hi, >> >> I have a setup with three squid peers (siblings in squid.conf) and >> three upstream servers(peers with parent and originserver in >> squid.conf). >> >> I am using htcp for the three squid siblings. >> How much time does it take for one squid server to 'know' that another >> peer has a particular object cached? I see digests exchanged between >> the siblings, as logged in cache.log. > > When both HTCP an dDgests are active between siblings the maximum time > is however long it takes for the HTCP packet to reach the sibling, be > parsed, looked up in the cache and response to get back. > > Digests are used to short-circuit the ICP or HTCP process. If the digest > contains an entry for the URL the peer will be selected as a possible > destination server. Regardless of whether the object stored for that URL > is the same one the client is fetching. > > Digests are updated every digest_rebuild_period (default 1 hr). You can > disable digests with either "digest_generation off" or per-peer with the > cache_peer no-digest option. > > >> >> I have been able to make a request to one sibling and it resulted in a >> sibling_hit. >> >> How I do this test is this: >> 1. bring up all siblings >> 2. issue a request to one server (sibling 1) >> 3. Make sure it is cached in sibling 1 >> 4. Wait for some time (I don't know how long to wait) > > Until the log of sibling1 contains a digest fetch from sibling2. A > restart of sibling2 will make that happen faster. > >> 5. Make same request to another sibling, say sibling 2 >> 6. Check if it went to upstream server for the request or it was a sibling >> hit. >> >> My problem is that the sibling hits seem to be random. I am not able >> to figure out exactly >> how log it takes for the cache information to propagate to all siblings. > > Digest is a old algorithm designed as an optimization of ICP, and > likewise is based on URL alone - which is great for HTTP/1.0 traffic. In > modern HTTP/1.1 traffic the Vary headers have a big part to play and > HTCP with full-header lookups works much better. > > I suggest trying with only HTCP (digests disabled) and see if your > performance improves at all. YMMV though. > > Be aware that there is no guarantee that any object is still in cache, > even with the more reliable HTCP on-demand lookups. Any object could be > dropped from sibling1 cache picoseconds after the "i have it" reply > started being formed for delivery to sibling2 (before it even hits the > wire on its way back). > > Amos > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
