Hi, Similar to what Christian asked about a few days ago I would like help to summarize the recommendations for running a haproxy as a SSL LB on a multi cpu, multi core machine.
I have a machine with two sockets equipped with Intel Xeon E5-2680 v4. 56 cores in total with HT enabled, 28 with HT disabled. Summary(correct me where I'm wrong): Hyperthreading - should be disabled As for network IRQ pinning, should I not pin the NIC to core 0 of each CPU? Should I split it up between the cores when doing SSL termination on most cores? global nbproc 28 # equal to the number of none HT cores (28 in my case) # cpu-map's equal to the number of non HT cores. # (didn't see any cpu-map in Christians configuration, is it not needed anymore?) cpu-map 1 0 cpu-map 2 1 ... cpu-map 28 27 frontend https bind :443 ssl crt /etc/ssl/xx.pem process 1 .... bind :443 ssl crt /etc/ssl/xx.pem process 28 # should I omitt process 1/2 and 15/16 here? # Should I use core 0 on each CPU for backends (proc 1+15) or should I use core 1(proc 2+16)? backend x bind-process 1 15 backend y bind-process 2 16 backend z # or should i use a bind-process like the frontend's bind? bind-process 2 bind-process 16 I just read the release notes for haproxy 1.7. There was mention of mixing different certificate types under "support of multi-certs". Previously I would have a tcp-ssl that would send traffic to a ecc backend and a rsa backend depending on req.ssl_ec_ext, which in turn would send traffic to a frontend with two sockets, one for each certificate type. To something like this (hope my ascii doesn't get messed up). +-->backend01 +--->backend-ecc+ | frontend-tcp-ssl:443 | +--->frontend-https+-->backend02 +--->backend-rsa + | +-->backend03 Does this mean I can now mix RSA and ECC certificates on the same frontend and skip the entire frontend-backend-frontend trick? +-->backend01 | frontend-https:443+-->backend02 | +-->backend03 Thanks, Elias