Re: [RFC] byte hit ratio

On 02/07/2012 05:00 AM, Amos Jeffries wrote:
> On 7/02/2012 9:40 p.m., Henrik Nordström wrote:
>> tis 2012-02-07 klockan 14:01 +1300 skrev Amos Jeffries:
>>> We have a long history of questions and bugs mentioning negative
>>> numbers in the byte hit ratio.
>>>
>>> I've always thought it was a bug we had not tracked down, but the FAQ
>>> says it is correct.
>>> http://wiki.squid-cache.org/SquidFaq/InnerWorkings#Why_do_I_see_negative_byte_hit_ratio.3F
>>>
>> Yes.. it's based on the difference between traffic squid<-servers and
>> clients<-squid. This can be negative (more traffic squid<-servers than
>> clients<-squid) in some situations.
>>
>> - retried requests
>> - range retreival being processed by Squid
>> - continued download after client disconnects (quick_abort_...)
>
> Wiki also mentions cache digests but ...
> " /*
> * This ugly hack is here to prevent the user from seeing a
> * negative byte hit ratio. When we fetch a cache digest from
> * a neighbor, it gets treated like a cache miss because the
> * object is consumed internally. Thus, we subtract cache
> * digest bytes out before calculating the byte hit ratio.
> */
> cd = CountHist[0].cd.kbytes_recv.kb -
> CountHist[minutes].cd.kbytes_recv.kb;
> "

I think that hack should be removed (why would we want to lie about
bandwidth usage?) but I may be missing some deeper reasons why it was added.

>
> Which one is inaccurate?
> "Hits as % of traffic sent" with calculation of (net traffic / client
> bytes)
> or
> "Net traffic gain/loss" with calculation of (net traffic / client_bytes)
> or
> "Hits as % of client traffic" with calculation of ( sum_hits /
> client_bytes )
>
> One guess which one we have today ...

I think the bandwidth G/L formula should be something like:

    (client - server) / client

Note how it is independent from the definition of what a "hit" is.

The name is a separate question.

We could use a similar formula to report "hit ratio" as well (just use
message counts instead of bytes) but that would be somewhat against the
"standard practice". I am not against adding a separate "message G/L"
line for that.

HTH,

Alex.
Received on Tue Feb 07 2012 - 18:48:46 MST