Hi Willy,
Le 16/04/2020 17:00, « Willy Tarreau » <w...@1wt.eu> a écrit :
I'm a bit confused by how it can be efficiently used. Because it still
includes the client-side handshake which only happens before the first
request, so if you're interested in removing idle time from keep-alive
requests, Th should already be null and this should equal Ta. And for
the first request, indeed Ta doesn't include the handshake time, but
having some requests include Th and others not seems confusing to me.
I don't deny you can have a valid use case for it, but I'd like to
understand it better because I'm pretty sure that if anyone asks me
I'll be unable to suggest when to use it.
What I'm actually interested in is assessing real-world total time taken to
serve a client request (as seen from the client such as reported by cURL or in
a browser network performance tab, except for DNS lookup time) and making
statistics based on that. It doesn't really matter if Th is null after first
request as timing is still accurate because client didn't have to open a new
connection.
I initially thought about simply summing Ta and Th in configuration file, but
it took me a long time realizing this would be a good approach to end-to-end
time measurement.
As I thought some people might be interested in it too, I'm suggesting this new
timer. If there is too little interest, maybe a simple doc update could be
sufficient?
And maybe we'll even figure that another one is irrelevant and would
need to be slightly modified.
Last point (just a detail) I really hate having mixed case in a macro
name and just for this I think we should name it differently once we
figure the exact relevant use case.
It's indeed ugly, didn't come with a better idea and saw other usages with
mixed case so I thought it was the way to go, but I'll be glad to rename it to
a better suggestion :)
Thanks!
Willy
Cheers,
Damien
