Re: General SSL vs. non-SSL Performance

[Pavlos Parissis]

On 17/03/2016 04:49 μμ, Nenad Merdanovic wrote:
> Hello Pavlos,
> 
> On 3/17/2016 4:45 PM, Pavlos Parissis wrote:
>> I am working(not very actively) on a solution which utilizes this.
>> It will use www.vaultproject.io as central store, a generating engine
>> and a pull/push mechanism in place.
>>
>> But, the current version of HAProxy doesn't support different TLS
>> tickets per frontend, which I would like to use.
> 
> What do you mean? You can specify tls-ticket-keys per bind line.
>>

I *was* wrong as I have completely forgot that and also that socket
command accepts IDs:

set ssl tls-key  

I am sorry for the spreading wrong information.

Cheers,
Pavlos



signature.asc
Description: OpenPGP digital signature

Re: HAProxy Configuration Best Practices

[Jeff Palmer]

Also,   I would consider setting maxconn appropriately to be critical.  You
want it high enough to handle your peaks/spikes,  but not so high as to
consume all resources available on the machine.

On Thu, Mar 17, 2016 at 9:49 AM, Baptiste  wrote:

>
>
> On Thu, Mar 17, 2016 at 1:17 PM, Gregg Cranshaw 
> wrote:
>
>> Hello,
>>
>> I am in the middle of a project where I have to setup a couple of load
>> balancers to allow load balancing traffic to some web app servers and to
>> provide an easy way to swap out some other resources. I have spent a lot of
>> time researching options and I settled on HAProxy with Keepalived to make
>> it fault tolerant.
>>
>> I have read through the HAProxy configuration options page as best I
>> could and I have the basic setup of HAProxy for a web server. I also setup
>> the stats option on the server. Do you have any tips or resources on what
>> best practices are for the haproxy.cfg file? Most options I find are basic
>> with the front and back end setup, the binding IP, the server list, and the
>> method used for load balancing. Is there anything else I should add to that
>> basic configuration? Is there an easy way to tell what the connection
>> counts should be? Any info would be greatly appreciated.
>>
>> Thanks for your time.
>>
>> Regards
>>
>>
>>
>> [image: signatureSeal]Gregg Cranshaw
>>
>> *Senior Network Engineer*
>>
>> RI Department of State  |  Secretary of State Nellie M. Gorbea
>>
>> Email: g crans...@sos.ri.gov  | Website:
>> www.sos.ri.gov  | Twitter: @RISecState 
>>
>> 148 W. River Street, Providence RI 02904 | 401-222-1326
>>
>>
>>
>> *Our Mission: *The Rhode Island Department of State engages and empowers
>> all Rhode Islanders by making government more accessible and transparent,
>> encouraging civic pride, enhancing commerce and ensuring that elections are
>> fair, fast and accurate.
>>
>
>
> Don't forget the following points:
> - setup proper timeouts (enable slow post protection)
> - configure an accurate health check
> - enable the stats page
>
> Baptiste
>



-- 
Jeff Palmer
https://PalmerIT.net

Re: Help! HAProxy randomly failing health checks!

[Zachary Punches]

Thanks for the reply!

Ok so based on what you saw in my config, does it look like we’re misconfigured 
enough to cause this to happen?

If we were misconfigured, one would assume we would go down all the time yeah?

From: Igor Cicimov 
mailto:ig...@encompasscorporation.com>>
Date: Wednesday, March 16, 2016 at 4:50 PM
To: Zachary Punches mailto:zpunc...@getcake.com>>
Cc: Baptiste mailto:bed...@gmail.com>>, 
"haproxy@formilux.org" 
mailto:haproxy@formilux.org>>
Subject: Re: Help! HAProxy randomly failing health checks!



On Thu, Mar 17, 2016 at 10:47 AM, Igor Cicimov 
mailto:ig...@encompasscorporation.com>> wrote:


