performance of openssl 1.1.1p vs. 3.1.0

[vitalyk-radware]

I compared performance of openssl versions 1.1.1p and 3.1.0 using nginx 1.23.4 as a server and siege 4.1.6 as a client.
I tried three ciphers and in each of these benchmarks, 1.1.1 has better performance.
Is it a well known issue or the tests are not correct?
Thank you!

                         1.1.1  hits     3.1.0 hits
AES256-SHA256                18728       8134
ECDHE-RSA-AES256-GCM-SHA384   16514    16015
ECDHE-ECDSA-AES256-GCM-SHA384   76020     64967

siege command is :

siege  -t1M -b  https://localhost:4411

p.s. All tools have been built with default config options; nginx webserver returns its default page.

[paulidale]

Yes, the performance loss is known. OpenSSL 3.x requires a slightly different approach and pre-fetching algorithms avoids the majority of the losses.

[vitalyk-radware]

Thank you very much for your reply. We would like to use openssl v.3 library in same way as we used V1.1. Our program is a TLS server and it works in most basic way (SSL_CTX_new, SSL_CTX_use_PrivateKey_file, SSL_new, SSL_accept, SSL_read). I would like to learn how we should modify this program to achieve best performance in v.3 . Can you please recommend a tutorial how we do it? (I read about explicit fetching, but we do not call functions like EVP_DigestInit() directly . It happens inside SSL… Therefore, I doubt how we can fetch algorithms in advance… ) Thank you, Vitaly From: Pauli ***@***.***> Sent: Sunday, May 21, 2023 3:27 PM To: openssl/openssl ***@***.***> Cc: Vitaly Kroivets ***@***.***>; Author ***@***.***> Subject: Re: [openssl/openssl] performance of openssl 1.1.1p vs. 3.1.0 (Issue #21005) CAUTION: EXTERNAL EMAIL. Yes, the performance loss is known. OpenSSL 3.x requires a slightly different approach and pre-fetching algorithms avoids the majority of the losses. — Reply to this email directly, view it on GitHub<#21005 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A6ECPGJCSYJRWUYFOAKVXPTXHICYTANCNFSM6AAAAAAYIJBIOY>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[mattcaswell]

I read about explicit fetching, but we do not call functions like EVP_DigestInit() directly . It happens inside SSL…
Therefore, I doubt how we can fetch algorithms in advance…

If you are working mostly with libssl then the SSL_CTX will cache explicit fetches for you. Therefore it is important to re-use an SSL_CTX across multiple connections, i.e. do not create a new SSL_CTX for each SSL object.

[Liu-ErMeng]

Another point might help.
According to the results of my testing and analysis，the specific cipher suite AES256-SHA256 invoke the tls1_mac in tls connection in both openssl1.x and openssl3.x. The performance of tls1_mac in openssl3.x dropes a lot compare to openssl1.x, it's because openssl3.x uses provider mechanism to implement mac instead, which has a longer calling path.

[t8m]

@mattcaswell it seems the tls1_mac still uses the old method of computing hmac through EVP_DigestSign? Could refactoring to use EVP_MAC help?

[mattcaswell]

Could refactoring to use EVP_MAC help?

Quite possibly. Not sure how easy it will be though

[mattcaswell]

According to the results of my testing and analysis，the specific cipher suite AES256-SHA256 invoke the tls1_mac in tls connection in both openssl1.x and openssl3.x. The performance of tls1_mac in openssl3.x dropes a lot compare to openssl1.x, it's because openssl3.x uses provider mechanism to implement mac instead, which has a longer calling path.

Do you have some statistics on the tls1_mac performance drop? And any details about how you did your testing would be helpful.

[Liu-ErMeng]

According to the results of my testing and analysis，the specific cipher suite AES256-SHA256 invoke the tls1_mac in tls connection in both openssl1.x and openssl3.x. The performance of tls1_mac in openssl3.x dropes a lot compare to openssl1.x, it's because openssl3.x uses provider mechanism to implement mac instead, which has a longer calling path.

Do you have some statistics on the tls1_mac performance drop? And any details about how you did your testing would be helpful.

Yes. It's the server-side perf data.
openssl-3.0.7

openssl1.1.1n

[mattcaswell]

Hmmm. I don't understand the increase spent in SHA256_Update from 16.39 to 20.62. Most of the performance difference seems to be there.

[vitalyk-radware]

I would like to ask about OPENSSL_LH_doall_arg / do_name functions.
They are responsible for 2-5% of CPU time in my becnhmark test (server with cipher ECDHE-ECDSA-AES256-GCM-SHA384).
Can we do anything to minimize their effect on performance?
I understand it may be related to some "legacy" more of keys... is it true?

below is a trace of these fnunctions:

#0  0x00000000005d0690 in do_name ()
#1  0x00000000005cee5c in OPENSSL_LH_doall_arg ()
#2  0x00000000005d0888 in ossl_namemap_doall_names ()
#3  0x00000000005c7827 in int_ctx_new.constprop ()
#4  0x00000000005bf195 in do_sigver_init ()
#5  0x00000000005bf3b3 in EVP_DigestSignInit_ex ()
#6  0x00000000005c2a79 in EVP_PKEY_digestsign_supports_digest ()
#7  0x0000000000521494 in check_cert_usable.isra ()
#8  0x000000000052534c in tls_choose_sigalg ()
#9  0x0000000000552822 in tls_post_process_client_hello ()
#10 0x000000000053fd12 in state_machine ()
#11 0x0000000000516834 in SSL_do_handshake ()