stable-bot: Bugfixes waiting for a release 2.1 (4)
Hi,
This is a friendly bot that watches fixes pending for the next haproxy-stable
release! One such e-mail is sent periodically once patches are waiting in the
last maintenance branch, and an ideal release date is computed based on the
severity of these fixes and their merge date. Responses to this mail must be
sent to the mailing list.
Last release 2.1.7 was issued on 2020-06-09. There are currently 4 patches in
the queue cut down this way:
- 3 MEDIUM, first one merged on 2020-06-12
- 1 MINOR, first one merged on 2020-06-12
Thus the computed ideal release date for 2.1.8 would be 2020-07-10, which is in
two weeks or less.
The current list of patches in the queue is:
- 2.1 - MEDIUM : log: don't hold the log lock during
writev() on a file descriptor
- 2.1 - MEDIUM : ssl: crt-list must continue parsing on
ERR_WARN
- 2.1 - MEDIUM : pattern: fix thread safety of pattern
matching
- 2.1 - MINOR : ssl: fix ssl-{min,max}-ver with
openssl < 1.1.0
--
The haproxy stable-bot is freely provided by HAProxy Technologies to help
improve the quality of each HAProxy release. If you have any issue with these
emails or if you want to suggest some improvements, please post them on the
list so that the solutions suiting the most users can be found.
Re: Monitoring the total request time in haproxy 1.7.5 HTTP logs
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 : > >> 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, Илья Шипицин a écrit : >> >>> is it https ? is ocsp stapling enabled ? >>> >>> вт, 30 июн. 2020 г. в 20:24, Paul Belloc : >>> 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
Re: Monitoring the total request time in haproxy 1.7.5 HTTP logs
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 : > 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, Илья Шипицин a écrit : > > is it https ? is ocsp stapling enabled ? > > вт, 30 июн. 2020 г. в 20:24, Paul Belloc : > >> 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 >> > >
Re: Monitoring the total request time in haproxy 1.7.5 HTTP logs
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, Илья Шипицин a écrit : > is it https ? is ocsp stapling enabled ? > > вт, 30 июн. 2020 г. в 20:24, Paul Belloc : > >> 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
Re: Monitoring the total request time in haproxy 1.7.5 HTTP logs
is it https ? is ocsp stapling enabled ? вт, 30 июн. 2020 г. в 20:24, Paul Belloc : > 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 >
Monitoring the total request time in haproxy 1.7.5 HTTP logs
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
Bid Writing Workshops Via Zoom
NFP WORKSHOPS 18 Blake Street, York YO1 8QG Affordable Training Courses for Charities, Schools & Public Sector Organisations This email has been sent to haproxy@formilux.org CLICK TO UNSUBSCRIBE FROM LIST Alternatively send a blank e-mail to unsubscr...@nfpmail2001.co.uk quoting haproxy@formilux.org in the subject line. Unsubscribe requests will take effect within seven days. Bid Writing: The Basics Online via ZOOM START 13.30 FINISH 16.00 COST £95.00 TOPICS COVERED Do you know the most common reasons for rejection? Are you gathering the right evidence? Are you making the right arguments? Are you using the right terminology? Are your numbers right? Are you learning from rejections? Are you assembling the right documents? Do you know how to create a clear and concise standard funding bid? Are you communicating with people or just excluding them? Do you know your own organisation well enough? Are you thinking through your projects carefully enough? Do you know enough about your competitors? Are you answering the questions funders will ask themselves about your application? Are you submitting applications correctly? PARTICIPANTS Staff members, volunteers, trustees or board members of charities, schools, not for profits or public sector organisations who intend to submit grant funding applications to charitable grant making trusts and foundations. People who provide advice to these organisations are also welcome. BOOKING DETAILS Participants receive full notes and sample bids by e-mail after the workshop. The workshop consists of talk, questions and answers. There are no power points or audio visuals used. All places must be booked through the online booking system using a debit card, credit card or paypal. We do not issue invoices or accept bank or cheque payments. If you do not have a payment card from your organisation please use a personal one and claim reimbursement using the booking confirmation e-mail as proof of purchase. BOOKING TERMS Workshop bookings are non-cancellable and non-refundable. If you are unable to participate on the booked date you may allow someone else to log on in your place. There is no need to contact us to let us know that there will be a different participant. Bookings are non-transferable between dates unless an event is postponed. If an event is postponed then bookings will be valid on any future scheduled date for that workshop. QUESTIONS If you have a question please e-mail questi...@nfpmail2001.co.uk You will usually receive a response within 24 hours. Due to our training commitments we are unable to accept questions by phone. Bid Writing: Advanced Online via ZOOM START 13.30 FINISH 16.00 COST £95.00 TOPICS COVERED Are you applying to the right trusts? Are you applying to enough trusts? Are you asking for the right amount of money? Are you applying in the right ways? Are your projects the most fundable projects? Are you carrying out trust fundraising in a professional way? Are you delegating enough work? Are you highly productive or just very busy? Are you looking for trusts in all the right places? How do you compare with your competitors for funding? Is the rest of your fundraising hampering your bids to trusts? Do you understand what trusts are ideally looking for? PARTICIPANTS Staff members, volunteers, trustees or board members of charities, schools, not for profits or public sector organisations who intend to submit grant funding applications to charitable grant making trusts and foundations. People who provide advice to these organisations are also welcome. BOOKING DETAILS Participants receive full notes and sample bids by e-mail after the workshop. The workshop consists of talk, questions and answers. There are no power points or audio visuals used. All places must be booked through the online booking system using a debit card, credit card or paypal. We do not issue invoices or accept bank or cheque payments. If you do not have a payment card from your organisation please use a personal one and claim reimbursement using the booking confirmation e-mail as proof of purchase. BOOKING TERMS Workshop bookings are non-cancellable and non-refundable. If you are unable to participate on the booked date you may allow someone else to log on in your place. There is no need to contact us to let us know that there will be a different participant. Bookings are non-transferable between dates unless an event is postponed. If an event is postponed then bookings will be valid on any future scheduled date for that workshop. QUESTIONS If you have a question please e-mail questi...@nfpmail2001.co.uk You will usually receive a response within 24 hours. Due to our training commitments we are unable to accept questions by phone. Dates & Booking Links BID WRITING: THE BASICS Mon 29 Jun 2020Booking Link Mon 13 Jul 2020Booking Link Mon 27 Jul 2020Booking Link Mon 10 Aug 2020Booking
