-
-
Notifications
You must be signed in to change notification settings - Fork 11.1k
Closed as not planned
Labels
branch: 3.0Applies to openssl-3.0 branchApplies to openssl-3.0 branchbranch: 3.1Applies to openssl-3.1 (EOL)Applies to openssl-3.1 (EOL)branch: 3.2Applies to openssl-3.2 (EOL)Applies to openssl-3.2 (EOL)branch: masterApplies to master branchApplies to master branchinactiveThis label should not be applied to open issues anymore.This label should not be applied to open issues anymore.triaged: bugThe issue/pr is/fixes a bugThe issue/pr is/fixes a bugtriaged: performanceThe issue/pr reports/fixes a performance concernThe issue/pr reports/fixes a performance concern
Description
I have tested the workarounds with a single global instance for AES and SHA-1 HMAC mentioned in this comment and this comment in #17064.
If the default provider is used the required performance dropped to an acceptable value (only somewhat slower than with version 1.0.2).
But if we use the FIPS provider instead the catastrophic performance issue did appear again!
In the test used with 500 channels, around 150 could not be set up and the remaining around 350 required around 2000% CPU instead of the around 700% otherwise required for all 500 channels, see my comment there.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
branch: 3.0Applies to openssl-3.0 branchApplies to openssl-3.0 branchbranch: 3.1Applies to openssl-3.1 (EOL)Applies to openssl-3.1 (EOL)branch: 3.2Applies to openssl-3.2 (EOL)Applies to openssl-3.2 (EOL)branch: masterApplies to master branchApplies to master branchinactiveThis label should not be applied to open issues anymore.This label should not be applied to open issues anymore.triaged: bugThe issue/pr is/fixes a bugThe issue/pr is/fixes a bugtriaged: performanceThe issue/pr reports/fixes a performance concernThe issue/pr reports/fixes a performance concern