Hi Willy,
On 2016-03-17 06:05, Willy Tarreau wrote:
Hi Christian,
On Wed, Mar 16, 2016 at 05:25:53PM +0100, Christian Ruppert wrote:
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.
You also found the hard way why it's important to share TLS secrets
between multiple front nodes, or to properly distribute the load to
avoid handshakes as much as possible.
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.
>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?
Here I don't know. TLS handshakes are one large part of what made me
think
that we must go multi-threaded instead of multi-process over the long
term,
just because I want to be able to pin some tasks to some CPUs. Ie when
TLS
says "handshake needed", we want to be able to migrate the task to
another
CPU to avoid the huge latency imposed to all other processing (eg: 7ms
in
your case).
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.
And before linux kernel reintroduced support for SO_REUSEPORT (in
3.9), it was common to have the single process load-balance incoming
TCP connections to all other TLS processes. It then makes it possible
to chose the LB algo you want, including source hash so that a same
attacker can only affect one process for example.
Willy
--
Regards,
Christian Ruppert
