Characterise the Mojaloop Connector

[PaulGregoryBaker]

Goal:

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

Notes:
The API

Acceptance Criteria:

• Add SDK to the test harness docker compose
• Verify that the perf docker compose in the mojaloop core test harness repository is updated to use the latest Mojaloop connector SDK and callback handler as backend
• Verify that the transactions per second performance of the mojaloop connector for a full transaction is understood
  • as a Payer DFSP
  • as a Payee DFSP
• Verify the amount of data stored per transfer is understood
• Verify that the profiler is run on the API service Module to observe for any obvious problems
• Any performance issue that are found should fixed if they are small; and written up as stories if they are not.

Diagram showing test for payer SDK

Diagram showing test for payee SDK

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:

• Include SDK Into Test Harness
• Add new docker compose profiles
  • for running SDK+Callback handler in payer mode (Callback handler acts as switch)
  • for running SDK+Callback handler in payee mode (Callback handler acts as backend)
• Add API handlers for SDK backend sync resources (parties, qutoesrequests and transfers) to callback handler
• Create k6 test for Payer SDK
• Create k6 test for Payee SDK
• Benchmark the SDK into reasonable performance

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

[aaronreynoza]

This feature will be continued on a new architecture following #3747