15 TCP_REFRESH_HIT/206
14566 TCP_REFRESH_HIT/304
I understand the REFRESH cases, but what about the first three? Under
what circumstances does a (non-REFRESH) cache hit none-the-less cause a
fetch to an origin server?
Thanks,
ht
--
Henry S. Thompson, School of Informatics, University of Edin
Amos Jeffries writes:
> On 6/08/2016 1:03 a.m., Henry S. Thompson wrote:
>> Amos wrote:
>>> HST wrote:
>> ...
>>>> Amos wrote:
>> ...
>>>>> HST wrote:
>>>>>> 3) I'm seeing very small numbers (1 in 10) of negat
Amos Jeffries writes:
> On 5/08/2016 12:37 a.m., Henry S. Thompson wrote:
>> Thanks for your patience with this, but still not quite getting it.
>>
>> I thought there were two cases:
>>
>> 1) Client drops the connection before the interaction is complete ==
&
eally mean "~100 _milliseconds_"? My understanding was that
kernel time differences were typically accurate to ~100 _nanoseconds_.
If you can easily tell me where to look in the source, obviously that's
what I should do
ht
--
Henry S. Thompson, School of Informati
Amos Jeffries writes:
> On 5/08/2016 12:37 a.m., Henry S. Thompson wrote:
>> Thanks for your patience with this, but still not quite getting it.
>>
>> I thought there were two cases:
>>
>> 1) Client drops the connection before the interaction is complete ==
&
me from End-time to get a negative.
> Note that its on the scale of ~100 milliseconds.
Sorry but I still don't see how two successive fetchs could result in a
decrement (w/o an NTP intervention).
The negative numbers I'm seeing range up into the low 1000s (of msec,
right? That's what
Amos Jeffries writes:
> On 4/08/2016 2:36 a.m., Henry S. Thompson wrote:
>> I'm trying to do some summary statistics based on log files from our
>> 2.6.STABLE18 setup.
>
> Please upgrade. The current 3.5.20 release can do everything that
> Squid-2.6 could do, and a
e be understood?
Sorry for these queries of mostly historical interest for most people,
but I've looked fairly hard for earlier discussion of these oddities w/o
success.
Thanks,
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinbur
Amos Jeffries writes:
> On 25/07/2016 10:34 p.m., Henry S. Thompson wrote:
>> Standard squid config only logs one CONNECT line for any https
>> transaction. What is being counted/timed by the reported bytes and
>> duration fields in that line?
>>
>> I'm
of the TLS connection
established by that CONNECT, but I can't find anything in the log
documentation which confirms that.
Thanks,
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
e log files and ask whoever looks after this
> network which machine has that address (or at least, what that
> subnet range is used for)
Will do.
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44)
Antony Stone writes:
> On Friday 26 Jun 2015 at 09:51, Henry S. Thompson wrote:
>
>> > logs will show the IP address that reached squid, ie. the source
>> > address of the connection. If that was NATted, squid will never know
>> > (and thus is not able to log
Leonardo Rodrigues writes:
> Em 24/06/15 15:28, Henry S. Thompson escreveu:
>> I've searched the documentation and mailing list archives w/o success,
>> and am not competent to read the source, so asking here: what is
>> logged as the 'remotehost' in Squ
menting NAT, or from a machine accessing the proxy via a VPN
connection?
Thanks,
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h.
14 matches
Mail list logo
