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