On Thu, Mar 17, 2016 at 5:29 AM, Zachary Punches 
mailto:zpunc...@getcake.com>> wrote:
I’m not, these guys aren’t sitting behind an ELB. They sit behind route53 
routing. If one of the proxy boxes fails 3 checks in 30 seconds (with 4 checks 
done a second) then Route53 changes its routing from the first proxy box to the 
second




On 3/15/16, 9:46 PM, "Baptiste" mailto:bed...@gmail.com>> 
wrote:

>Maybe you're checking a third party VM :)
>

AFAIK the Route53 health checks come from different points around the globe and 
it is possible that at some time of the day AWS has scheduled some specific end 
points to perform the HC. And it is possible that those ones have different SSL 
settings from the ones performing the HC during your day time. I would suggest 
you bring up this issue with AWS support, let them know your SSL cypher 
settings in HAP and ask if they are compatible with ALL their servers 
performing SSL health checks.

I personally haven't seen any issues with failed SSL handshakes coming from AWS 
servers and have HAP's running in AU and UK regions.

Igor

That is if you are absolutely sure that the failed handshakes are not caused by 
overload or misconfigured (system) settings on HAP

Re: Help! HAProxy randomly failing health checks!

[Igor Cicimov]

On Thu, Mar 17, 2016 at 11:14 AM, Zachary Punches 
wrote:

> I wanna say average is like 4-6 connections a second? Super minimal
>
> From what I’ve seen in the logs during the SSL errors, the log hangs then
> outputs a bunch of SSL errors all at once.
>
> Here it the output from sysctl –p
> net.ipv4.ip_forward = 0
> net.ipv4.conf.default.rp_filter = 1
> net.ipv4.conf.default.accept_source_route = 0
> kernel.sysrq = 0
> kernel.core_uses_pid = 1
> net.ipv4.tcp_syncookies = 1
> error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key
> error: "net.bridge.bridge-nf-call-iptables" is an unknown key
> error: "net.bridge.bridge-nf-call-arptables" is an unknown key
> kernel.msgmnb = 65536
> kernel.msgmax = 65536
> kernel.shmmax = 68719476736
> kernel.shmall = 4294967296
>
> What would lowering the tune.ssl.default-dh-param to 1024 do?
> From: Igor Cicimov 
> Date: Wednesday, March 16, 2016 at 5:01 PM
> To: Zachary Punches 
> Cc: Baptiste , "haproxy@formilux.org" <
> haproxy@formilux.org>
> Subject: Re: Help! HAProxy randomly failing health checks!
>
>
>
> On Thu, Mar 17, 2016 at 10:55 AM, Zachary Punches 
> wrote:
>
>> Thanks for the reply!
>>
>> Ok so based on what you saw in my config, does it look like we’re
>> misconfigured enough to cause this to happen?
>>
>> If we were misconfigured, one would assume we would go down all the time
>> yeah?
>>
>> From: Igor Cicimov 
>> Date: Wednesday, March 16, 2016 at 4:50 PM
>> To: Zachary Punches 
>> Cc: Baptiste , "haproxy@formilux.org" <
>> haproxy@formilux.org>
>> Subject: Re: Help! HAProxy randomly failing health checks!
>>
>>
>>
>> On Thu, Mar 17, 2016 at 10:47 AM, Igor Cicimov <
>> ig...@encompasscorporation.com> wrote:
>>
>>>
>>>
>>> On Thu, Mar 17, 2016 at 5:29 AM, Zachary Punches 
>>> wrote:
>>>
 I’m not, these guys aren’t sitting behind an ELB. They sit behind
 route53 routing. If one of the proxy boxes fails 3 checks in 30 seconds
 (with 4 checks done a second) then Route53 changes its routing from the
 first proxy box to the second




 On 3/15/16, 9:46 PM, "Baptiste"  wrote:

 >Maybe you're checking a third party VM :)
 >

