Spike Testing with K6

In performance testing, Spike Testing is a method used to evaluate a system’s ability to handle sudden surges in traffic. The goal is to assess how the system reacts and recovers when faced with a rapid increase in the number of users over a short period of time. K6 is an excellent tool for Spike Testing thanks to its simplicity and flexibility in configuring test scenarios. In this article, we will learn how to perform Spike Testing with K6, as well as explain how to measure and analyze the results to gain a clearer understanding of the system’s load-handling capabilities.

How to Perform Spike Testing with K6

1. Install K6

To get started with K6, you first need to install the tool on your machine. K6 supports multiple platforms:

MacOS: Use Homebrew with the command brew install k6.
Windows: Install via Chocolatey using the command choco install k6.
Linux: You can download it directly from the K6 website or install via APT/YUM. (Refer to the installation guide here: https://grafana.com/docs/k6/latest/set-up/install-k6/)

Once successfully installed, you can verify it with the command k6 version to check the installed version.

2. Build a Spike Test Script

To perform Spike Testing with K6, we need to create a test script with stages simulating a sudden spike in load. This script will rapidly increase the number of Virtual Users (VUs) over a short period and then drop back to a normal level.

import http from 'k6/http';
import { sleep } from 'k6';

export let options = {
  stages: [
    { duration: '30s', target: 50 },  // Ramp up to 50 VUs in 30 seconds
    { duration: '10s', target: 400 }, // Sudden spike to 400 VUs
    { duration: '30s', target: 400 }, // Hold at 400 VUs for 30 seconds
    { duration: '10s', target: 50 },  // Drop back to 50 VUs
    { duration: '30s', target: 0 },   // Gradually scale down to 0 VUs
  ],
};

export default function () {
  http.get('http://test.k6.io');
  sleep(1); // Simulate user think time
}

Explanation of the Script:

Import Library:
- http: K6 supports the HTTP library to perform requests.
- sleep: Adds delays between requests, simulating real user think time.
Options:
- Defines 5 stages for the test, each specifying the number of Virtual Users (VUs) over a specific duration.
- Stage 2: Simulates a spike with a sudden increase to 400 users.
- Stage 3: Tests the system’s ability to sustain a high load over a period of time.
HTTP Requests:
- http.get: Sends GET requests to the target URL http://test.k6.io using multiple VUs.

3. Execute the Test

Run the test script using the following command:

k6 run script-name.js

Analyzing Test Results

Data Sent and Received

Data Received: 161 MB at a speed of 1.6 MB/s.
Data Sent: 2.9 MB at a speed of 28 kB/s.
- Observation: The processing speed remained stable, meeting the demand for handling a high volume of data.

HTTP Request Blocked Time (http_req_blocked)

Average Time: 12.65ms (ranging from 0s to 1.99s).
Maximum Time: 1.99s.
- Observation: A small number of requests experienced delays, likely due to network connection or TLS processing issues.

HTTP Request Connection Time (http_req_connecting)

Average: 8.62ms.
- Observation: The system maintained a fast connection time, with minimal delays for most requests.

HTTP Request Duration (http_req_duration)

Average: 293.11ms (ranging from 231.41ms to 1.59s).
90th Percentile (p(90)): 319.48ms.
95th Percentile (p(95)): 482.42ms.
- Observation: Response times remained stable, with most requests under 500ms. Higher response times (>1s) occurred due to sudden spikes in load.

Request Failure Rate (http_req_failed)

Result: 0.00%, with no failed requests.
- Observation: This is a highly positive result, showing the system can handle sudden spikes without errors.

HTTP Waiting Time (http_req_waiting)

Average: 282.28ms (ranging from 231.36ms to 1.59s).
- Observation: Consistent with the http_req_duration, indicating short server processing times.

Number of Requests and Iterations

Total Requests: 26,862 requests, with a processing rate of 268 requests per second.
Iterations: 13,431 iterations at a rate of 134 iterations per second.
- Observation: Confirms the system maintained its ability to handle a large workload without issues.

Conclusion

The test results demonstrate that the system performs exceptionally well when the load spikes to 400 Virtual Users. Response times remained stable, and no requests failed. Metrics related to delays (connection time, waiting time) were within acceptable limits, and the system maintained a response time under 500ms for most requests. This indicates that the system can handle high loads over short periods without encountering issues.