Re: HAProxy 1.7.9 very slow with HTTP compression
Hi Nick, Am 31.08.2017 um 14:16 schrieb Nick Stolwijk: > Today we noticed something strange after updating our HAProxy to 1.7.9. A > request which took a mere second before now takes a whopping 45 seconds. > > After some playing around, we found that if we turned off the compression on > HAProxy it was back to fast again. > Try the patch from the thread: "HTTP/1.0 with compression enabled broken again in v1.7.9" https://www.mail-archive.com/haproxy@formilux.org/msg27155.html Lukas
HAProxy 1.7.9 very slow with HTTP compression
Today we noticed something strange after updating our HAProxy to 1.7.9. A request which took a mere second before now takes a whopping 45 seconds. After some playing around, we found that if we turned off the compression on HAProxy it was back to fast again. We are running HA-Proxy version 1.7.9-1ppa1~trusty 2017/08/19 on Ubuntu 14.04. Our compression configuration: compression algo gzip compression type text/html text/plain text/css image/svg+xml text/xml application/xml application/javascript application/json application/pdf Without compression: $ curl --user user:pass https://host/path/to/pdf -o /tmp/pdf -D headers -H "Accept-Encoding: gzip" % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 137k0 137k0 0 64537 0 --:--:-- 0:00:02 --:--:-- 65102 $ cat headers HTTP/1.1 200 OK X-Powered-By: Undertow/1 X-Powered-By: Undertow/1 Set-Cookie: JSESSIONID=sessionid; path=/; HttpOnly; Max-Age=36000; Expires=Thu, 31-Aug-2017 22:10:49 GMT Set-Cookie: access_token=eyJjdHkiOiJKV1QiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiZGlyIn0..v5kb6ns9zt7F0_3F.fPNbj9CWN9gfpCHR8--tfse2xEKDEM22hsSUCIF0KNRTq9pjd3Tl84fAl_tN9rO66ScYaoIMwvgeb89sGV_mYoTG1myJvbVF26RXXTToa3oOCTL9LzqD9pbAa08CSUSS7YEhP5ia7XawX5G2uWqM9qk6nxet-ESDtAN9HRTKeX9UlPwMHcD7Kkow76F2btlZyxoelO0xqnuTt9C1r0_uVxWhOPdcbmdJLB_UrJr6IQpLPsSPf7TgAZVdDwVo7imm8O4eTIModtuVllXEq3dAk5PF5SHhg8W1iFl5Pw.3ssYrnKKFRiZNeP0g9baZQ; path=/; Max-Age=36000; Expires=Thu, 31-Aug-2017 22:10:49 GMT Access-Control-Allow-Headers: origin, content-type, accept, authorization Server: WildFly/10 Server: WildFly/10 Content-Disposition: inline; filename=OBE_11_Bodegraven - Woerden_000200804_O.pdf Date: Thu, 31 Aug 2017 12:10:49 GMT Connection: close Access-Control-Allow-Origin: * Vary: Accept Access-Control-Allow-Credentials: true Content-Type: application/pdf Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD Access-Control-Max-Age: 1209600 Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; With compression: $ curl --user nick.user:pass https://host/path/to/pdf -o /tmp/pdf -D headers -H "Accept-Encoding: gzip" % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 137k0 137k0 0 3078 0 --:--:-- 0:00:45 --:--:-- 39398 $ cat headers HTTP/1.1 200 OK X-Powered-By: Undertow/1 X-Powered-By: Undertow/1 Set-Cookie: JSESSIONID=sessionid; path=/raildocs; HttpOnly; Max-Age=36000; Expires=Thu, 31-Aug-2017 22:12:24 GMT Set-Cookie: access_token=eyJjdHkiOiJKV1QiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiZGlyIn0..RcxVSV-cJB7rTq6N.JupirTzLtU6KhCmswAiejWvC13pVciJ01br_XRoMvhlXk3j7db3hshhh7eo5OjgOkUgNxyGplE3ohvC8xXCYSUKAfcCeYYe3_9VCY28eLoJ0TgO63uzLwI77kgek2Qd1dVMAWl-y3B9sWt33irlBPaJLUaT2GEG53EQ1hrqyLD8mGHzw5qRZhDrCFCWxJbvHVQvnXn9btkcxFGHBIlfC887UShTR05WywXo31fNJGDJa6R9a0dbe1hr5mp-O30dpTezRrfmrrbK8NILHmcJBEQiYhjUXk6rRk9LIsA.I6oBuk3Gw4h41C0D9hz52A; path=/; Max-Age=36000; Expires=Thu, 31-Aug-2017 22:12:24 GMT Access-Control-Allow-Headers: origin, content-type, accept, authorization Server: WildFly/10 Server: WildFly/10 Content-Disposition: inline; filename=OBE_11_Bodegraven - Woerden_000200804_O.pdf Date: Thu, 31 Aug 2017 12:12:24 GMT Connection: close Access-Control-Allow-Origin: * Vary: Accept Access-Control-Allow-Credentials: true Content-Type: application/pdf Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD Access-Control-Max-Age: 1209600 Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; Does someone has an idea why we see this degrade in performance. What are we doing wrong? Thanks in advance, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell
Trouble with RDP loadbalancing
Hi! I've set up haproxy to load balance two (later more) RDP servers (MS Terminal Services) without any connection broker (later I want to add a second haproxy to make sure all parts keep working even if one part fails). So: 2x backend terminal servers running on port 3389 1x haproxy connfigured for load balancing, listening on port 3389 some clients to connect to haproxy on port 3389 Config is (based on https://www.haproxy.com/doc/aloha/7.0/deployment_guides/microsoft_remote_desktop_services.html): global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemon ssl-server-verify none peers nxmux peer nxmux01 *:3388 frontend ft_rdp mode tcp bind *:3389 name rdp timeout client 1h log global option tcplog tcp-request inspect-delay 2s tcp-request content accept if RDP_COOKIE default_backend bk_rdp backend bk_rdp mode tcp balance leastconn timeout server 1h timeout connect 4s log global option tcplog stick-table type string len 32 size 10k expire 8h peers nxmux stick on rdp_cookie(mstshash) option tcp-check tcp-check connect port 3389 ssl default-server inter 3s rise 2 fall 3 #server nxnode01 10.169.16.105:3389 weight 10 check #server nxnode02 10.169.16.106:3389 weight 10 check server nxnode03 10.169.16.107:3389 weight 10 check server nxnode04 10.169.16.108:3389 weight 10 check I can connect to both clients directly from all clients. If I try to connect to haproxy it fails. Any idea what I missed? # haproxy -vv HA-Proxy version 1.7.9 2017/08/18 Copyright 2000-2017 Willy Tarreau Build options : TARGET = linux2628 CPU = generic CC = gcc CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.7 Running on zlib version : 1.2.7 Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip") Built with OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013 Running on OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built without PCRE support (using libc's regex instead) Built without Lua support Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll. Available filters : [COMP] compression [TRACE] trace [SPOE] spoe -- Thomas
Re: Error on "tcp-check connect port 3389 ssl" in config
You where right! I forgot to install the newly compiled binary, working with the one without ssl support! On Thu, Aug 31, 2017 at 1:28 PM, Cyril Bonté wrote: > Hi Thomas, > >> De: "Thomas Schweikle" >> À: haproxy@formilux.org >> Envoyé: Jeudi 31 Août 2017 12:48:39 >> Objet: Error on "tcp-check connect port 3389 ssl" in config >> >> Hi! >> >> Trying to configure haproxy to act as a connection broker and load >> balancer for RDP (aka Microsoft Terminal Services). >> >> While configuring the backend, I found haproxy choke on >> >> tcp-check connect port 3389 ssl >> >> with message: >> >> [ALERT] 242/124152 (6066) : parsing [/etc/haproxy/haproxy.cfg:33] : >> 'tcp-check connect' expects 'comment', 'port', 'send-proxy' or but >> got >> 'ssl' as argument. >> >> Within the handbook I find (section "tcp-check connect"): >> >> tcp-check connect port 443 ssl >> >> If it chokes on this -- is it a bug? Or anything else? >> >> # haproxy -v >> HA-Proxy version 1.7.9 2017/08/18 >> Copyright 2000-2017 Willy Tarreau > > I guess that you compiled haproxy yourself and forgot to enable the SSL > support. > If you run the following command : > haproxy -vv > it will probably show you that haproxy was compiled without SSL support. > > Cyril Bonté -- Thomas
Re: Error on "tcp-check connect port 3389 ssl" in config
Hi Thomas, > De: "Thomas Schweikle" > À: haproxy@formilux.org > Envoyé: Jeudi 31 Août 2017 12:48:39 > Objet: Error on "tcp-check connect port 3389 ssl" in config > > Hi! > > Trying to configure haproxy to act as a connection broker and load > balancer for RDP (aka Microsoft Terminal Services). > > While configuring the backend, I found haproxy choke on > > tcp-check connect port 3389 ssl > > with message: > > [ALERT] 242/124152 (6066) : parsing [/etc/haproxy/haproxy.cfg:33] : > 'tcp-check connect' expects 'comment', 'port', 'send-proxy' or but > got > 'ssl' as argument. > > Within the handbook I find (section "tcp-check connect"): > > tcp-check connect port 443 ssl > > If it chokes on this -- is it a bug? Or anything else? > > # haproxy -v > HA-Proxy version 1.7.9 2017/08/18 > Copyright 2000-2017 Willy Tarreau I guess that you compiled haproxy yourself and forgot to enable the SSL support. If you run the following command : haproxy -vv it will probably show you that haproxy was compiled without SSL support. Cyril Bonté
Error on "tcp-check connect port 3389 ssl" in config
Hi! Trying to configure haproxy to act as a connection broker and load balancer for RDP (aka Microsoft Terminal Services). While configuring the backend, I found haproxy choke on tcp-check connect port 3389 ssl with message: [ALERT] 242/124152 (6066) : parsing [/etc/haproxy/haproxy.cfg:33] : 'tcp-check connect' expects 'comment', 'port', 'send-proxy' or but got 'ssl' as argument. Within the handbook I find (section "tcp-check connect"): tcp-check connect port 443 ssl If it chokes on this -- is it a bug? Or anything else? # haproxy -v HA-Proxy version 1.7.9 2017/08/18 Copyright 2000-2017 Willy Tarreau backend bk_rdp mode tcp balance leastconn timeout server 1h timeout connect 4s log global option tcplog stick-table type string len 32 size 10k expire 8h peers nxmux stick on rdp_cookie(mstshash) option tcp-check tcp-check connect port 3389 ssl default-server inter 3s rise 2 fall 3 #server nxnode01 10.169.16.105:3389 weight 10 check #server nxnode02 10.169.16.106:3389 weight 10 check server nxnode03 10.169.16.107:3389 weight 10 check server nxnode04 10.169.16.108:3389 weight 10 check -- Thomas
[PATCH] MINOR DOC: Improve CLI info on privilege levels
Hello all, I was experimenting some CLI actions like "disable server" and get error "Permission denied". I did not find easily why in HAProxy doc (I was in a hurry, so did not read well, I admit). This was because of the "level" on the socket bind line not high enough. Attached is a patch to the doc to add a small paragraph explaining that some CLI actions require higher level of privileges. This is very well explained in the configuration manual, but CLI options are explained in the management tutorial, that's why I did not find what I was looking for at first sight. If you have better phrasing, feel free to comment me :) @willy: I hope patch is formatted correctly this time ;) Olivier 0001-MINOR-doc-CLI-info-on-privilege-levels.patch Description: Binary data