There is no overhead on the client side, only on the server time logged Sent from ProtonMail mobile
-------- Original Message -------- On Jun 30, 2020, 20:14, Илья Шипицин wrote: > is that https publicly available? can you say it's url ? > > otherwise, https might add some overhead. can you compare http <-- > https > performance ? > > вт, 30 июн. 2020 г. в 21:32, Paul Belloc <[email protected]>: > >> it is https, I am not sure if ocsp stapling is enabled, how can I know ? >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> Le mardi 30 juin 2020 17:26, Илья Шипицин <[email protected]> a écrit : >> >>> is it https ? is ocsp stapling enabled ? >>> >>> вт, 30 июн. 2020 г. в 20:24, Paul Belloc <[email protected]>: >>> >>>> Hello, I have been struggling on this issue for some time. >>>> >>>> I am trying to monitor the total request time in haproxy 1.7.5 HTTP logs. >>>> My usecase is customers want to know the exact overhead of calling our >>>> service. Sometime we have complaints that we are adding overhead, and we >>>> know that our backend is fast, but we don't have the data to show the >>>> total overhead from the last end user point of view. >>>> >>>> So I started saving all haproxy HTTP logs in an ELK cluster. >>>> >>>> At this point I must say: we use http-server-close and option httplog. >>>> >>>> What I see is the Tr and Tt seem to depend on the TCP opening timer. The >>>> consequence is the logged time is good only for the first http request of >>>> a tcp connection, i.e the request that has a NI cookie-status. >>>> >>>> To show that, I can show the difference between querying the backend >>>> through haproxy using >>>> >>>> 1) CURL (no keep alive) >>>> >>>> Jun 30 17:18:23 19/0/0/3/22 200 1993 - - --NI 567/567/0/1/0 0/0 "GET >>>> /website/5be174f9a9403/tag.js HTTP/1.1" >>>> Jun 30 17:18:25 18/0/0/2/20 200 1993 - - --NI 449/449/0/1/0 0/0 "GET >>>> /website/5be174f9a9403/tag.js HTTP/1.1" >>>> Jun 30 17:18:28 19/0/0/2/21 200 1993 - - --NI 605/605/0/1/0 0/0 "GET >>>> /website/5be174f9a9403/tag.js HTTP/1.1" >>>> >>>> We see that there is 1 seconds between my two first curls, and that the Tr >>>> and Tt are similar. We see both are NI. Then there is 3 seconds between >>>> the 2 last curls, but the Tr and Tt is still similar. >>>> >>>> 2) Web browser (keep-alive) >>>> >>>> Jun 30 17:14:49 190305/0/0/4/190309 304 205 - - --VN 963/963/0/0/0 0/0 >>>> "GET /website/5be174f9a9403/tag.js HTTP/1.1" >>>> Jun 30 17:14:51 1940/0/0/1/1941 304 205 - - --VN 966/966/0/1/0 0/0 "GET >>>> /website/5be174f9a9403/tag.js HTTP/1.1" >>>> >>>> We see the first request has crazy Tt and Tr even if it was really fast on >>>> the client side. This is, I guess because of the idle time on the TCP >>>> connection. >>>> We see the second request has 2000 ms Tt / Tr, this is the time elapsed >>>> since the first request, plus the 'real' http response time. >>>> >>>> Now I wonder if this is normal behaviour and what are my options. >>>> >>>> I see: >>>> >>>> - Disable all form of keepalive, with a big performance cost >>>> - Monitor only the NI requests, with a risk of inconsistencies >>>> >>>> Is there another way ? Do I understand correctly what is going on ? >>>> >>>> Thank you
