[openssl-users] Performance problems with OpenSSL and threading

[John Foley]

Yes, if you never call FIPS_mode_set(), the POST will never run.  I'll
defer to the experts on your other questions.


On 05/01/2015 05:10 PM, Bryan Call wrote:
> 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
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> .
>