Somewhat tangentially related to this is the how thread locking in OpenSSL is slowing things up.
We've been doing some connection establishment performance analysis recently and have discovered a lot of waiting on locks is occurring. By far the worst culprit is CRYPTO_LOCK_EVP_PKEY in CRYPTO_add_lock calls. Changing these to gcc's atomic add operations (__sync_add_and_fetch) improved things significantly: base OpenSSL 11935 connections/s 85% CPU utilisation with Atomic Change 16465 connections/s 22% CPU utilisation So fifty percent more connections for a quarter the CPU. At this point a number of other locks are causing the slow down. Now, I'm not sure if such a change would be interesting to the community or not, but there definitely is room for significant gains in the multi threaded locking. Ignoring the atomic operations and moving to a separate lock per reference count would likely save a an amount of blocking -- is this a suitable use for dynamic locks? I also submitted a bug report and fix recently [openssl.org #4135] to do with threading, which will hopefully get included eventually. Regards, Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
