As a Mojaloop implementer, I want to make sure that there is no performance deviation on vNext

[JulieG19]

The purpose of this ticket is to prepare for the release process and work on the release process checks. We want to make sure that we can transparently demonstrate that there is no performance degradation of vNow.

To complete this ticket, we need the current performance numbers on vNow.

[JulieG19]

Note:

1. There is also a performance workstream addressing current issues.
2. The performance team may not know vNext have a dependency on their work

[JulieG19]

Note from sprint planning:

For performance tests, the performance testing team is using Tracestate

https://github.com/mojaloop/mojaloop-specification/blob/master/fspiop-api/documents/Tracing%20v1.0.md#table-4--data-model-for-tracestate-list-member-values

https://github.com/mojaloop/mojaloop-specification/blob/master/fspiop-api/documents/Tracing%20v1.0.md

Note: probably the specs need to be reviewed as well and perhaps specs need to be updated.

[JulieG19]

Note from sprint planning: existing tests: https://github.com/mojaloop/ml-core-test-harness/tree/main/packages/k6-tests

[pedrosousabarreto]

I appreciate that ml-perf-characterization repo is very detailed, but It's not ideal to have to extract the results and the conditions used for the tests from those readme files. There are lots of different scenarios in each use case, and it is not clear which numbers we will use as the base for the comparison.

With that said, can we get a summary clarifying the exact vNow test procedures that were followed and exact results obtained in a simple form?

Ideally without test specific code like the one mentioned in this comment regarding this PR

Also, can we document in the most simple way possible the requirements and flow for each test? Ideally without anything that is specific to either vNow or vNext, but simply using the external FSPIOP API contract.

Something like this example for lookups:

• An initial GET /parties/MSISDN/$randomId request is sent to the FSPIOP API (this request includes the request timestamp in a header
• (the switch will do its work until it sends the request to the FSP who owns the party)
• A participant simulator will later respond to the subsequent GET /parties call from the switch with an predetermined payload, measuring the first leg duration.
• (the switch will do its work until it sends the final response to the requester FSP)
• Another participant simulator will capture the PUT /parties callback and measure both the second leg as well as the total duration.

This example was extracted from the happy path use case documented in our reference architecture: https://docs.mojaloop.io/reference-architecture-doc/boundedContexts/accountLookupAndDiscovery/#get-party