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 <paul.bel...@protonmail.com>: > 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, Илья Шипицин <chipits...@gmail.com> a écrit : > > is it https ? is ocsp stapling enabled ? > > вт, 30 июн. 2020 г. в 20:24, Paul Belloc <paul.bel...@protonmail.com>: > >> 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 >> > >
