Re: HAProxy 1.7.9 very slow with HTTP compression

2017-08-31 Thread Lukas Tribus 
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

2017-08-31 Thread 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.

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

2017-08-31 Thread Thomas Schweikle 
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

2017-08-31 Thread Thomas Schweikle 
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

2017-08-31 Thread Cyril Bonté 
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

2017-08-31 Thread Thomas Schweikle 
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

2017-08-31 Thread Olivier Doucet 
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