>>>
>>> AFAIK the Route53 health checks come from different points around the
>>> globe and it is possible that at some time of the day AWS has scheduled
>>> some specific end points to perform the HC. And it is possible that those
>>> ones have different SSL settings from the ones performing the HC during
>>> your day time. I would suggest you bring up this issue with AWS support,
>>> let them know your SSL cypher settings in HAP and ask if they are
>>> compatible with ALL their servers performing SSL health checks.
>>>
>>> I personally haven't seen any issues with failed SSL handshakes coming
>>> from AWS servers and have HAP's running in AU and UK regions.
>>>
>>> Igor
>>>
>>
>> That is if you are absolutely sure that the failed handshakes are not
>> caused by overload or misconfigured (system) settings on HAP
>>
>>
> I was saying this in regards to system (kernel) settings. For example,
> assuming Unix/Linux is your net.core.somaxconn actually set *higher* than
> your maxconn which is set to 3 and 15000 in HAP? Any other kernel
> settings you might have changed? (output of "sysctl -p" command)
>
> What is your pick hour load, how many connections/sessions are you seeing
> on each HAP?
>
> Another suggestion is maybe set tune.ssl.default-dh-param to 1024 and see
> if that helps.
>


Ok, so on default ubuntu cloud instance this is what we have:

# sysctl -a | grep maxconn
net.core.somaxconn = 128

which is too low for production server. Check your value and adjust it to
your needs.

By the way, what is accept-proxy doing there in your setup? Is there
anything else in front of HAP using PROXY protocol?

SSL and SNI keeping it all in HAProxy

[shouldbe q931]

I'm trying to get my head around how to get multiple HTTPS sites on
one public IP with HAProxy

After reading 
http://blog.haproxy.com/2012/04/13/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/
 I've got a rough idea of how to do the SNI ACLs

To keep all of the HTTPS termination in HAProxy (one place for
letsencrypt), do I then point each backend at a non SNI http mode
HTTPS front end, which then feeds a backend as required ?

Or have I missed something?

Cheers

Re: Help! HAProxy randomly failing health checks!

[Igor Cicimov]

On Thu, Mar 17, 2016 at 5:29 AM, Zachary Punches 
wrote:

> I’m not, these guys aren’t sitting behind an ELB. They sit behind route53
> routing. If one of the proxy boxes fails 3 checks in 30 seconds (with 4
> checks done a second) then Route53 changes its routing from the first proxy
> box to the second
>
>
>
>
> On 3/15/16, 9:46 PM, "Baptiste"  wrote:
>
> >Maybe you're checking a third party VM :)
> >
>

AFAIK the Route53 health checks come from different points around the globe
and it is possible that at some time of the day AWS has scheduled some
specific end points to perform the HC. And it is possible that those ones
have different SSL settings from the ones performing the HC during your day
time. I would suggest you bring up this issue with AWS support, let them
know your SSL cypher settings in HAP and ask if they are compatible with
ALL their servers performing SSL health checks.

I personally haven't seen any issues with failed SSL handshakes coming from
AWS servers and have HAP's running in AU and UK regions.

Igor

Re: General SSL vs. non-SSL Performance

[Nenad Merdanovic]

Hello Gary,

On 3/17/2016 11:51 AM, Gary Barrueto wrote:
> 
> While that would help a single server, how about when dealing with multi
> servers + anycast: Has there been any thoughts about sharing ssl/tls
> session cache between servers? Like how apache can use memcache to store
> its cache or how cloudfare used/patched openresty to do the same recently.
> 

HAproxy can load TLS ticket keys from file, which can be distributed by
a central server. That way the information is kept on the client side
and can be reused by any server in the anycasted pool.

https://cbonte.github.io/haproxy-dconv/configuration-1.6.html#5.1-tls-ticket-keys

Is there any reason why you'd still want to use session cache?

Regards,
Nenad

