Re: Certificate bundles seem to be non-functional

[Michael Ezzell]

On Dec 20, 2017 01:19, "Andrew Heberle"  wrote:

just wanting to know where the failing is...


With me, in this case.  Apologies for the complete misunderstanding of your
question.  I have not used the feature you're referring to and mistakenly
assumed "bundle" was a reference to cert + intermediate + key.

Re: [PATCH] BUG: NetScaler CIP handling is incorrect

[Willy Tarreau]

On Tue, Dec 19, 2017 at 11:10:58PM +, Bertrand Jacquin wrote:
> Hi Andreas and Willy,
> 
> Please find attached a patch serie adding support for both legacy and
> standard CIP protocol while keeping compatibility with current
> configuration format.

Excellent, now applied to 1.9, will backport it to 1.8 later.

Thanks a lot guys, I've seen how many round trips it required to
validate these changes on your respective infrastructures, it was
a very productive cooperation!

Cheers,
Willy

Re: [PATCH] DOC/MINOR: intro: typo, wording, formatting fixes

[Willy Tarreau]

On Tue, Dec 19, 2017 at 06:01:51PM -0500, Davor Ocelic wrote:
> - Fix a couple typos
> - Introduce a couple simple rewordings
> - Eliminate > 80 column lines
> 
> Changes do not affect technical content and can be backported.

Thanks a lot Davor, I've read it all and it's all quite good stuff. We'll
backport this to 1.8 and try to do the same with older releases. Thanks
for taking care of the doc's quality!

Willy

Re: Certificate bundles seem to be non-functional

[Michael Ezzell]

On Dec 19, 2017 20:46, "Andrew Heberle"  wrote:

I am attempting to utilise certificate bundles so we can have multi-type
certs in haproxy however this seems non-functional.

I have a two cert bundles as follows (only testing with RSA certs at the
moment):

/etc/haproxy/ssl # ls -l /etc/haproxy/ssl/
total 16
-rw-r--r-- 1 root root 1184 Dec 20 01:39 test1.pem.issuer.rsa
-rw-r--r-- 1 root root 2888 Dec 20 01:26 test1.pem.rsa
-rw-r--r-- 1 root root 1184 Dec 20 01:40 test2.pem.issuer.rsa
-rw-r--r-- 1 root root 2888 Dec 20 01:30 test2.pem.rsa

With the following config of my two front-ends:

frontend test1
bind *:5000 ssl crt test1.pem
default_backend app1

frontend test2
bind *:5001 ssl crt test2.pem
default_backend app2

But this then fails:

/etc/haproxy/ssl # haproxy -f /etc/haproxy/haproxy.cfg -c
[ALERT] 353/014339 (59) : parsing [/etc/haproxy/haproxy.cfg:34] : 'bind
*:5000' : unable to stat SSL certificate from fi
le '/etc/haproxy/ssl/test1.pem' : No such file or directory.


Refer to the documentation.

There is no implied extension for the specified filename, such as ".rsa".
The "crt" directive expects the exact path to a single file containing the
certificate AND chain AND private key.

crt 


This setting is only available when support for OpenSSL was built in. It
designates a PEM file containing both the required certificates and any
associated private keys. This file can be built by concatenating multiple
PEM files into one (e.g. cat cert.pem key.pem > combined.pem). If your CA
requires an intermediate certificate, this can also be concatenated into this
file.


http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#5.1-crt

Certificate bundles seem to be non-functional

[Andrew Heberle]

I am attempting to utilise certificate bundles so we can have multi-type
certs in haproxy however this seems non-functional.

I have a two cert bundles as follows (only testing with RSA certs at the
moment):

/etc/haproxy/ssl # ls -l /etc/haproxy/ssl/
total 16
-rw-r--r-- 1 root root 1184 Dec 20 01:39 test1.pem.issuer.rsa
-rw-r--r-- 1 root root 2888 Dec 20 01:26 test1.pem.rsa
-rw-r--r-- 1 root root 1184 Dec 20 01:40 test2.pem.issuer.rsa
-rw-r--r-- 1 root root 2888 Dec 20 01:30 test2.pem.rsa

With the following config of my two front-ends:

frontend test1
bind *:5000 ssl crt test1.pem
default_backend app1

frontend test2
bind *:5001 ssl crt test2.pem
default_backend app2

But this then fails:

/etc/haproxy/ssl # haproxy -f /etc/haproxy/haproxy.cfg -c
[ALERT] 353/014339 (59) : parsing [/etc/haproxy/haproxy.cfg:34] : 'bind
*:5000' : unable to stat SSL certificate from fi
le '/etc/haproxy/ssl/test1.pem' : No such file or directory.
[ALERT] 353/014339 (59) : parsing [/etc/haproxy/haproxy.cfg:38] : 'bind
*:5001' : unable to stat SSL certificate from fi
le '/etc/haproxy/ssl/test2.pem' : No such file or directory.
[ALERT] 353/014339 (59) : Error(s) found in configuration file :
/etc/haproxy/haproxy.cfg
[ALERT] 353/014339 (59) : Fatal errors found in configuration.

Build Options:

HA-Proxy version 1.7.9 2017/08/18
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -Os -fomit-frame-pointer
  OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : LibreSSL 2.6.3
Running on OpenSSL version : LibreSSL 2.6.3
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.41 2017-07-05
Running on PCRE version : 8.41 2017-07-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with Lua version : Lua 5.3.4
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

--
Andrew Heberle

Re: [PATCH] BUG: NetScaler CIP handling is incorrect

[Bertrand Jacquin]

Hi Andreas and Willy,

Please find attached a patch serie adding support for both legacy and
standard CIP protocol while keeping compatibility with current
configuration format.

This also fixes numerous bugs spotted during this dev cycle and present
since the first version of the patch.

This serie applies cleanly on v1.9-dev0-76-g789691778fde but also on
v1.8.1-20-gdd8ea125889d while I only tested it on v1.9.

Cheers,
Bertrand

