Enhance SDK characterisation to include Security

[PaulGregoryBaker]

Goal:

As a Mojaloop Community member
I want to understand the performance characterisation of the Mojaloop Connector with security enabled
so that use this to plan and cost an appropriate deployment of mojaloop particpation tools that meets my availability and performance requirements.

Acceptance Criteria:

• Verify that testing harness used to characterise the SDK in terms of performance has
  • mTLS enabled
  • JWS enabled
• Verify that the impact of enabling security is calculated. I.e. measurement without security compared to measurement with security
• Document the findings
• Perform basic validation of the performance using e.g. profiling tools, to improve the performance where applicable. When the work required is more substantial, then create a story based on findings.

Complexity: <High|Medium|Low> > A short comment to remind the reason for the rating

Uncertainty: <High|Medium|Low> > A short comment to remind the reason for the rating

---

Tasks:

• Set up security in ml core test harness
• Perform security equivalent charactization of sdk non security passes
• Logger fixes for sdk components
• Logger fixes for sdk
• Rerun characterizations
• Document findings

Done

• Acceptance Criteria pass
• Designs are up-to date
• Unit Tests pass
• Integration Tests pass
• Code Style & Coverage meets standards
• Changes made to config (default.json) are broadcast to team and follow-up tasks added to update helm charts and other deployment config.
• TBD

Pull Requests:

• TBD

Follow-up:

• N/A

Dependencies:

• N/A

Accountability:

• Owner: TBC
• QA/Review: TBC

[kleyow]

Primlimanary testing lead to easily fixable issues such as pruning object serialization in jws signing of the sdk-standard-components and else where in the sdk api-svc.

Though after isLevelEnabled and log leveling functionality/silenceing the sdk continues to demonstrate poor performance on mtls and jws requests.

Though there is a critical issue #3762 blocking this story current test runs show around 200~ ops/s in non-security mode and around 20~ ops/s in security mode on the /transfers endpoint (refresher that the sdk /transfers does several
requests to accomplish discovery/agreement/transfer so an "op" represents from the start of discovery to the final sync response after the transfer phase).

Roughly, a tenth of the performance.

This lead to more profiling of the service where no observable source code was impacting performance. The decreased performance seems to lay in first party node tls library signing/settings keys/encryption.
Leading me to believe that this is currently the most optimal performance numbers unless there is better mtls configuration options for the under lying https library.

The suggestions Paul and I reached are

• Exploring configuration options for the inbuilt https library
• Trying to migrate the https library to http/2

[kleyow]

#3809