k6 Load Testing Framework Comprehensive setup for k6 load testing. Includes smoke, load, stress, soak, spike, and breakpoint tests to evaluate performance, scalability, and reliability of web apps and APIs. Automate performance tests and monitor key metrics like response time and throughput.
# k6 Load Testing Documentation
## 1. Installation of k6
To install **k6** for load testing, follow the instructions for your operating system:
### For **Windows**:
1. **Install via Windows Package Manager**:
Open **PowerShell** and run:
```bash
winget install k6
-
Manual Installation:
- Go to the k6 Releases page.
- Download the Windows binary (
k6-vX.X.X-amd64.msi
). - Run the installer and follow the instructions.
-
Install via Homebrew: Run the following command in Terminal:
brew install k6
-
Manual Installation:
- Go to the k6 Releases page.
- Download the macOS binary (
k6-vX.X.X-darwin-amd64.tar.gz
). - Extract the archive and move
k6
to/usr/local/bin/
.
-
Install via Package Manager:
-
Debian/Ubuntu:
sudo apt update sudo apt install k6
-
-
Manual Installation:
- Go to the k6 Releases page.
- Download the Linux binary (
k6-vX.X.X-linux-amd64.tar.gz
). - Extract and move
k6
to/usr/local/bin/
.
After installation, verify it with the command:
k6 version
Load testing is essential to assess the performance of a system under normal and peak load conditions. The primary objectives are:
- Identify system bottlenecks: Load testing helps detect performance issues such as slow response times and failed transactions during high load.
- Validate scalability: It ensures the system can handle increasing traffic or load, such as more users or requests.
- Ensure reliability and stability: Load testing confirms that the system can perform consistently under expected and unexpected loads, preventing crashes and downtime.
- Capacity planning: It helps understand the system's limits, which aids in future resource allocation for handling peak traffic.
- Purpose: Verify that basic functionality works and that the system handles minimal load.
- Duration: Short (seconds or minutes).
- When to Use: After changes in the system or application code to check for critical issues or breakages.
- Purpose: Assess system performance under expected normal conditions (average load).
- Duration: Medium (5-60 minutes).
- When to Use: During routine performance checks to ensure the system handles typical usage without significant delays or failures.
- Purpose: Push the system to its limits by applying loads greater than the expected average, to test how it reacts under extreme conditions.
- Duration: Medium (5-60 minutes).
- When to Use: To evaluate system robustness and identify how the system performs when under heavy traffic or unexpected spikes.
- Purpose: Assess system performance over prolonged periods, identifying issues such as memory leaks, resource depletion, or system slowdowns.
- Duration: Long (hours).
- When to Use: After making changes to the system to evaluate stability and reliability over time.
- Purpose: Simulate sudden and massive increases in traffic to see how the system performs during quick spikes.
- Duration: Short (a few minutes).
- When to Use: For systems that may experience seasonal or traffic bursts (e.g., e-commerce websites during sales events).
- Purpose: Gradually increase the load until the system reaches its capacity limit to find the point of failure.
- Duration: Variable, depending on the system.
- When to Use: When you need to identify the maximum capacity and failure thresholds of your system.
Based on the current k6 load test script, the following scenarios and their respective durations are calculated:
- Duration: 30 seconds
- Virtual Users (VUs): 1
- Duration: 5 minutes (300 seconds)
- Virtual Users (VUs): 50
- Duration: 10 minutes (600 seconds)
- Virtual Users (VUs): Starts at 50 and ramps up to 200.
- Duration: 2 hours (7,200 seconds)
- Virtual Users (VUs): 20
- Duration: 1 minute (60 seconds)
- Virtual Users (VUs): 100
- Duration: 35 minutes (2,100 seconds)
- Virtual Users (VUs): Starts at 10 and ramps up in stages.
To calculate the total time required to complete all scenarios:
- Smoke Test: 30 seconds
- Load Test: 300 seconds
- Stress Test: 600 seconds
- Soak Test: 7,200 seconds
- Spike Test: 60 seconds
- Breakpoint Test: 2,100 seconds
Total Duration = 30s + 300s + 600s + 7,200s + 60s + 2,100s = 9,690 seconds = 2 hours, 41 minutes, and 30 seconds.
- Response Time: Track the time it takes to serve requests.
- Throughput: The number of requests served per unit of time.
- Error Rate: The percentage of requests that fail.
By observing these metrics during your tests, you can gain insights into your system's performance and identify areas for improvement.
Type | VUs/Throughput | Duration | When? |
---|---|---|---|
Smoke | Low | Short (seconds or minutes) | When the relevant system or application code changes. It checks functional logic, baseline metrics, and deviations. |
Load | Average production | Mid (5-60 minutes) | Often to check system maintains performance with average use. |
Stress | High (above average) | Mid (5-60 minutes) | When system may receive above-average loads to check how it manages. |
Soak | Average | Long (hours) | After changes to check system under prolonged continuous use. |
Spike | Very high | Short (a few minutes) | When the system prepares for seasonal events or receives frequent traffic peaks. |
Breakpoint | Increases until break | As long as necessary | A few times to find the upper limits of the system. |
By using k6 to run various load testing scenarios, you can evaluate the performance, scalability, and reliability of your system under different conditions. Understanding how your system behaves under stress and load is essential for optimizing its performance and ensuring it can handle real-world traffic efficiently.
### How to Use the Markdown File:
1. Copy the content above into a file named `k6_load_testing_guide.md`.
2. Upload this Markdown file to your **GitHub** repository to share the load testing setup and scenarios.
3. You can also view this file in any **Markdown viewer** (like **VS Code** or **GitHub**).
Let me know if you need any adjustments or further enhancements!