[squid-users] Time for cache synchronization between siblings

[Sreenath BH]

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 at treenet.co.nz> 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>