On Tue, Nov 24, 2015 at 07:56:15am +1000, Paul Dale wrote: > 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.
Is this TLS connections? > At this point a number of other locks are causing the slow down. I'd like to know more... > 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? As Matt mentioned, I'm curently working exactly on this. Would it be possible for you to share your testing method and code? I'd like to verify that my patches actually go in the right direction before having them merged (or maybe you could do your tests on top of my patches, they should mostly work fine even if the work is not complete yet, I think). Thanks _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
