[openssl-users] Performance problems with OpenSSL and threading

[Bryan Call]

So can I assume the FIPS POST has completed if I never call FIPS_mode_set() in the code?  I was confused about that.

When we call SSL_read() and get a 0 byte return we call SSL_get_error() to see if there was an error not not.  Maybe there is a more efficient handle this, like looking at the shutdown flag?

       0   The read operation was not successful. The reason may either be a
           clean shutdown due to a "close notify" alert sent by the peer (in
           which case the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state
           is set (see SSL_shutdown(3), SSL_set_shutdown(3)). It is also
           possible, that the peer simply shut down the underlying transport
           and the shutdown is incomplete. Call SSL_get_error() with the
           return value ret to find out, whether an error occurred or the
           connection was shut down cleanly (SSL_ERROR_ZERO_RETURN).

When we call SSL_accept we also call SSL_get_error() to see we need to read or write.  Is there a more efficient way to tell if we need to read or write?

       If the underlying BIO is non-blocking, SSL_accept() will also return
       when the underlying BIO could not satisfy the needs of SSL_accept() to
       continue the handshake, indicating the problem by the return value -1.
       In this case a call to SSL_get_error() with the return value of
       SSL_accept() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
       The calling process then must repeat the call after taking appropriate
       action to satisfy the needs of SSL_accept().  The action depends on the
       underlying BIO. When using a non-blocking socket, nothing is to be
       done, but select() can be used to check for the required condition.
       When using a buffering BIO, like a BIO pair, data must be written into
       or retrieved out of the BIO before being able to continue.


Thank you...

-Bryan




> On May 1, 2015, at 5:34 AM, John Foley <foleyj at cisco.com> wrote:
> 
> Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.  It appears your application is generating a lot of errors for some reason.  Never tried it myself, but you probably can't disable this lock with multiple threads running.  You should take a look at the error log to identify the cause of the errors.  Then resolve the issue, whatever it may be.  
> 
> 
> 
> On 04/30/2015 06:52 PM, Bryan Call wrote:
>> This is for Apache Traffic Server and we have no knobs for turning on/off FIPS.  I am thinking about always disabling FIPS right now and that would happen before we create the threads. 
>> 
>> I was able to get rid of all the FIPS lock connection with the changes you recommend (Big Thanks!).  The big one now is type 1.  I am printing out the log every time the contention total is mod 1M.  Are there any tricks I can do for type 1 locks?
>> 
>> [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock - total contention: 4000000 waiting: 1 file: pmeth_lib.c line: 185 type: 10
>> [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock - total contention: 11000000 waiting: 2 file: err.c line: 469 type: 1
>> [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock - total contention: 4000000 waiting: 0 file: ex_data.c line: 304 type: 2
>> [Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock - total contention: 12000000 waiting: 5 file: err.c line: 446 type: 1
>> [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock - total contention: 1000000 waiting: 0 file: rand_lib.c line: 212 type: 19
>> 
>> -Bryan
>> 
>> 
> 
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users