SDK.finance system performance testing

TL;DR

SDK.finance conducted performance testing to define workload capacity and run Transactions Per Second (TPS) assessment. The system configuration involved AWS EC2, with the following results:

• The SDK.finance system workload capacity is 400 Transactions Per Second (TPS)
• Backend CPU usage remained below 70% at a load of 400 TPS.
• Database CPU usage stayed below 38% at a load of 400 TPS

Performance testing process overview

1. Defining performance goals and acceptance criteria.
2. Workload modeling.
3. Test environment setup.
   At SDK.finance, our chosen toolset includes:
   • Prometheus is a monitoring system for collecting system metrics.
   • Grafana and k6 for executing test scenarios and emulating workloads.
   • InfluxDB for storing metrics from the K6 load test tool.
   • Grafana for interactive visualization and analysis of data from Prometheus and InfluxDB.
4. Test scenarios creation and execution.
5. Test results analysis and reporting.

SDK.finance system performance testing results

Goals

• Determine the purpose of the testing, such as defining the workload capacity of the specific test environment.
• Assess how many Transactions Per Second (TPS) the environment can handle without errors while maintaining response times within SLA.
• Identify the maximum number of money transfer transactions per second that the test environment can process.
• Detect any potential bottlenecks within the system.
• Compare the system’s performance under varying workloads and establish correlations between workload and response time metrics.

Test environment configuration

• Platform: AWS EC2
• Frontend: 4 vCPU and 16 GB RAM
• Backend: 16 vCPU and 32 GB RAM (Java Heap Size: 15875 MB)
• Postgres Database (RDS): 32 vCPU and 128 GB RAM, supporting at least 1,000,000 user profiles (700,000 individuals and 300,000 merchants)
• MongoDB: 4 vCPU and 16 GB RAM

Load test scenarios

• The load test scenario involves a single API call: POST /api/v1/transfers, which facilitates money transfers between user wallets.
• For each virtual user (thread) and each iteration, a pair of coin serials is randomly selected from a shared data pool containing 50,000 wallets (coins).

Picture 1. Dependence of the response time upon the workload.

Conclusions

• Response time exhibits a significant dependence on workload.
• Backend CPU usage remains below 70% at a workload of 400 TPS, indicating the capacity to handle increased workloads.
• Database CPU usage stays below 38% at a workload of 400 TPS, implying room for handling additional workloads.
• Data Pool (DP) connections are not released during the test, leading to a surplus of idle connections.
• No memory leaks were detected; memory is consistently released, and memory limits are not reached.
• IO Latency (Write and Read) increases up to 14 msec as the workload grows, with IO:WALWrite operations being the most significant factor on the database side.

This report summarizes the outcomes of our rigorous system performance testing and provides valuable insights into the capabilities and potential improvements of the SDK.finance system.