On 11/12/17 15:04, Bertrand Jacquin wrote:
> Hi Andreas,
> 
> I got this really side tracked, my apology. Let me take a look at that
> this evening again. Some corps need to be unburied.
> 
> I'm afraid the patch, as is, will break compatibility with other version
> of the CIP protocol, I'd like haproxy to support both of them.
> 
> Cheers,
> Bertrand
> 
> On 07/12/17 13:41, Andreas Mahnke wrote:
>> Hello everybody,
>>
>> Is there an update regarding the merging of the patch? We are thinking
>> to switch to version 1.8 in the near future and it would be nice to have
>> the patch merged, so that we do not need to merge each update on our own.
>>
>> Best regards,
>> Andreas
>>
>> On Fri, Jul 7, 2017 at 2:43 PM, Willy Tarreau > > wrote:
>>
>> On Fri, Jul 07, 2017 at 02:36:07PM +0200, Andreas Mahnke wrote:
>> > Hi Willy,
>> >
>> > I had some direct mail conversations with him and he wanted to create a
>> > patch based in the findings.
>> > In the meantime we got it working using the patch I provided, 
>> therefore I
>> > sent it yesterday so that it gets integrated and we do not need to 
>> patch
>> > haproxy on our end everytime a new version comes out.
>> >
>> > I wrote him yesterday that the patch was sent by me, but he seems to 
>> be out
>> > of office until monday - so maybe he will get back to us then.
>>
>> Yep I noticed the out-of-office notification as well. Let's wait for
>> him to
>> get back. I'm pretty fine with merging your patch, I just want to be
>> certain
>> that everything is OK on his side as well, especially before
>> backporting it
>> (since it's a bug fix).
>>
>> Thanks!
>> Willy
>>
>>
> 

-- 
Bertrand
Payments Infrastructure Engineering, Amazon
From 3245e08747ed3c72fa429365010450c2ca04caac Mon Sep 17 00:00:00 2001
From: Bertrand Jacquin 
Date: Tue, 12 Dec 2017 01:17:23 +
Subject: [PATCH 8/8] MEDIUM: netscaler: add support for standard NetScaler CIP
 protocol

It looks like two version of the protocol exist as reported by
Andreas Mahnke. This patch add support for both legacy and standard CIP
protocol according to NetScaler specifications.
---
 doc/netscaler-client-ip-insertion-protocol.txt | 28 ++-
 src/connection.c   | 38 --
 2 files changed, 50 insertions(+), 16 deletions(-)

diff --git a/doc/netscaler-client-ip-insertion-protocol.txt b/doc/netscaler-client-ip-insertion-protocol.txt
index 6f77f6522c7f..559d98a82a92 100644
--- a/doc/netscaler-client-ip-insertion-protocol.txt
+++ b/doc/netscaler-client-ip-insertion-protocol.txt
@@ -10,7 +10,9 @@ Specifications and documentations from NetScaler:
   https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/
 
 When CIP is enabled on the NetScaler, then a TCP packet is inserted just after
-the TCP handshake. This is composed as:
+the TCP handshake. Two versions of the CIP extension exist.
+
+Legacy (NetScaler < 10.5)
 
   - CIP magic number : 4 bytes
 Both sender and receiver have to agree on a magic number so that
@@ -27,3 +29,27 @@ the TCP handshake. This is composed as:
   - TCP header : >= 20 bytes
 Contains the header of the last TCP packet sent by the client during TCP
 handshake.
+
+Standard (NetScaler >= 10.5)
+
+  - CIP magic number : 4 bytes
+Both sender and receiver have to agree on a magic number so that
+they both handle the incoming data as a NetScaler Client IP insertion
+packet.
+
+  - CIP length : 4 bytes
+Defines the total length on the CIP header.
+
+  - CIP type: 2 bytes
+Always set to 1.
+
+  - Header length : 2 bytes
+Defines the length on the remaining data.
+
+  - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6
+Contains the header of the last IP packet sent by the client during TCP
+handshake.
+
+  - TCP header : >= 20 bytes
+Contains the header of the last TCP packet sent by the client during TCP
+handshake.
diff --git a/src/connection.c b/src/connection.c
index 58bf4a5f85f5..0f8acb02dbdb 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -678,14 +678,8 @@ int conn_recv_proxy(struct connection *conn, int flag)
 }
 
 /* This handshake handler waits a NetScaler Client IP insertion header
- * at the beginning of the raw data stream. The header looks like this:
- *
- *   4 bytes:   CIP magic number
- *   4 bytes:   Header length
- *   20+ bytes: Header of the last IP packet sent by the client 

[PATCH] DOC/MINOR: intro: typo, wording, formatting fixes

[Davor Ocelic]

- Fix a couple typos
- Introduce a couple simple rewordings
- Eliminate > 80 column lines

Changes do not affect technical content and can be backported.
>From b6a7b7f6948033d54660a9895487766081634663 Mon Sep 17 00:00:00 2001
From: Davor Ocelic 
Date: Tue, 19 Dec 2017 23:30:39 +0100
Subject: [PATCH] DOC/MINOR: intro: typo, wording, formatting fixes

- Fix a couple typos
- Introduce a couple simple rewordings
- Eliminate > 80 column lines

Changes do not affect technical content and can be backported.
---
 doc/intro.txt | 214 +-
 1 file changed, 108 insertions(+), 106 deletions(-)

diff --git a/doc/intro.txt b/doc/intro.txt
index f2a27f1..aff9641 100644
--- a/doc/intro.txt
+++ b/doc/intro.txt
@@ -9,10 +9,10 @@ well as for those who want to re-discover it when they know older versions. Its
 primary focus is to provide users with all the elements to decide if HAProxy is
 the product they're looking for or not. Advanced users may find here some parts
 of solutions to some ideas they had just because they were not aware of a given
-new feature. Some sizing information are also provided, the product's lifecycle
+new feature. Some sizing information is also provided, the product's lifecycle
 is explained, and comparisons with partially overlapping products are provided.
 
-This document doesn't provide any configuration help nor hint, but it explains
+This document doesn't provide any configuration help or hints, but it explains
 where to find the relevant documents. The summary below is meant to help you
 search sections by name and navigate through the document.
 
@@ -45,7 +45,7 @@ Summary
 3.3.9.ACLs and conditions
 3.3.10.   Content switching
 3.3.11.   Stick-tables
-3.3.12.   Formated strings
+3.3.12.   Formatted strings
 3.3.13.   HTTP rewriting and redirection
 3.3.14.   Server protection
 3.3.15.   Logging
@@ -75,12 +75,12 @@ to the mailing list whose responses are present in these documents.
   - intro.txt (this document) : it presents the basics of load balancing,
 HAProxy as a product, what it does, what it doesn't do, some known traps to
 avoid, some OS-specific limitations, how to get it, how it evolves, how to
-ensure you're running with all known fixes, how to update it, complements and
-alternatives.
+ensure you're running with all known fixes, how to update it, complements
+and alternatives.
 
   - management.txt : it explains how to start haproxy, how to manage it at
-runtime, how to manage it on multiple nodes, how to proceed with seamless
-upgrades.
+runtime, how to manage it on multiple nodes, and how to proceed with
+seamless upgrades.
 
   - configuration.txt : the reference manual details all configuration keywords
 and their options. It is used when a configuration change is needed.
@@ -89,15 +89,15 @@ to the mailing list whose responses are present in these documents.
 load-balanced infrastructure and how to interact with third party products.
 
   - coding-style.txt : this is for developers who want to propose some code to
-the project. It explains the style to adopt for the code. It's not very
-strict and not all the code base completely respects it but contributions
+the project. It explains the style to adopt for the code. It is not very
+strict and not all the code base completely respects it, but contributions
 which diverge too much from it will be rejected.
 
   - proxy-protocol.txt : this is the de-facto specification of the PROXY
 protocol which is implemented by HAProxy and a number of third party
 products.
 
-  - README : how to build haproxy from sources
+  - README : how to build HAProxy from sources
 
 
 2. Quick introduction to load balancing and load balancers
@@ -118,8 +118,8 @@ without increasing their individual speed.
 Examples of load balancing :
 
   - Process scheduling in multi-processor systems
-  - Link load balancing (eg: EtherChannel, Bonding)
-  - IP address load balancing (eg: ECMP, DNS roundrobin)
+  - Link load balancing (e.g. EtherChannel, Bonding)
+  - IP address load balancing (e.g. ECMP, DNS round-robin)
   - Server load balancing (via load balancers)
 
 The mechanism or component which performs the load balancing operation is
@@ -147,9 +147,9 @@ all routing decisions.
 The first one acts at the packet level and processes packets more or less
 individually. There is a 1-to-1 relation between input and output packets, so
 it is possible to follow the traffic on both sides of the load balancer using a
-regular network sniffer.  This technology can be very cheap and extremely fast.
+regular network sniffer. This technology can be very cheap and extremely fast.
 It is usually implemented in hardware (ASICs) allowing to reach line rate, such
-as switches doing ECMP.  Usually stateless, it can also be stateful (consider
+as switches doing ECMP. Usually stateless, it can 

回复：Haproxy SSl Termination performance issue

[hongw...@163.com]

Hi, Thierry.Thanks again.One more question about you talking about, can i just think like this way: assume we got a 8core cpu, we use 7 of them for ssl termination and one is for http forward?  If it is, is there any document for this soulution?Thanks a lotMike 原始邮件 主题：Re: Haproxy SSl Termination performance issue发件人：Thierry Fournier 收件人：Mike G 抄送：Haproxy Ok, you’re using HAProxy as SSL offloading. HAProxy is one of theright solutions for doing this. You’re performance problem is notdue to HAProxy, each component using OpenSSL will reach the samelimits.Classic setup is to configure many process for the SSL offloading(proxy in TCP mode), and only one for the HTTP. This setup worksfine because it allow many CPU for the SSL which require computing,and the HTTP processing is done by only one process which canperform accounting and apply limits (rate limit, connexion limit,...). Thierry> On 19 Dec 2017, at 12:44, Mike G  wrote:> > > > Hi, Thierry.> > our case is like this: we put a haproxy as ssl termination.  and haproxy got the https requirement. and then go throught SSL ternimation. and then forward > the request to web (by HTTP), also, get the Http request and encrypt it, and return HTTPS to client.> > > thanks> > Mike> > > > > > At 2017-12-19 19:25:09, "Thierry Fournier"  wrote:> >Hi,> >> >What kind of job ?> >> >Thierry> >> >> On 19 Dec 2017, at 12:17, hongw...@163.com wrote:> >> > >> Hi，Thierry> >> > >> got it. Thanks！> >> > >> By the way, may I ask the ssl termination is best solution for this kind of job?> >> > >> > >> Many thanks> >> > >> Mike> >> > >> > >> > >>  原始邮件 > >> 主题：Re: Haproxy SSl Termination performance issue> >> 发件人：Thierry Fournier > >> 收件人：Mike G > >> 抄送：Haproxy > >> > >> > >> Hi,> >> > >> I gues that 130 is 130 SSL requests per seconds ?> >> > >> SSL is a very heavy processing. The 4096 bits certificates consume more> >> CPU that 2048 (thanks captain obvious). Your capacity processing is> >> capped by your CPU. You must check the CPU of your server during your> >> test. If the CPU consummation is 100%, you reach the limit of your server.> >> > >> If you reach the limit of one CPU (nbproc), you can use more CPU and/or more> >> servers.> >> > >> Thierry> >> > >> > >> > On 19 Dec 2017, at 08:36, Mike G wrote:> >> > > >> > Hi, everyone. > >> > > >> > I just got a problem about the haproxy ssl termination performance issues. > >> > we have a case which want to use SSL Termination. so, we did some testing before online, I know the virtual machine will not good choice, but it make feel so supriose the cur link can be more than 130 when I use 4096 key.> >> > here's my configuration about the haproxy:> >> > > >> > haproxy as SSL termination layer before web server.  > >> > the haproxy version is 1.8.1> >> > I compile it by myself:> >> > use the parameter:> >> > make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1> >> > > >> > also, I use download openssl 1.0.2n from openssl.org, and compile by those parameters:> >> > ./config -d zlib> >> > > >> > after install openssl and haproxy.> >> > here's my configuration about the haproxy:> >> > global> >> > log 127.0.0.1 local0> >> > > >> > chroot /var/lib/haproxy> >> > pidfile /var/run/haproxy.pid> >> > maxconn 65535> >> > group haproxy> >> > user haproxy> >> > daemon> >> > nbproc 1> >> > > >> > stats socket /var/lib/haproxy/stats> >> > tune.ssl.default-dh-param 2048> >> > > >> > defaults> >> > mode http> >> > log global> >> > option redispatch> >> > option abortonclose> >> > log 127.0.0.1 local0> >> > retries 3> >> > maxconn 65535> >> > timeout connect 10s> >> > timeout client 1m> >> > timeout queue 1m> >> > timeout http-request 30s> >> > timeout server 1m> >> > timeout check 5s> >> > > >> > listen admin_stats> >> > bind 0.0.0.0:20123> >> > maxconn 10> >> > stats refresh 10s> >> > stats uri /web/status> >> > stats auth admin:1> >> > stats hide-version> >> > > >> > > >> > frontend localhost> >> > bind *:80> >> > bind *:443 ssl crt /etc/ssl/web-zhengshu.pem> >> > option httpclose> >> > mode http> >> > default_backend nodes> >> > > >> > backend nodes> >> > mode http> >> > balance roundrobin> >> > option forwardfor> >> > option httpchk GET /check.html> >> > server web01 127.0.0.1:8080 check> >> > http-request set-header X-Forwarded-Port %[dst_port]> >> > http-request add-header X-Forwarded-Proto https if { ssl_fc }> >> > > >> > > >> > note: about the option httpclose, I make it for purpose.> >> > > >> > also, I use vegeta for test.> >> > here's the testing command line:> >> > echo "GET https://10.77.77.215/check.html" | ./vegeta.vegeta -cpus=8 attack -duration=90s -rate=800 -insecure | tee reports.bin | ./vegeta.vegeta report> >> > > >> > I found the cpu is get more than 90% usage very soon. but the haproxy status picture like in attachment.> >> > > >> > the max links is less than 130 around.> >> > > 

haproxy and solarflare onload

[Elias Abacioglu]

Hi,

I recently bought a solarflare NIC with (ScaleOut) Onload / OpenOnload to
test it with HAproxy.

Have anyone tried running haproxy with solarflare onload functions?

After I started haproxy with onload, this started spamming on the kernel
log:
Dec 12 14:11:54 dflb06 kernel: [357643.035355] [onload]
oof_socket_add_full_hw: 6:3083 ERROR: FILTER TCP 10.3.54.43:4147
10.3.20.116:80 failed (-16)
Dec 12 14:11:54 dflb06 kernel: [357643.064395] [onload]
oof_socket_add_full_hw: 6:3491 ERROR: FILTER TCP 10.3.54.43:39321
10.3.20.113:80 failed (-16)
Dec 12 14:11:54 dflb06 kernel: [357643.081069] [onload]
oof_socket_add_full_hw: 3:2124 ERROR: FILTER TCP 10.3.54.43:62403
10.3.20.30:445 failed (-16)
Dec 12 14:11:54 dflb06 kernel: [357643.082625] [onload]
oof_socket_add_full_hw: 3:2124 ERROR: FILTER TCP 10.3.54.43:62403
10.3.20.30:445 failed (-16)

And this in haproxy log:
Dec 12 14:12:07 dflb06 haproxy[21145]: Proxy ssl-relay reached system
memory limit at 9931 sockets. Please check system tunables.
Dec 12 14:12:07 dflb06 haproxy[21146]: Proxy ssl-relay reached system
memory limit at 9184 sockets. Please check system tunables.
Dec 12 14:12:07 dflb06 haproxy[21145]: Proxy HTTP reached system memory
limit at 9931 sockets. Please check system tunables.
Dec 12 14:12:07 dflb06 haproxy[21145]: Proxy HTTP reached system memory
limit at 9931 sockets. Please check system tunables.


Apparently I've hit the max hardware filter limit on the  card.
Does anyone here have experience in running haproxy with onload features?
Mind sharing insights and advice on how to get a functional setup?


Thanks,
Elias

回复：Haproxy SSl Termination performance issue

[hongw...@163.com]

Hi，ThierryMany thanksMike发自我的华为手机 原始邮件 主题：Re: Haproxy SSl Termination performance issue发件人：Thierry Fournier 收件人：Mike G 抄送：Haproxy Ok, you’re using HAProxy as SSL offloading. HAProxy is one of theright solutions for doing this. You’re performance problem is notdue to HAProxy, each component using OpenSSL will reach the samelimits.Classic setup is to configure many process for the SSL offloading(proxy in TCP mode), and only one for the HTTP. This setup worksfine because it allow many CPU for the SSL which require computing,and the HTTP processing is done by only one process which canperform accounting and apply limits (rate limit, connexion limit,...). Thierry> On 19 Dec 2017, at 12:44, Mike G  wrote:> > > > Hi, Thierry.> > our case is like this: we put a haproxy as ssl termination.  and haproxy got the https requirement. and then go throught SSL ternimation. and then forward > the request to web (by HTTP), also, get the Http request and encrypt it, and return HTTPS to client.> > > thanks> > Mike> > > > > > At 2017-12-19 19:25:09, "Thierry Fournier"  wrote:> >Hi,> >> >What kind of job ?> >> >Thierry> >> >> On 19 Dec 2017, at 12:17, hongw...@163.com wrote:> >> > >> Hi，Thierry> >> > >> got it. Thanks！> >> > >> By the way, may I ask the ssl termination is best solution for this kind of job?> >> > >> > >> Many thanks> >> > >> Mike> >> > >> > >> > >>  原始邮件 > >> 主题：Re: Haproxy SSl Termination performance issue> >> 发件人：Thierry Fournier > >> 收件人：Mike G > >> 抄送：Haproxy > >> > >> > >> Hi,> >> > >> I gues that 130 is 130 SSL requests per seconds ?> >> > >> SSL is a very heavy processing. The 4096 bits certificates consume more> >> CPU that 2048 (thanks captain obvious). Your capacity processing is> >> capped by your CPU. You must check the CPU of your server during your> >> test. If the CPU consummation is 100%, you reach the limit of your server.> >> > >> If you reach the limit of one CPU (nbproc), you can use more CPU and/or more> >> servers.> >> > >> Thierry> >> > >> > >> > On 19 Dec 2017, at 08:36, Mike G wrote:> >> > > >> > Hi, everyone. > >> > > >> > I just got a problem about the haproxy ssl termination performance issues. > >> > we have a case which want to use SSL Termination. so, we did some testing before online, I know the virtual machine will not good choice, but it make feel so supriose the cur link can be more than 130 when I use 4096 key.> >> > here's my configuration about the haproxy:> >> > > >> > haproxy as SSL termination layer before web server.  > >> > the haproxy version is 1.8.1> >> > I compile it by myself:> >> > use the parameter:> >> > make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1> >> > > >> > also, I use download openssl 1.0.2n from openssl.org, and compile by those parameters:> >> > ./config -d zlib> >> > > >> > after install openssl and haproxy.> >> > here's my configuration about the haproxy:> >> > global> >> > log 127.0.0.1 local0> >> > > >> > chroot /var/lib/haproxy> >> > pidfile /var/run/haproxy.pid> >> > maxconn 65535> >> > group haproxy> >> > user haproxy> >> > daemon> >> > nbproc 1> >> > > >> > stats socket /var/lib/haproxy/stats> >> > tune.ssl.default-dh-param 2048> >> > > >> > defaults> >> > mode http> >> > log global> >> > option redispatch> >> > option abortonclose> >> > log 127.0.0.1 local0> >> > retries 3> >> > maxconn 65535> >> > timeout connect 10s> >> > timeout client 1m> >> > timeout queue 1m> >> > timeout http-request 30s> >> > timeout server 1m> >> > timeout check 5s> >> > > >> > listen admin_stats> >> > bind 0.0.0.0:20123> >> > maxconn 10> >> > stats refresh 10s> >> > stats uri /web/status> >> > stats auth admin:1> >> > stats hide-version> >> > > >> > > >> > frontend localhost> >> > bind *:80> >> > bind *:443 ssl crt /etc/ssl/web-zhengshu.pem> >> > option httpclose> >> > mode http> >> > default_backend nodes> >> > > >> > backend nodes> >> > mode http> >> > balance roundrobin> >> > option forwardfor> >> > option httpchk GET /check.html> >> > server web01 127.0.0.1:8080 check> >> > http-request set-header X-Forwarded-Port %[dst_port]> >> > http-request add-header X-Forwarded-Proto https if { ssl_fc }> >> > > >> > > >> > note: about the option httpclose, I make it for purpose.> >> > > >> > also, I use vegeta for test.> >> > here's the testing command line:> >> > echo "GET https://10.77.77.215/check.html" | ./vegeta.vegeta -cpus=8 attack -duration=90s -rate=800 -insecure | tee reports.bin | ./vegeta.vegeta report> >> > > >> > I found the cpu is get more than 90% usage very soon. but the haproxy status picture like in attachment.> >> > > >> > the max links is less than 130 around.> >> > > >> > but when I changed the ssl certication file back to 2048, it will be increase to around 800.> >> > > >> > is there anyone can help me about how to improve the haproxy ssl termination performance?> >> > > >> > > >> > Many 

Re:Re: Haproxy SSl Termination performance issue

[Mike G]

Hi, Thierry.


our case is like this: we put a haproxy as ssl termination.  and haproxy got 
the https requirement. and then go throught SSL ternimation. and then forward 
the request to web (by HTTP), also, get the Http request and encrypt it, and 
return HTTPS to client.




thanks


Mike








At 2017-12-19 19:25:09, "Thierry Fournier"  
wrote:
>Hi,
>
>What kind of job ?
>
>Thierry
>
>> On 19 Dec 2017, at 12:17, hongw...@163.com wrote:
>> 
>> Hi，Thierry
>> 
>> got it. Thanks！
>> 
>> By the way, may I ask the ssl termination is best solution for this kind of 
>> job?
>> 
>> 
>> Many thanks
>> 
>> Mike
>> 
>> 
>> 
>>  原始邮件 
>> 主题：Re: Haproxy SSl Termination performance issue
>> 发件人：Thierry Fournier 
>> 收件人：Mike G 
>> 抄送：Haproxy 
>> 
>> 
>> Hi,
>> 
>> I gues that 130 is 130 SSL requests per seconds ?
>> 
>> SSL is a very heavy processing. The 4096 bits certificates consume more
>> CPU that 2048 (thanks captain obvious). Your capacity processing is
>> capped by your CPU. You must check the CPU of your server during your
>> test. If the CPU consummation is 100%, you reach the limit of your server.
>> 
>> If you reach the limit of one CPU (nbproc), you can use more CPU and/or more
>> servers.
>> 
>> Thierry
>> 
>> 
>> > On 19 Dec 2017, at 08:36, Mike G wrote:
>> > 
>> > Hi, everyone. 
>> > 
>> > I just got a problem about the haproxy ssl termination performance issues. 
>> > we have a case which want to use SSL Termination. so, we did some testing 
>> > before online, I know the virtual machine will not good choice, but it 
>> > make feel so supriose the cur link can be more than 130 when I use 4096 
>> > key.
>> > here's my configuration about the haproxy:
>> > 
>> > haproxy as SSL termination layer before web server.  
>> > the haproxy version is 1.8.1
>> > I compile it by myself:
>> > use the parameter:
>> > make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
>> > 
>> > also, I use download openssl 1.0.2n from openssl.org, and compile by those 
>> > parameters:
>> > ./config -d zlib
>> > 
>> > after install openssl and haproxy.
>> > here's my configuration about the haproxy:
>> > global
>> > log 127.0.0.1 local0
>> > 
>> > chroot /var/lib/haproxy
>> > pidfile /var/run/haproxy.pid
>> > maxconn 65535
>> > group haproxy
>> > user haproxy
>> > daemon
>> > nbproc 1
>> > 
>> > stats socket /var/lib/haproxy/stats
>> > tune.ssl.default-dh-param 2048
>> > 
>> > defaults
>> > mode http
>> > log global
>> > option redispatch
>> > option abortonclose
>> > log 127.0.0.1 local0
>> > retries 3
>> > maxconn 65535
>> > timeout connect 10s
>> > timeout client 1m
>> > timeout queue 1m
>> > timeout http-request 30s
>> > timeout server 1m
>> > timeout check 5s
>> > 
>> > listen admin_stats
>> > bind 0.0.0.0:20123
>> > maxconn 10
>> > stats refresh 10s
>> > stats uri /web/status
>> > stats auth admin:1
>> > stats hide-version
>> > 
>> > 
>> > frontend localhost
>> > bind *:80
>> > bind *:443 ssl crt /etc/ssl/web-zhengshu.pem
>> > option httpclose
>> > mode http
>> > default_backend nodes
>> > 
>> > backend nodes
>> > mode http
>> > balance roundrobin
>> > option forwardfor
>> > option httpchk GET /check.html
>> > server web01 127.0.0.1:8080 check
>> > http-request set-header X-Forwarded-Port %[dst_port]
>> > http-request add-header X-Forwarded-Proto https if { ssl_fc }
>> > 
>> > 
>> > note: about the option httpclose, I make it for purpose.
>> > 
>> > also, I use vegeta for test.
>> > here's the testing command line:
>> > echo "GET https://10.77.77.215/check.html; | ./vegeta.vegeta -cpus=8 
>> > attack -duration=90s -rate=800 -insecure | tee reports.bin | 
>> > ./vegeta.vegeta report
>> > 
>> > I found the cpu is get more than 90% usage very soon. but the haproxy 
>> > status picture like in attachment.
>> > 
>> > the max links is less than 130 around.
>> > 
>> > but when I changed the ssl certication file back to 2048, it will be 
>> > increase to around 800.
>> > 
>> > is there anyone can help me about how to improve the haproxy ssl 
>> > termination performance?
>> > 
>> > 
>> > Many thanks
>> > 
>> > 
>> > Mike
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> >  
>> > 

Re: Haproxy SSl Termination performance issue

[Thierry Fournier]

Hi,

What kind of job ?

Thierry

> On 19 Dec 2017, at 12:17, hongw...@163.com wrote:
> 
> Hi，Thierry
> 
> got it. Thanks！
> 
> By the way, may I ask the ssl termination is best solution for this kind of 
> job?
> 
> 
> Many thanks
> 
> Mike
> 
> 
> 
>  原始邮件 
> 主题：Re: Haproxy SSl Termination performance issue
> 发件人：Thierry Fournier 
> 收件人：Mike G 
> 抄送：Haproxy 
> 
> 
> Hi,
> 
> I gues that 130 is 130 SSL requests per seconds ?
> 
> SSL is a very heavy processing. The 4096 bits certificates consume more
> CPU that 2048 (thanks captain obvious). Your capacity processing is
> capped by your CPU. You must check the CPU of your server during your
> test. If the CPU consummation is 100%, you reach the limit of your server.
> 
> If you reach the limit of one CPU (nbproc), you can use more CPU and/or more
> servers.
> 
> Thierry
> 
> 
> > On 19 Dec 2017, at 08:36, Mike G wrote:
> > 
> > Hi, everyone. 
> > 
> > I just got a problem about the haproxy ssl termination performance issues. 
> > we have a case which want to use SSL Termination. so, we did some testing 
> > before online, I know the virtual machine will not good choice, but it make 
> > feel so supriose the cur link can be more than 130 when I use 4096 key.
> > here's my configuration about the haproxy:
> > 
> > haproxy as SSL termination layer before web server.  
> > the haproxy version is 1.8.1
> > I compile it by myself:
> > use the parameter:
> > make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
> > 
> > also, I use download openssl 1.0.2n from openssl.org, and compile by those 
> > parameters:
> > ./config -d zlib
> > 
> > after install openssl and haproxy.
> > here's my configuration about the haproxy:
> > global
> > log 127.0.0.1 local0
> > 
> > chroot /var/lib/haproxy
> > pidfile /var/run/haproxy.pid
> > maxconn 65535
> > group haproxy
> > user haproxy
> > daemon
> > nbproc 1
> > 
> > stats socket /var/lib/haproxy/stats
> > tune.ssl.default-dh-param 2048
> > 
> > defaults
> > mode http
> > log global
> > option redispatch
> > option abortonclose
> > log 127.0.0.1 local0
> > retries 3
> > maxconn 65535
> > timeout connect 10s
> > timeout client 1m
> > timeout queue 1m
> > timeout http-request 30s
> > timeout server 1m
> > timeout check 5s
> > 
> > listen admin_stats
> > bind 0.0.0.0:20123
> > maxconn 10
> > stats refresh 10s
> > stats uri /web/status
> > stats auth admin:1
> > stats hide-version
> > 
> > 
> > frontend localhost
> > bind *:80
> > bind *:443 ssl crt /etc/ssl/web-zhengshu.pem
> > option httpclose
> > mode http
> > default_backend nodes
> > 
> > backend nodes
> > mode http
> > balance roundrobin
> > option forwardfor
> > option httpchk GET /check.html
> > server web01 127.0.0.1:8080 check
> > http-request set-header X-Forwarded-Port %[dst_port]
> > http-request add-header X-Forwarded-Proto https if { ssl_fc }
> > 
> > 
> > note: about the option httpclose, I make it for purpose.
> > 
> > also, I use vegeta for test.
> > here's the testing command line:
> > echo "GET https://10.77.77.215/check.html; | ./vegeta.vegeta -cpus=8 attack 
> > -duration=90s -rate=800 -insecure | tee reports.bin | ./vegeta.vegeta report
> > 
> > I found the cpu is get more than 90% usage very soon. but the haproxy 
> > status picture like in attachment.
> > 
> > the max links is less than 130 around.
> > 
> > but when I changed the ssl certication file back to 2048, it will be 
> > increase to around 800.
> > 
> > is there anyone can help me about how to improve the haproxy ssl 
> > termination performance?
> > 
> > 
> > Many thanks
> > 
> > 
> > Mike
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > 

Stats with nproc > 1 and Haproxy 1.8

[Ricardo Fraile]

Hi Haproxy Team,


If I'm not wrong, with the previous versions, the stats was separated in
each process if the nproc > 1 was used. But what is the state now in 1.8
if the "master-worker" configuration is used?

In the following configuration snippet, the socket is bounded to process
1, but have it the information of all of the child threads?


global
master-worker
stats socket /var/run/haproxy.sock level admin expose-fd
listeners process 1
nbproc 8

listen proxy-stats
bind 192.168.1.1:80 process 1
mode http
stats enable
stats uri /stats


Thanks,

回复：Haproxy SSl Termination performance issue

[hongw...@163.com]

Hi，Thierrygot it. Thanks！By the way, may I ask the ssl termination is best solution for this kind of job?Many thanksMike 原始邮件 主题：Re: Haproxy SSl Termination performance issue发件人：Thierry Fournier 收件人：Mike G 抄送：Haproxy Hi,I gues that 130 is 130 SSL requests per seconds ?SSL is a very heavy processing. The 4096 bits certificates consume moreCPU that 2048 (thanks captain obvious). Your capacity processing iscapped by your CPU. You must check the CPU of your server during yourtest. If the CPU consummation is 100%, you reach the limit of your server.If you reach the limit of one CPU (nbproc), you can use more CPU and/or moreservers.Thierry> On 19 Dec 2017, at 08:36, Mike G  wrote:> > Hi, everyone. > > I just got a problem about the haproxy ssl termination performance issues. > we have a case which want to use SSL Termination. so, we did some testing before online, I know the virtual machine will not good choice, but it make feel so supriose the cur link can be more than 130 when I use 4096 key.> here's my configuration about the haproxy:> > haproxy as SSL termination layer before web server.  > the haproxy version is 1.8.1> I compile it by myself:> use the parameter:>  make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1> > also,  I use download openssl 1.0.2n from openssl.org, and compile by those parameters:> ./config -d zlib> > after install openssl and haproxy.> here's my configuration about the haproxy:> global> log 127.0.0.1   local0> > chroot  /var/lib/haproxy> pidfile /var/run/haproxy.pid> maxconn 65535> group haproxy> user haproxy> daemon> nbproc 1> > stats socket /var/lib/haproxy/stats> tune.ssl.default-dh-param 2048> > defaults> modehttp> log global> option  redispatch> option  abortonclose> log 127.0.0.1 local0> retries 3> maxconn 65535> timeout connect 10s> timeout client  1m> timeout queue   1m> timeout http-request30s> timeout server  1m> timeout check   5s> > listen  admin_stats> bind 0.0.0.0:20123> maxconn 10> stats refresh 10s> stats uri /web/status> stats auth admin:1> stats hide-version> > > frontend localhost> bind *:80> bind *:443 ssl crt /etc/ssl/web-zhengshu.pem> option httpclose> mode http> default_backend nodes> > backend nodes> mode http> balance roundrobin> option forwardfor> option httpchk GET /check.html> server web01 127.0.0.1:8080 check> http-request set-header X-Forwarded-Port %[dst_port]> http-request add-header X-Forwarded-Proto https if { ssl_fc }> > > note: about the option httpclose,  I make it for purpose.> > also, I use vegeta for test.> here's the testing command line:> echo "GET https://10.77.77.215/check.html" | ./vegeta.vegeta -cpus=8 attack -duration=90s -rate=800 -insecure | tee reports.bin | ./vegeta.vegeta report> > I found the cpu is get more than 90% usage very soon. but the haproxy status picture like in attachment.> > the max links is less than 130 around.> > but when I changed the ssl certication file back to 2048, it will be increase to around 800.> > is there anyone can help me about how to improve the haproxy ssl termination performance?> > > Many thanks> > > Mike> > > > > > > > > > > >  > 

1.8.1 Segfault + slowdown

[Peter Lindegaard Hansen]

Hi list,

We upgraded from 1.5 to 1.8 recently - then to 1.8.1

Now we're seeing segfaults and slowdowns with haproxy

Repeating:
Dec 19 11:14:26 haproxy02 kernel: [122635.295196] haproxy[29582]: segfault
at 55d5152279b2 ip 7f9c2dcc5a28 sp 7fff07caf4b8 error 6 in
libc-2.23.so[7f9c2dc26000+1c]
Dec 19 11:14:26 haproxy02 systemd[1]: haproxy.service: Main process exited,
code=exited, status=139/n/a
Dec 19 11:14:26 haproxy02 systemd[1]: haproxy.service: Unit entered failed
state.
Dec 19 11:14:26 haproxy02 systemd[1]: haproxy.service: Failed with result
'exit-code'.
Dec 19 11:14:26 haproxy02 systemd[1]: haproxy.service: Service hold-off
time over, scheduling restart.
Dec 19 11:14:26 haproxy02 systemd[1]: Stopped HAProxy Load Balancer.
Dec 19 11:14:26 haproxy02 systemd[1]: Starting HAProxy Load Balancer...
Dec 19 11:14:26 haproxy02 systemd[1]: Started HAProxy Load Balancer.
Dec 19 11:14:27 haproxy02 kernel: [122636.578738] haproxy[31479]: segfault
at 56409a8c1de2 ip 7fa5fa349a28 sp 7ffe66f4f688 error 6 in
libc-2.23.so[7fa5fa2aa000+1c]
Dec 19 11:14:27 haproxy02 systemd[1]: haproxy.service: Main process exited,
code=exited, status=139/n/a
Dec 19 11:14:27 haproxy02 systemd[1]: haproxy.service: Unit entered failed
state.
Dec 19 11:14:27 haproxy02 systemd[1]: haproxy.service: Failed with result
'exit-code'.
Dec 19 11:14:27 haproxy02 systemd[1]: haproxy.service: Service hold-off
time over, scheduling restart.
Dec 19 11:14:27 haproxy02 systemd[1]: Stopped HAProxy Load Balancer.
Dec 19 11:14:27 haproxy02 systemd[1]: Starting HAProxy Load Balancer...
Dec 19 11:14:28 haproxy02 systemd[1]: Started HAProxy Load Balancer.
Dec 19 11:14:28 haproxy02 kernel: [122637.569863] haproxy[31487]: segfault
at 55cb4bd59857 ip 7f71e678aa28 sp 7fffb94427b8 error 6 in
libc-2.23.so[7f71e66eb000+1c]
Dec 19 11:14:28 haproxy02 systemd[1]: haproxy.service: Main process exited,
code=exited, status=139/n/a
Dec 19 11:14:28 haproxy02 systemd[1]: haproxy.service: Unit entered failed
state.
Dec 19 11:14:28 haproxy02 systemd[1]: haproxy.service: Failed with result
'exit-code'.
Dec 19 11:14:28 haproxy02 systemd[1]: haproxy.service: Service hold-off
time over, scheduling restart.
Dec 19 11:14:28 haproxy02 systemd[1]: Stopped HAProxy Load Balancer.
Dec 19 11:14:28 haproxy02 systemd[1]: Starting HAProxy Load Balancer...
Dec 19 11:14:29 haproxy02 systemd[1]: Started HAProxy Load Balancer.


At same time in haproxy.log

(lots of ssl handshake failures...) then
Dec 19 11:14:26 haproxy02 haproxy[29579]: [ALERT] 352/090058 (29579) :
Current worker 29582 left with exit code 139
Dec 19 11:14:26 haproxy02 haproxy[29579]: [ALERT] 352/090058 (29579) :
exit-on-failure: killing every workers with SIGTERM
Dec 19 11:14:26 haproxy02 haproxy[29579]: [WARNING] 352/090058 (29579) :
All workers are left. Leaving... (139)
Dec 19 11:14:27 haproxy02 haproxy[31476]: [ALERT] 352/111426 (31476) :
Current worker 31479 left with exit code 139
Dec 19 11:14:27 haproxy02 haproxy[31476]: [ALERT] 352/111426 (31476) :
exit-on-failure: killing every workers with SIGTERM
Dec 19 11:14:27 haproxy02 haproxy[31476]: [WARNING] 352/111426 (31476) :
All workers are left. Leaving... (139)
Dec 19 11:14:28 haproxy02 haproxy[31485]: [ALERT] 352/111428 (31485) :
Current worker 31487 left with exit code 139
Dec 19 11:14:28 haproxy02 haproxy[31485]: [ALERT] 352/111428 (31485) :
exit-on-failure: killing every workers with SIGTERM
Dec 19 11:14:28 haproxy02 haproxy[31485]: [WARNING] 352/111428 (31485) :
All workers are left. Leaving... (139)
Dec 19 11:14:29 haproxy02 haproxy[31493]: [ALERT] 352/111429 (31493) :
Current worker 31496 left with exit code 139
Dec 19 11:14:29 haproxy02 haproxy[31493]: [ALERT] 352/111429 (31493) :
exit-on-failure: killing every workers with SIGTERM
Dec 19 11:14:29 haproxy02 haproxy[31493]: [WARNING] 352/111429 (31493) :
All workers are left. Leaving... (139)
Dec 19 11:14:30 haproxy02 haproxy[31503]: [ALERT] 352/111429 (31503) :
Current worker 31505 left with exit code 139
Dec 19 11:14:30 haproxy02 haproxy[31503]: [ALERT] 352/111429 (31503) :
exit-on-failure: killing every workers with SIGTERM
Dec 19 11:14:30 haproxy02 haproxy[31503]: [WARNING] 352/111429 (31503) :
All workers are left. Leaving... (139)
Dec 19 11:14:30 haproxy02 haproxy[31511]: [ALERT] 352/111430 (31511) :
Current worker 31515 left with exit code 139
Dec 19 11:14:30 haproxy02 haproxy[31511]: [ALERT] 352/111430 (31511) :
exit-on-failure: killing every workers with SIGTERM
Dec 19 11:14:30 haproxy02 haproxy[31511]: [WARNING] 352/111430 (31511) :
All workers are left. Leaving... (139)



Until haproxy does not respond to requests :-(


I dont know if it is related, but we do see huge slowdows running 1.8 (with
h2 enabled)

After say 10-20 hours haproxy will degrade to serving requests at
4-500kb/s.. when we do a restart of the haproxy service, it will go back to
regular full-line speeds.

We're running ubuntu servers and using Vincent Bernat's PPA.

I can post conf if needed.

Any 

Re: Haproxy SSl Termination performance issue

[Thierry Fournier]

Hi,

I gues that 130 is 130 SSL requests per seconds ?

SSL is a very heavy processing. The 4096 bits certificates consume more
CPU that 2048 (thanks captain obvious). Your capacity processing is
capped by your CPU. You must check the CPU of your server during your
test. If the CPU consummation is 100%, you reach the limit of your server.

If you reach the limit of one CPU (nbproc), you can use more CPU and/or more
servers.

Thierry


> On 19 Dec 2017, at 08:36, Mike G  wrote:
> 
> Hi, everyone. 
> 
> I just got a problem about the haproxy ssl termination performance issues. 
> we have a case which want to use SSL Termination. so, we did some testing 
> before online, I know the virtual machine will not good choice, but it make 
> feel so supriose the cur link can be more than 130 when I use 4096 key.
> here's my configuration about the haproxy:
> 
> haproxy as SSL termination layer before web server.  
> the haproxy version is 1.8.1
> I compile it by myself:
> use the parameter:
>  make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
> 
> also,  I use download openssl 1.0.2n from openssl.org, and compile by those 
> parameters:
> ./config -d zlib
> 
> after install openssl and haproxy.
> here's my configuration about the haproxy:
> global
> log 127.0.0.1   local0
> 
> chroot  /var/lib/haproxy
> pidfile /var/run/haproxy.pid
> maxconn 65535
> group haproxy
> user haproxy
> daemon
> nbproc 1
> 
> stats socket /var/lib/haproxy/stats
> tune.ssl.default-dh-param 2048
> 
> defaults
> modehttp
> log global
> option  redispatch
> option  abortonclose
> log 127.0.0.1 local0
> retries 3
> maxconn 65535
> timeout connect 10s
> timeout client  1m
> timeout queue   1m
> timeout http-request30s
> timeout server  1m
> timeout check   5s
> 
> listen  admin_stats
> bind 0.0.0.0:20123
> maxconn 10
> stats refresh 10s
> stats uri /web/status
> stats auth admin:1
> stats hide-version
> 
> 
> frontend localhost
> bind *:80
> bind *:443 ssl crt /etc/ssl/web-zhengshu.pem
> option httpclose
> mode http
> default_backend nodes
> 
> backend nodes
> mode http
> balance roundrobin
> option forwardfor
> option httpchk GET /check.html
> server web01 127.0.0.1:8080 check
> http-request set-header X-Forwarded-Port %[dst_port]
> http-request add-header X-Forwarded-Proto https if { ssl_fc }
> 
> 
> note: about the option httpclose,  I make it for purpose.
> 
> also, I use vegeta for test.
> here's the testing command line:
> echo "GET https://10.77.77.215/check.html; | ./vegeta.vegeta -cpus=8 attack 
> -duration=90s -rate=800 -insecure | tee reports.bin | ./vegeta.vegeta report
> 
> I found the cpu is get more than 90% usage very soon. but the haproxy status 
> picture like in attachment.
> 
> the max links is less than 130 around.
> 
> but when I changed the ssl certication file back to 2048, it will be increase 
> to around 800.
> 
> is there anyone can help me about how to improve the haproxy ssl termination 
> performance?
> 
> 
> Many thanks
> 
> 
> Mike
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 

Re: 1.8.1 backend stays 'DOWN' when dns resolvers and http health checks are used

[Holger Amann]

> Am 18.12.2017 um 15:52 schrieb Christopher Faulet :
> 
> There have been some fixes since the 1.8.1. One of them could fix your 
> problem: http://git.haproxy.org/?p=haproxy-1.8.git;a=commit;h=80b92902 
> 
Thanks Christopher, that fixes it!