Re: zlib vs slz (perfoarmance)
> On 29.03.2021., at 23:06, Lukas Tribus wrote: > […] > Like I said last year, this needs a marketing campaign: > https://www.mail-archive.com/haproxy@formilux.org/msg38044.html > > > What about the docker images from haproxytech? Are those zlib or slz > based? Perhaps that would be a better starting point? > > https://hub.docker.com/r/haproxytech/haproxy-alpine Hi Lukas, I am maintaining haproxytech Docker images and I can easily make that (slz being used) happen, if that’s what community would like to see. Kind regards, D. -- Dinko Korunic ** Standard disclaimer applies ** Sent from OSF1 osf1v4b V4.0 564 alpha
Re: Is there a way to deactivate this "message repeated x times"
On 29.03.21 18:55, Lukas Tribus wrote:
Hello,
On Mon, 29 Mar 2021 at 15:25, Aleksandar Lazic wrote:
Hi.
I need to create some log statistics with awffull stats and I assume this
messages
means that only one line is written for 3 requests, is this assumption right?
Mar 28 14:04:07 lb1 haproxy[11296]: message repeated 3 times: [ ::::49445 [28/Mar/2021:14:04:07.234]
https-in~ be_api/api_prim 0/0/0/13/13 200 2928 - - 930/900/8/554/0 0/0 {|Mozilla/5.0 (Macintosh; Intel
Mac OS X 10.13; rv:86.0) Gecko/20100101 Firefox/86.0||128|TLS_AES_128_GCM_SHA256|TLSv1.3|} "GET
https:/// HTTP/2.0"]
Can this behavior be disabled?
This is not haproxy, this is your syslog server. Refer to the
documentation of the syslog server.
Oh yes of course, *clap on head*.
Looks like the RepeatedMsgReduction is on Ubuntu 18.04.5 LTS is this by default
on.
https://www.rsyslog.com/doc/v8-stable/configuration/action/rsconf1_repeatedmsgreduction.html
I have solved it with this ansible snipplet.
```
- name: Deactivate RepeatedMsgReduction in rsyslog
lineinfile:
backup: yes
line: $RepeatedMsgReduction off
path: /etc/rsyslog.conf
regexp: '^\$RepeatedMsgReduction on'
tags: haproxy,all,syslog
register: syslog
- name: Restart syslog
service:
name: rsyslog
state: restarted
when: syslog.changed
tags: haproxy,all,syslog
```
Lukas
Regards
Alex
Re: zlib vs slz (perfoarmance)
Hello, On Mon, 29 Mar 2021 at 20:54, Илья Шипицин wrote: >> > Dear list, >> > >> > on browser load (html + js + css) I observe 80% of cpu spent on gzip. >> > also, I observe that zlib is probably one of the slowest implementation >> > my personal benchmark correlate with https://github.com/inikep/lzbench >> > >> > if so, should'n we switch to slz by default ? or am I missing something ? >> >> There is no default. >> >> zlib is optional. >> slz is optional. >> >> Haproxy is compiled with either zlib, slz or no compression library at all. >> >> >> What specifically are you suggesting to change in the haproxy source tree? > > > for example, docker image > https://hub.docker.com/_/haproxy So nothing we control directly. Docker images, package repositories, etc. This means filing requests at those places, convincing other people to switch from a well known library to an unknown library that isn't even packaged yet in most places, that those maintainers then have to support. I'm not sure how realistic that is. Like I said last year, this needs a marketing campaign: https://www.mail-archive.com/haproxy@formilux.org/msg38044.html What about the docker images from haproxytech? Are those zlib or slz based? Perhaps that would be a better starting point? https://hub.docker.com/r/haproxytech/haproxy-alpine Lukas
Re: zlib vs slz (perfoarmance)
пн, 29 мар. 2021 г. в 19:35, Lukas Tribus : > Hi Ilya, > > > On Mon, 29 Mar 2021 at 15:34, Илья Шипицин wrote: > > > > Dear list, > > > > on browser load (html + js + css) I observe 80% of cpu spent on gzip. > > also, I observe that zlib is probably one of the slowest implementation > > my personal benchmark correlate with https://github.com/inikep/lzbench > > > > if so, should'n we switch to slz by default ? or am I missing something ? > > There is no default. > > zlib is optional. > slz is optional. > > Haproxy is compiled with either zlib, slz or no compression library at all. > > > What specifically are you suggesting to change in the haproxy source tree? > for example, docker image https://hub.docker.com/_/haproxy > > > Regards, > Lukas >
Re: Is there a way to deactivate this "message repeated x times"
Hello,
On Mon, 29 Mar 2021 at 15:25, Aleksandar Lazic wrote:
>
> Hi.
>
> I need to create some log statistics with awffull stats and I assume this
> messages
> means that only one line is written for 3 requests, is this assumption right?
>
> Mar 28 14:04:07 lb1 haproxy[11296]: message repeated 3 times: [
> ::::49445 [28/Mar/2021:14:04:07.234] https-in~ be_api/api_prim
> 0/0/0/13/13 200 2928 - - 930/900/8/554/0 0/0 {|Mozilla/5.0
> (Macintosh; Intel Mac OS X 10.13; rv:86.0) Gecko/20100101
> Firefox/86.0||128|TLS_AES_128_GCM_SHA256|TLSv1.3|} "GET
> https:/// HTTP/2.0"]
>
> Can this behavior be disabled?
This is not haproxy, this is your syslog server. Refer to the
documentation of the syslog server.
Lukas
Re: zlib vs slz (perfoarmance)
Hi Ilya, On Mon, 29 Mar 2021 at 15:34, Илья Шипицин wrote: > > Dear list, > > on browser load (html + js + css) I observe 80% of cpu spent on gzip. > also, I observe that zlib is probably one of the slowest implementation > my personal benchmark correlate with https://github.com/inikep/lzbench > > if so, should'n we switch to slz by default ? or am I missing something ? There is no default. zlib is optional. slz is optional. Haproxy is compiled with either zlib, slz or no compression library at all. What specifically are you suggesting to change in the haproxy source tree? Regards, Lukas
zlib vs slz (perfoarmance)
Dear list, on browser load (html + js + css) I observe 80% of cpu spent on gzip. also, I observe that zlib is probably one of the slowest implementation my personal benchmark correlate with https://github.com/inikep/lzbench if so, should'n we switch to slz by default ? or am I missing something ? Ilya
Is there a way to deactivate this "message repeated x times"
Hi.
I need to create some log statistics with awffull stats and I assume this
messages
means that only one line is written for 3 requests, is this assumption right?
Mar 28 14:04:07 lb1 haproxy[11296]: message repeated 3 times: [ ::::49445 [28/Mar/2021:14:04:07.234]
https-in~ be_api/api_prim 0/0/0/13/13 200 2928 - - 930/900/8/554/0 0/0 {|Mozilla/5.0 (Macintosh; Intel
Mac OS X 10.13; rv:86.0) Gecko/20100101 Firefox/86.0||128|TLS_AES_128_GCM_SHA256|TLSv1.3|} "GET
https:/// HTTP/2.0"]
Can this behavior be disabled?
Regards
Alex
Re: HTTP/2 and compression
I have tried it and it works with HTTP/2. I have sent a patch in another thread to clarify the documentation. On 29 Mar 10:45, Julien Pivotto wrote: > > Hello there, > > I read in the HAProxy configuration: > https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4.2-compression%20algo > > ``` > Compression is disabled when: > > * the response message is not HTTP/1.1 > ``` > > Did we forget to add HTTP/2 in the docs, or we do not support it for HTTP/2? > > > Regards, > > -- > (o-Julien Pivotto > //\Open-Source Consultant > V_/_ Inuits - https://www.inuits.eu -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Patch: DOC: clarify that compression works for HTTP/2
Dear, Please find a patch attached with a small fix for the documentation. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu From 359e386c711276c554eb8b9f07476017b6128519 Mon Sep 17 00:00:00 2001 From: Julien Pivotto Date: Mon, 29 Mar 2021 12:41:40 +0200 Subject: [PATCH] DOC: clarify that compression works for HTTP/2 This patch clarifies that compression also works with HTTP/2. I have picked the wording "HTTP/1.1 or above" because it is already used elsewhere in the documentation. I have tested that compression indeed works in HTTP/2. Signed-off-by: Julien Pivotto --- doc/configuration.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 7048fb63e..7862ce34e 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -4215,7 +4215,7 @@ compression offload Compression is disabled when: * the request does not advertise a supported compression algorithm in the "Accept-Encoding" header -* the response message is not HTTP/1.1 +* the response message is not HTTP/1.1 or above * HTTP status code is not one of 200, 201, 202, or 203 * response contain neither a "Content-Length" header nor a "Transfer-Encoding" whose last value is "chunked" -- 2.28.0 signature.asc Description: PGP signature
HTTP/2 and compression
Hello there, I read in the HAProxy configuration: https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4.2-compression%20algo ``` Compression is disabled when: * the response message is not HTTP/1.1 ``` Did we forget to add HTTP/2 in the docs, or we do not support it for HTTP/2? Regards, -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [PATCH] fine guard for ssl random extraction functions
On 3/26/21 3:10 PM, William Lallemand wrote: > On Fri, Mar 26, 2021 at 03:02:27PM +0100, Willy Tarreau wrote: >> On Fri, Mar 26, 2021 at 06:45:22PM +0500, ??? wrote: >>> Ping :) >> >> Ilya, please use the MAINTAINERS file to be sure to direct your messages >> to the relevant maintainers, because each time you forward them to me, I >> forward them in turn and the integration of your work gets needlessly >> delayed. > > I agree. You can also wait more than 1 day before doing a "ping" for a > minor patch, it's more likely that we didn't read it yet than we missed > it. > >> @Emeric, @William, could one of you please have a look ? >> > > I'll take a look. > All patches pushing ssl library feature detection on ssl-compat.h are welcome. This patch sounds good to me. Emeric
