On 5/29/23 20:38, Willy Tarreau wrote:
Have you verified that the CPU is saturated ?
The CPU on the machine running the test settles at about 1800 percent
for my test program. 12 real cores, hyperthreaded.
The CPU on the frontend haproxy process is barely breathing hard. Never
saw it get above 150%. That server has 24 real cores.
The CPU on the backend haproxy running on the raspberry pi hovers
between 250 and 280%. It's a 3B, so it has four CPU cores.
Those CPU values gathered with the test program running 24 threads with
quictls 1.1.1t. With 200 threads, the CPU usage on all 3 systems is
even lower.
So I would say I am not saturating the CPU. I need a different test
methodology ... this Java program is not really doing much to haproxy.
Without keep-alive nor TLS resume, you should see roughly 1000 connections
per second per core, and with TLS resume you should see roughly 4000 conns/s
per core. So if you have 12 cores you should see 12000 or 48000 conns/s
depending if you're using TLS resume or full rekey.
It's doing whatever Apache's httpclient does with Java's TLS. I know
it's not doing keepalive, I explicitly pass the connection close header.
I do not know if it uses TLS resume or not, and I do not know how to
discover that info.
I'm not seeing anywhere near that connection rate. Not even with an
haproxy backend.
Hmmm are you sure you didn't build the client with OpenSSL 3.0 ? I'm asking
because that was our first concern when we tested the perf on Intel's SPR
machine. No way to go beyond 400 conn/s, with haproxy totally idle and the
client at 100% on 48 cores... The cause was OpenSSL 3. Rebuilding under 1.1.1
jumped to 74000, almost 200 times more!
The client is a Java program running in Java 11, with nothing to have it
use anything but Java's TLS. It should not be using any version of openssl.
https://asciinema.elyograg.org/haproxyssltest1.html
Hmmm host not found here.
Oops. I did not get that name in my public DNS. Fixed. The run it
shows is from earlier, before I set up a backend running haproxy. That
run is using 200 threads. When it ends, it reports the connection rate
at 244.69 per second.
Thanks,
Shawn
