Load Testing Runner

Solo’s Load Testing Runner allows you to analyze API behavior in scenarios of high simultaneous traffic, determining response speed and the breaking point under pressure.

---

Performance Metrics

Solo’s Runner executes requests in parallel and provides the following statistics:

• P95 / P99 Latency: Measurement of response time for 95% and 99% of calls, for an accurate assessment of user experience.
• Throughput (req/s): Number of requests per second handled by the server before performance slows down.
• Error Rate: Identification of the critical threshold where the server returns timeout or overload errors (503 Service Unavailable).

---

Running a Load Test

1. Request Configuration: Prepare the HTTP request (URL, Body, Auth).

2. Runner Tab: Access the “Runner” tab in the request editor.

3. Load Setup: Define the stress parameters:

   • Concurrency: Number of simulated users for sending simultaneous requests.
   • Iterations: Total number of requests to send during the test.

4. Start Test: Click “Start Run”. Results are displayed in real-time during execution.

Realistic Testing with Scripts

The Runner executes Pre-request and Post-response scripts for each iteration. This allows for the simulation of real-world scenarios with dynamic IDs or tokens generated for every single call.

---

Analyzing Results

During execution, Solo provides immediate visual feedback:

• Results Table: Display of status codes and response times for each call.
• Progress Bar: Monitoring the test completion status.
• Final Summary: Generation of a detailed report with time averages, minimum/maximum peaks, and success percentages at the end of the test.

---

Strategies for Effective Testing

Objective	Suggested Strategy
Stress Test	Gradually increase Concurrency until an increase in Error Rate is detected.
Baseline Performance	Run 100 Iterations with Concurrency 1 to measure base speed.
Stability	Set a high number of Iterations (e.g., 5000) to check for server degradation over time.

---

Troubleshooting (Failure Map)

Local Resource Exhaustion

Setting excessively high Concurrency (e.g., > 500) can cause system errors related to “file descriptors”. We recommend starting with low values and increasing gradually.

Stop on Error

If the “Stop on error” option is enabled, the Runner stops parallel requests at the first failure (e.g., 500 error). This function avoids overloading servers that are already crashing.

Rate Limiting

If you see 429 errors, the server is likely blocking calls due to an excessive number of requests sent in a short period (WAF or Rate Limiters).