Re: HAProxy Configuration Best Practices

[Baptiste]

On Thu, Mar 17, 2016 at 1:17 PM, Gregg Cranshaw 
wrote:

> Hello,
>
> I am in the middle of a project where I have to setup a couple of load
> balancers to allow load balancing traffic to some web app servers and to
> provide an easy way to swap out some other resources. I have spent a lot of
> time researching options and I settled on HAProxy with Keepalived to make
> it fault tolerant.
>
> I have read through the HAProxy configuration options page as best I could
> and I have the basic setup of HAProxy for a web server. I also setup the
> stats option on the server. Do you have any tips or resources on what best
> practices are for the haproxy.cfg file? Most options I find are basic with
> the front and back end setup, the binding IP, the server list, and the
> method used for load balancing. Is there anything else I should add to that
> basic configuration? Is there an easy way to tell what the connection
> counts should be? Any info would be greatly appreciated.
>
> Thanks for your time.
>
> Regards
>
>
>
> [image: signatureSeal]Gregg Cranshaw
>
> *Senior Network Engineer*
>
> RI Department of State  |  Secretary of State Nellie M. Gorbea
>
> Email: g crans...@sos.ri.gov  | Website:
> www.sos.ri.gov  | Twitter: @RISecState 
>
> 148 W. River Street, Providence RI 02904 | 401-222-1326
>
>
>
> *Our Mission: *The Rhode Island Department of State engages and empowers
> all Rhode Islanders by making government more accessible and transparent,
> encouraging civic pride, enhancing commerce and ensuring that elections are
> fair, fast and accurate.
>


Don't forget the following points:
- setup proper timeouts (enable slow post protection)
- configure an accurate health check
- enable the stats page

Baptiste

RE: HAProxy -st not killing old processes

[Lukas Tribus]

Hi Bowen,


> Hi, 
> 
> We are using -p option to save the pid of HAProxy. When a new HAProxy 
> is received, we use -st pid option to reload HAProxy. 
> The issue we are having is that -st option sometimes does not kill the 
> old process. 

Please upgrade to 1.5.16 or 1.6.4, there have been fixes regarding those
problems.



Regards,

Lukas

  

Re: Help! HAProxy randomly failing health checks!

[Zachary Punches]

Ok! Here is a bunch of info that might better assist with the issue:


Each of our clients has an HAProxy install that forwards requests for 80 and 
443 to 1025 and 1026 respectively. These requests are forwarded over TCP using 
proxy protocol to our HAP instances.
Our HAP instances then SSL term the request and forward them off to our backend 
on port 80.

See attached diagram which should better explain the entire flow.

During an outage due to the SSL handshakes failing, I was running TCPDump so I 
could look through and discover what was causing the failure, I was able to 
discover that we are receiving connection resets on some SSL connections. We 
then tested all the SSL certs from our client side to our side to verify that 
there is not a mismatched cert. This test was completed with no issues.

Here is a connection reset packet I found in that TCP Dump

29525 158.09621710.1.4.119 54.239.21.251TCP 5438740 → 443 [RST] Seq=3533 Win=0 
Len=0

Frame 29523: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Mar 17, 2016 14:58:07.34584 PDT
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1458251887.34584 seconds
[Time delta from previous captured frame: 0.2 seconds]
[Time delta from previous displayed frame: 0.021655000 seconds]
[Time since reference or first frame: 158.096184000 seconds]
Frame Number: 29523
Frame Length: 54 bytes (432 bits)
Capture Length: 54 bytes (432 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:tcp]
[Coloring Rule Name: TCP RST]
[Coloring Rule String: tcp.flags.reset eq 1]
Ethernet II, Src: 12:8d:18:05:0f:91 (12:8d:18:05:0f:91), Dst: 1e:8f:a6:6b:52:58 
(1e:8f:a6:6b:52:58)
Destination: 1e:8f:a6:6b:52:58 (1e:8f:a6:6b:52:58)
Address: 1e:8f:a6:6b:52:58 (1e:8f:a6:6b:52:58)
 ..1.     = LG bit: Locally administered address 
