The stress test will be divided into contract loading, writing operations, and reading operations.
Contract loading: we will start by registering the smart contract into the blockchain to be used for future operations.
Writing operations: the test goal is to find that the endpoints are working too, so this is where we run all writing operations, basically any procedure that changes the state of the blockchain, such as transactions or specific contract calls.
Reading operations: this is the real deal, we want to find out how scalable is our API, and we want to run across all our endpoints first to find out if they are still working as intended, but also we want to try different payloads, and be able to run this test in parallel as much as the hosting hardware allows it.
We can take this a step further by deploying an set of instances using terraform where each of them will run the read endpoints, after the test is finished all the instances will be destroyed. Effectively performing a more realistic scenario
We can automate this process using the PR interface, where we will create a PR by changing a config file where we will indicate the parameters of our test such as the number of instances or indicating the set of available tests. Leveraging the flexibility of Github actions the PR will
We can take this further by deploying a set of instances using terraform. They will run the read endpoints; after the test is finished, all the instances will be destroyed—effectively performing a more realistic scenario. We can automate this process using the PR interface. We will create a PR by changing a config file where we will indicate the parameters of our test, such as the number of instances or telling the set of available tests. Leveraging the flexibility of Github actions, the PR will load the contract to perform the write operations; then, it will run a single shot of the read operations. This first phase is to ensure all the endpoints are still working.
Then the PR will proceed by deploying the distributed infrastructure where it'll bombard our RPC API. When it finishes, it'll post a small report in the PR comment section with a link to Grafana framed with the time of the test duration to visualize the results.
Metrics: we don't have to do much in this area. We are already exporting all the necessary metrics to Prometheus of each endpoint. We can look at Grafana while the test is running to see how this test affects our systems.
Using PRs as UI tool, we can keep a history of tests run for future benchmarking. And closing the PR will effectively destroy all the infra deployed for the test, giving us an easy way to halt tests if things are going south. At the end of each test, the PR can be closed by either the tester or the PR itself after a couple of hours of inactivity.