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 < rouss...@measurement-factory.com> 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@lists.squid-cache.org > > https://lists.squid-cache.org/listinfo/squid-users > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > https://lists.squid-cache.org/listinfo/squid-users >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
