3 ms·
Less than you think. You only need few cores to saturate tens of gigabits of traffic, HAProxy already is very performant. It's future-proofing basically. The
by ilyt 4y ago
Less than you think. You only need few cores to saturate tens of gigabits of traffic, HAProxy already is very performant.
It's future-proofing basically.
The page is ancient https://www.haproxy.org/10g.html https://www.haproxy.org/10g.html but they were doing 10Gbits on Core2Duo in '09 (sans SSL but back then AES acceleration wasn't very common either)
- wtarreau 4y agoIndeed, we've done 100Gbps about a year ago on a 8-core machine. Usually the only reason to use many cores is SSL, but since OpenSSL 3.0 that totally collapses under load, even then you're forced to significantly lower the number of threads (or to downgrade to 1.1.1 that about any high traffic site does).
- ivanr 4y agoDo you know what's behind the performance degradation of OpenSSL 3.0? Has the problem been documented anywhere?
- wtarreau 4y agoHorrible locking. 95% CPU spent in spinlocks. We're still doing measurements that we'll report with all data shortly. Anyway many of them were already collected by the project; there are so many that they created a meta-issue to link to them: https://github.com/openssl/openssl/issues/17627#issuecomment-1060123659 https://github.com/openssl/openssl/issues/17627#issuecomment... 3.1-dev is slightly less worse but still far behind 1.1.1. They made it too dynamic, and certain symbols that were constants or macroes have become functions running over lists under a lock. We noticed the worst degradation in client mode where the performance was divided by 200 for 48 threads, making it literally unusable.