(this is NOT the factory default)
 ...0     = IG bit: Individual address (unicast)
Source: 12:8d:18:05:0f:91 (12:8d:18:05:0f:91)
Address: 12:8d:18:05:0f:91 (12:8d:18:05:0f:91)
 ..1.     = LG bit: Locally administered address 
(this is NOT the factory default)
 ...0     = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: $SRC IP Dst: $DST IP
0100  = Version: 4
 0101 = Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
 00.. = Differentiated Services Codepoint: Default (0)
 ..00 = Explicit Congestion Notification: Not ECN-Capable Transport 
(0)
Total Length: 40
Identification: 0x5f56 (24406)
Flags: 0x02 (Don't Fragment)
0...  = Reserved bit: Not set
.1..  = Don't fragment: Set
..0.  = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (6)
Header checksum: 0x8018 [validation disabled]
[Good: False]
[Bad: False]
Source: $SourceIP
Destination: $DestinationIP
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Transmission Control Protocol, Src Port: 38740 (38740), Dst Port: 443 (443), 
Seq: 3533, Len: 0
Source Port: 38740
Destination Port: 443
[Stream index: 2799]
[TCP Segment Len: 0]
Sequence number: 3533(relative sequence number)
Acknowledgment number: 0
Header Length: 20 bytes
Flags: 0x004 (RST)
000.   = Reserved: Not set
...0   = Nonce: Not set
 0...  = Congestion Window Reduced (CWR): Not set
 .0..  = ECN-Echo: Not set
 ..0.  = Urgent: Not set
 ...0  = Acknowledgment: Not set
  0... = Push: Not set
  .1.. = Reset: Set
[Expert Info (Warn/Sequence): Connection reset (RST)]
[Connection reset (RST)]
[Severity level: Warn]
[Group: Sequence]
  ..0. = Syn: Not set
  ...0 = Fin: Not set
[TCP Flags: *R**]
Window size value: 0
[Calculated window size: 0]
[Window size scaling factor: 128]
Checksum: 0x5c2f [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Urgent pointer: 0





From: Igor Cicimov 
mailto:ig...@encompasscorporation.com>>
Date: Thursday, March 17, 2016 at 8:40 PM
To: Zachary Punches mailto:zpunc...@getcake.com>>
Cc: Baptiste mailto:bed...@gmail.com>>, 
"haproxy@formilux.org" 
mailto:haproxy@formilux.org>>
Subject: Re: Help! HAProxy randomly failing health checks!



On Fri, Mar 18, 2016 at 1:38 PM, Igor Cicimov 
mailto:ig...@encompasscorporation.com>> wrote:


On Fri, Mar 18, 2016 at 12:04 PM, Zachary Punches 
mailto:zpunc...@getcake.com>> wrote:
Yeah port 102

case @req.hdr puzzlement

[Jim Freeman]

I'm trying to add a header only if the last occurrence of it is not
the frontend_name (%f), but the header field name comparison seems to
be case sensitive when it should not be ?

haproxy.cfg

listen foo.bar
  bind  :10001
  mode  http
  log   127.0.0.1:514 local2 debug info

  acl XOH_OK req.hdr(X-Orig-Host,-1) -m str -i %f
  http-request add-header X-Orig-Host %f unless XOH_OK
  # http-request add-header X-Orig-Host %f if !{
req.hdr(x-orig-host,-1) -m str -i %f }

  capture request header X-Orig-HoST len 64

  server local localhost:80

curl test
===
curl -I -H 'X-Orig-Host: baz' -H 'x-oRiG-hOsT: foo.bar' -H 'Host:
foo.bar' localhost:10001/

headers as seen by lighttpd
=
2016-03-18 14:45:26: (request.c.311) fd: 7 request-len: 135
HEAD / HTTP/1.1
User-Agent: curl/7.38.0
Accept: */*
X-Orig-Host: baz
x-oRiG-hOsT: foo.bar
Host: foo.bar
X-Orig-Host: foo.bar

haproxy with this config should *not* have added the last header ???

System:
root@jfree:~# haproxy -v
HA-Proxy version 1.6.3 2015/12/25Debian Jessie, haproxy from backports
https://packages.debian.org/jessie-backports/haproxy

BTW - haproxy well and truly rocks ...

Re: case @req.hdr puzzlement

[Cyril Bonté]

Hi Jim,

Le 18/03/2016 21:52, Jim Freeman a écrit :

I'm trying to add a header only if the last occurrence of it is not
the frontend_name (%f), but the header field name comparison seems to
be case sensitive when it should not be ?


The analysis is not correct.


haproxy.cfg

listen foo.bar
   bind  :10001
   mode  http
   log   127.0.0.1:514 local2 debug info

   acl XOH_OK req.hdr(X-Orig-Host,-1) -m str -i %f


The issue is here : this is not supposed to work (well, not as you 
thought). ACLs don't support log-format variables for string comparison.
Here, you are asking to compare the "X-Orig-Host" header with the string 
"%f".



   http-request add-header X-Orig-Host %f unless XOH_OK
   # http-request add-header X-Orig-Host %f if !{
req.hdr(x-orig-host,-1) -m str -i %f }

   capture request header X-Orig-HoST len 64

   server local localhost:80

curl test
===
curl -I -H 'X-Orig-Host: baz' -H 'x-oRiG-hOsT: foo.bar' -H 'Host:
foo.bar' localhost:10001/

headers as seen by lighttpd
=
2016-03-18 14:45:26: (request.c.311) fd: 7 request-len: 135
HEAD / HTTP/1.1
User-Agent: curl/7.38.0
Accept: */*
X-Orig-Host: baz
x-oRiG-hOsT: foo.bar
Host: foo.bar
X-Orig-Host: foo.bar

haproxy with this config should *not* have added the last header ???


To illustrate what I previously wrote, you can try :
curl -I -H 'X-Orig-Host: baz' -H 'x-oRiG-hOsT: %f' -H 'Host: foo.bar' 
localhost:10001/


You'll probably see that haproxy will not add a third header.




System:
root@jfree:~# haproxy -v
HA-Proxy version 1.6.3 2015/12/25Debian Jessie, haproxy from backports
https://packages.debian.org/jessie-backports/haproxy

BTW - haproxy well and truly rocks ...




--
Cyril Bonté

RE: General SSL vs. non-SSL Performance

[Christian Ruppert]

Hi Lukas,

On 2016-03-16 16:53, Lukas Tribus wrote:

The "option httpclose" was on purpose. Also the client could (during a
attack) simply do the same and achieve the same result. I don't think
that will help in such cases.


So what you are actually and purposely benchmarking are SSL/TLS
handshakes, because thats the bottleneck you are trying to improve.


You're right, yes.



First of all the selected cipher is very important, as is the 
certificate

and the RSA key size.

For optimal performance, you would drop your RSA certificate
and get a ECC cert. If thats not a possibility then use 2048-bit
RSA certificates.


Your ab output suggest that the negotiated cipher is
ECDHE-RSA-AES128-GCM-SHA256 - which is fine for RSA certificates,
but your RSA certificate is 4096 bit long, which is where the 
performance

penalty comes from - use 2048bit certificates or better yet use ECC
certificates.

read: DO NOT USE RSA certificates longer than 2048bit.


Some customers may require 4096 bit keys as it seems to be much more 
decent than 2048 nowadays. So you may be limited here. A test with a 
2048 bit Cert gives me around ~770 requests per second, a test with an 
256 bit ECC cert around 1600 requests per second. That's still more than 
96% difference compared to non-SSL, way better than the 4096 bit RSA one 
though. I also have to make sure that even some older clients can 
connect to the site, so I have to take a closer look on the ECC certs 
and cipher then. ECC is definitively an enhancement, if there's no 
compatibility problem.





Both nginx [1] and haproxy currently do not support offloading TLS
handshakes to another thread or dedicating a thread to a TLS session.

Thats why Apache will scale better currently, because its threading.


Hm, I haven't tried Apache yet but would that be a huge benefit compared 
to a setup using nbproc > 1?






Hope this helps,

Lukas



[1] https://twitter.com/ngx_vbart/status/611956593324916736


--
Regards,
Christian Ruppert

Re: General SSL vs. non-SSL Performance

[Aleksandar Lazic]

Hi.

Am 16-03-2016 15:17, schrieb Christian Ruppert:

Hi,

this is rather HAProxy unrelated so more a general problem but anyway..
I did some tests with SSL vs. non-SSL performance and I wanted to share 
my

results with you guys but also trying to solve the actual problem

So here is what I did:


[snipp]


A test without SSL, using "ab":
# ab -k -n 5000 -c 250 http://127.0.0.1:65410/


[snipp]

That's much worse than I expected it to be. ~144 requests per second 
instead of
42*k*. That's more than 99% performance drop. The cipher a moderate but 
secure

(for now), I doubt that changing the cipher will help a lot here.
nginx and HAProxy
performance is almost equal so it's not a problem with the server 
software.
One could increase nbproc (at least in my case it only increased up to 
nbproc 4,
Xeon E3-1281 v3) but that's just a rather minor enhancement. With those 
~144 r/s

you're basically lost when being under attack. How did you guys solve
this problem?
External SSL offloading, using hardware crypto foo, special
cipher/settings tuning,
simply *much* more hardware or not yet at all?


You run both client & server on the same machine

Maybe you are running out of entropy?
Are you able to run the client on a different machine?

BR Aleks

Re: General SSL vs. non-SSL Performance

[Willy Tarreau]

Hi Christian,

On Fri, Mar 18, 2016 at 11:31:57AM +0100, Christian Ruppert wrote:
> I also just stumbled over this:
> https://software.intel.com/en-us/articles/accelerating-ssl-load-balancers-with-intel-xeon-v3-processors
> Might be interesting for others as well. So ECC and multi-threaded/process
> is the way to go it seems.

Thanks for this one, I had seen it once and lost it! I'll add it to
the list of articles on the haproxy page not to lose it anymore!

> >But note that people who have to deal with heavy SSL traffic actually
> >deal with this in haproxy by using to levels of processing, one for
> >HTTP and one for TLS. It means that only TLS traffic can be hurt by
> >handshakes :
> >
> >   listen secure
> >bind :443 ssl crt foo.pem process 2-32
> > mode tcp
> >server clear 127.0.0.1:80
> >
> >   frontend clear
> >bind :80 process 1
> > mode http
> >use_backend my_wonderful_server_farm
> >
> >   ...
> >
> 
> Your example would be better and easier but we need the client IP for ACLs
> and so forth which wouldn't work in tcp mode and there would be no XFF
> header. So we're duplicating stuff in the frontend but use one backend.

You don't need, just use the proxy protocol :

   listen secure
bind :443 ssl crt foo.pem process 2-32
mode tcp
server clear 127.0.0.1:81 send-proxy-v2

   frontend clear
bind 127.0.0.1:81 accept-proxy process 1
bind :80 process 1
mode http
use_backend my_wonderful_server_farm

Also, if you have one backend with all frontends bound to many processes,
then all your backends run on these processes, which makes it harder to
enforce maxconn limitations or to share stick-tables. That's why it's
much better to only move SSL out of the regular path. Of course if you
need to pass extra info, you'll have to enable HTTP in the frontend.

Regards,
Willy