in investigating various performance issues, I noted that we don't have a great throughput on client connections. while this is possibly not very problematic (clients don't usually have to do lots of frequent, repetitious connections), but just the same, checking with Openssl-bench, the number isn't great:
nhorman@hmsbeagle:~/git/openssl-bench$ LD_LIBRARY_PATH=../openssl ./bench --ecdsa handshake TLS_AES_256_GCM_SHA384
handshakes server TLSv1.3 TLS_AES_256_GCM_SHA384 6845.83 handshakes/s
handshakes client TLSv1.3 TLS_AES_256_GCM_SHA384 3232.94 handshakes/s
It would be nice if we could improve that.
One things I've noticed is that other implementations, when processing server certificates on the client, don't immediately decode the der string recieved in the server handshake messages. Instead they cache it, and decode just enough to complete the handshake, saving the full decode for later.
We don't have the infrastructure to do that right now, but we could implement some caching to avoid having to do the full decode on every single handshake.
in investigating various performance issues, I noted that we don't have a great throughput on client connections. while this is possibly not very problematic (clients don't usually have to do lots of frequent, repetitious connections), but just the same, checking with Openssl-bench, the number isn't great:
It would be nice if we could improve that.
One things I've noticed is that other implementations, when processing server certificates on the client, don't immediately decode the der string recieved in the server handshake messages. Instead they cache it, and decode just enough to complete the handshake, saving the full decode for later.
We don't have the infrastructure to do that right now, but we could implement some caching to avoid having to do the full decode on every single handshake.