Load Testing Architecture Design

[esune]

Document the architecture and technical requirements/steps necessary to perform load testing of VC issuance/revocation/verification.

[swcurran]

The BC Gov Digital Trust team would like to know the current capacity (measured in transactions per minute) of select BC Gov verifiable credential issuers and verifiers. The goal is to understand if the services are capable of processing loads that might be expected when the opportunity to receive and present the credentials is opened to the general public. As the teams iterate on the service deployments, we’d like to be able to rerun the load tests to see the impact on the capacity as progress is made on the services.

The services under test will run in a test environment using minimally modified versions of the issuers and verifiers. The load test documentation produced from this effort must cover how to integrate the load test generator with the systems to be tested (issuers, verifiers, mediator). The BC Gov maintainers of the issuers, verifiers, and mediator to be tested will make the changes necessary for running load tests. The Aries community has used the open source tool Locust for generating loads. Locust is designed to generate a load by executing defined scripts at specified rates. Barring a better choice, Locust will be used to run a load generating script that spins up a simulated wallet at a defined rate to:

• Connect to the testing mediator instance.
• Request the issuance of a credential from the designated issuer service.
• Periodically completes a presentation request/presentation sequence with a designated verifier service.

The load test generator must be capable of producing the following sustained load:

• 38 issuances per minute
• 165 verifications per minute

Ensuring that the services can sustain such a load is the responsibility of the BC Gov maintainers responsible for those services. An execution of the load test generator with mocked issuer, verifier, and mediator services is sufficient to demonstrate that capability.

The existing implementation of a similar capability uses an instance of Aries Framework JavaScript per wallet, which puts a very heavy load on the load generator system itself, such that the test runs frequently crash the generator before hitting the capacity of the systems under test. We expect that the scripting process will need to be implemented to use a multi-tenant version of Aries to reduce the resource usage on the load generator. Each wallet will be a tenant in a single, scalable instance of Aries.

The proposed architecture for the implementation: