<div dir="ltr"><div dir="ltr"><div><div class="gmail_default" style="font-family:tahoma,sans-serif"><font color="#741b47">> <span style="font-family:Arial,Helvetica,sans-serif">Please detail what you mean by "choice" or "decision". For example, do</span></font></div><font color="#741b47"><span class="gmail_default" style="font-family:tahoma,sans-serif">> </span>you want to stop the timer when Squid makes its final http_access decision?</font><br clear="all"></div><div><br></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">I mean I want to monitor the latency on what I could manage : the communication between client & squid, the time squid uses to process requests. But not the time spent by the destination server as I don't manage it.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">This could be multiple monitors if 1 is too complicated or not possible. So yes for example a timer that stop when Squid makes its final http_access decision (in case of http or bumped https) or its final ssl_bump splice decision.</div><br></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks a lot for your time !</div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><span><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:Montserrat,sans-serif;color:rgb(33,55,71);background-color:transparent;vertical-align:baseline"><br></span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:Montserrat,sans-serif;color:rgb(33,55,71);background-color:transparent;vertical-align:baseline">Cordialement, Regards,</span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:Montserrat,sans-serif;color:rgb(33,55,71);background-color:transparent;vertical-align:baseline"><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:Montserrat,sans-serif;color:rgb(33,55,71);background-color:transparent;font-weight:700;vertical-align:baseline">Benjamin DELANNOY </span></p></span></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2025 at 5:39 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2025-02-19 06:26, BENJAMIN DELANNOY wrote:<br>
<br>
> For %<pt : "The timer starts when the last request byte is sent to the <br>
> next hop and stops when the last response byte is received." Are we <br>
> talking of last request / last response of a single TCP connection on <br>
> server side ?<br>
<br>
I believe the short answer is "no": If Squid uses multiple TCP <br>
Squid-peer connections to forward a single client request, then the last <br>
connection used for that request forwarding should determine overall <br>
transaction outcome and %<pt values in access.log.<br>
<br>
<br>
> Do we agree that we are purely talking about <br>
> request/response on HTTP, and thus this time does not take into account <br>
> the time spent with SSL negotiation / squid actions before ?<br>
<br>
I believe the short answer is "yes": Today, %<pt timer starts after the <br>
HTTP (or FTP) request is written to the peer, so TLS handshake (if any) <br>
would happen before that timer starts. AFAIK, Squid does not support <br>
0-RTT TLS.<br>
<br>
<br>
> For %<tt : I understand that all the time spent sending requests & <br>
> waiting responses from the Origin are added. It would also means that if <br>
> I subtract this timer to %tr, I would have only the ClientSide time <br>
> before first packet is sent to Origin by the squid & after the last <br>
> packet is received from the Origin ?<br>
<br>
Yes, but "before" and "after" can be misleading here (in general) <br>
because there may be periods of time when Squid is _not_ talking to a <br>
peer but is working on what you call "ClientSide". For example, there is <br>
code that decides whether to revalidate a received peer response. From <br>
Squid point of view, that code runs on "ClientSide" -- %<tt timers may <br>
be stopped when that code runs. Since you are not caching, that <br>
particular code is not relevant to you.<br>
<br>
Also, please keep in mind that a slow client may effectively stall <br>
Squid-to-peer I/O by not consuming response data fast enough, filling <br>
Squid response buffers (see read_ahead_gap). If one only looks at "%tr - <br>
%<tt" difference in such cases, one would observe near-0 values and may <br>
mistakenly conclude that the slow client is super fast!<br>
<br>
<br>
<br>
> Actually, what I want to monitor, is the time between the first client <br>
> packet received on the Squid and the time the squid makes its choice :<br>
> - based on SNI for SSL Splice<br>
> - based on HTTP ACL (HTTP traffic or HTTPS traffic with SSL Bump)<br>
> Based on this, I would be able to check if a squid server is taking too <br>
> much time making a decision.<br>
> <br>
> Is this something feasible?<br>
<br>
Please detail what you mean by "choice" or "decision". For example, do <br>
you want to stop the timer when Squid makes its final http_access decision?<br>
<br>
<br>
Thank you,<br>
<br>
Alex.<br>
<br>
<br>
> On Mon, Feb 17, 2025 at 4:47 PM Alex Rousskov wrote:<br>
> <br>
> On 2025-02-17 10:02, BENJAMIN DELANNOY wrote:<br>
> <br>
> > I try to figure out what is exactly measured with the <pt & <tt<br>
> timings.<br>
> > I don't get what are the difference between them, what is the<br>
> difference<br>
> > between "peer response time" & "time spent forwarding to origin<br>
> > servers",<br>
> <br>
> Have you seen %<pt and %<tt descriptions at [1]? %<tt description was<br>
> updated in August 2024, and squid.conf.documented in Squid v6 and<br>
> earlier does not have those documentation updates (and the<br>
> corresponding<br>
> bug fixes)...<br>
> <br>
> [1] <a href="http://www.squid-cache.org/Doc/config/logformat/" rel="noreferrer" target="_blank">http://www.squid-cache.org/Doc/config/logformat/</a><br>
> <<a href="http://www.squid-cache.org/Doc/config/logformat/" rel="noreferrer" target="_blank">http://www.squid-cache.org/Doc/config/logformat/</a>><br>
> <br>
> <br>
> > what is the "last I/O with the last peer", etc.<br>
> <br>
> When forwarding a single client request, Squid may talk to multiple<br>
> cache_peer and origin server addresses (collectively called "peers").<br>
> Talking to a given peer may include multiple socket reading and writing<br>
> (i.e. I/O) events. Does this clarify?<br>
> <br>
> <br>
> <br>
> > For information, I aim to calculate the time spent on the<br>
> client-side &<br>
> > by squid processing time, excluding the server-side time spent<br>
> (=what I<br>
> > don't manage).<br>
> <br>
> This kind of calculation is a common need. Please keep in mind that<br>
> Squid may spend time on the client side (e.g., awaiting the next<br>
> request<br>
> body byte) while also spending time on the server side (e.g., awaiting<br>
> the next response body byte), complicating things.<br>
> <br>
> If existing %codes are not enough, please detail your needs in terms of<br>
> events that Squid can recognize (e.g., receiving the first response<br>
> header byte or sending the last request body byte).<br>
> <br>
> <br>
> HTH,<br>
> <br>
> Alex.<br>
> <br>
> <br>
> <br>
> <br>
> > We do not use squid for caching but only for http & ssl<br>
> proxy/filtering.<br>
> ><br>
> > Thanks a lot !<br>
> ><br>
> ><br>
> > Cordialement, Regards,<br>
> ><br>
> ><br>
> > Benjamin DELANNOY<br>
> ><br>
> > Cloud Network Engineer<br>
> ><br>
> > NETWORK SOLUTIONS - GTDP<br>
> ><br>
> > Mobile +33 (0)6 16 98 23 72<br>
> ><br>
> ><br>
> > 135 rue Sadi Carnot • CS 00001 • 59790 Ronchin • FRANCE<br>
> ><br>
> > <a href="http://positivetech.adeo.com" rel="noreferrer" target="_blank">positivetech.adeo.com</a> <<a href="http://positivetech.adeo.com" rel="noreferrer" target="_blank">http://positivetech.adeo.com</a>><br>
> <<a href="https://positivetech.adeo.com/" rel="noreferrer" target="_blank">https://positivetech.adeo.com/</a> <<a href="https://positivetech.adeo.com/" rel="noreferrer" target="_blank">https://positivetech.adeo.com/</a>>><br>
> ><br>
> > adeolinkedin <<a href="https://www.linkedin.com/company/groupe-adeo" rel="noreferrer" target="_blank">https://www.linkedin.com/company/groupe-adeo</a><br>
> <<a href="https://www.linkedin.com/company/groupe-adeo" rel="noreferrer" target="_blank">https://www.linkedin.com/company/groupe-adeo</a>>><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > squid-users mailing list<br>
> > <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
> <mailto:<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a>><br>
> > <a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a><br>
> <<a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a>><br>
> <br>
> _______________________________________________<br>
> squid-users mailing list<br>
> <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
> <mailto:<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a>><br>
> <a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a><br>
> <<a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a>><br>
> <br>
<br>
</blockquote></div></div>