Thanks for the answer.
Yes I saw the updates for %<pt and %<tt but I still don't get it.
For %<pt : " The timer starts when the last request byte is sent to the next hop and stops when the last response byte is received." Are we talking of last request / last response of a single TCP connection on server side ? Do we agree that we are purely talking about request/response on HTTP, and thus this time does not take into account the time spent with SSL negotiation / squid actions before ?
For %<tt : I understand that all the time spent sending requests & waiting responses from the Origin are added. It would also means that if I subtract this timer to %tr, I would have only the ClientSide time before first packet is sent to Origin by the squid & after the last packet is received from the Origin ?
Actually, what I want to monitor, is the time between the first client packet received on the Squid and the time the squid makes its choice :
- based on SNI for SSL Splice
- based on HTTP ACL (HTTP traffic or HTTPS traffic with SSL Bump)
Based on this, I would be able to check if a squid server is taking too much time making a decision.
Is this something feasible?
Cordialement, Regards,
Benjamin DELANNOY
On Mon, Feb 17, 2025 at 4:47 PM Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 2025-02-17 10:02, BENJAMIN DELANNOY wrote:
> I try to figure out what is exactly measured with the <pt & <tt timings.
> I don't get what are the difference between them, what is the difference
> between "peer response time" & "time spent forwarding to origin
> servers",
Have you seen %<pt and %<tt descriptions at [1]? %<tt description was
updated in August 2024, and squid.conf.documented in Squid v6 and
earlier does not have those documentation updates (and the corresponding
bug fixes)...
[1] http://www.squid-cache.org/Doc/config/logformat/
> what is the "last I/O with the last peer", etc.
When forwarding a single client request, Squid may talk to multiple
cache_peer and origin server addresses (collectively called "peers").
Talking to a given peer may include multiple socket reading and writing
(i.e. I/O) events. Does this clarify?
> For information, I aim to calculate the time spent on the client-side &
> by squid processing time, excluding the server-side time spent (=what I
> don't manage).
This kind of calculation is a common need. Please keep in mind that
Squid may spend time on the client side (e.g., awaiting the next request
body byte) while also spending time on the server side (e.g., awaiting
the next response body byte), complicating things.
If existing %codes are not enough, please detail your needs in terms of
events that Squid can recognize (e.g., receiving the first response
header byte or sending the last request body byte).
HTH,
Alex.
> We do not use squid for caching but only for http & ssl proxy/filtering.
>
> Thanks a lot !
>
>
> Cordialement, Regards,
>
>
> Benjamin DELANNOY
>
> Cloud Network Engineer
>
> NETWORK SOLUTIONS - GTDP
>
> Mobile +33 (0)6 16 98 23 72
>
>
> 135 rue Sadi Carnot • CS 00001 • 59790 Ronchin • FRANCE
>
> positivetech.adeo.com <https://positivetech.adeo.com/>
>
> adeolinkedin <https://www.linkedin.com/company/groupe-adeo>
>
>
>
> _______________________________________________
> squid-users mailing list
> squid-users@xxxxxxxxxxxxxxxxxxxxx
> https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
