Stress Testing
Table of Contents
Overview
Stress testing pushes systems beyond normal operating capacity to identify breaking points, failure modes, and recovery behavior. It validates system stability under extreme conditions and helps determine maximum capacity before degradation or failure.
When to Use
- Finding system capacity limits
- Identifying breaking points
- Testing auto-scaling behavior
- Validating error handling under load
- Testing recovery after failures
- Planning capacity requirements
- Verifying graceful degradation
- Testing spike traffic handling
Quick Start
Minimal working example:
// stress-test.js
import http from "k6/http";
import { check, sleep } from "k6";
import { Rate } from "k6/metrics";
const errorRate = new Rate("errors");
export const options = {
stages: [
// Stress testing: Progressive load increase
{ duration: "2m", target: 100 }, // Normal load
{ duration: "5m", target: 100 }, // Sustain normal
{ duration: "2m", target: 200 }, // Above normal
{ duration: "5m", target: 200 }, // Sustain above normal
{ duration: "2m", target: 300 }, // Breaking point approaching
{ duration: "5m", target: 300 }, // Sustain high load
{ duration: "2m", target: 400 }, // Beyond capacity
{ duration: "5m", target: 400 }, // System under stress
{ duration: "5m", target: 0 }, // Gradual recovery
],
thresholds: {
http_req_duration: ["p(99)<1000"], // 99% under 1s during stress
http_req_failed: ["rate<0.05"], // Allow 5% error rate under stress
errors: ["rate<0.1"],
},
// ... (see reference guides for full implementation)
Reference Guides
Detailed implementations in the references/ directory:
| Guide |
Contents |
| k6 Stress Testing |
k6 Stress Testing |
| Spike Testing |
Spike Testing |
| Soak/Endurance Testing |
Soak/Endurance Testing |
| JMeter Stress Test |
JMeter Stress Test |
| Auto-Scaling Validation |
Auto-Scaling Validation |
| Breaking Point Analysis |
Breaking Point Analysis |
Best Practices
✅ DO
- Test in production-like environment
- Monitor all system resources
- Gradually increase load to find limits
- Test recovery after stress
- Document breaking points
- Test auto-scaling behavior
- Plan for graceful degradation
- Monitor for memory leaks
❌ DON'T
- Test in production without safeguards
- Skip recovery testing
- Ignore warning signs (CPU, memory)
- Test only success scenarios
- Assume linear scalability
- Forget database capacity
- Skip monitoring third-party dependencies
- Test without proper cleanup
1---2name: stress-testing3description: Test system behavior under extreme load conditions to identify breaking points, capacity limits, and failure modes. Use for stress test, capacity testing, breaking point analysis, spike test, and system limits validation.4---5
6# Stress Testing
7
8## Table of Contents
9
10- [Overview](#overview)
11- [When to Use](#when-to-use)
12- [Quick Start](#quick-start)
13- [Reference Guides](#reference-guides)
14- [Best Practices](#best-practices)
15
16## Overview
17
18Stress testing pushes systems beyond normal operating capacity to identify breaking points, failure modes, and recovery behavior. It validates system stability under extreme conditions and helps determine maximum capacity before degradation or failure.
19
20## When to Use
21
22- Finding system capacity limits
23- Identifying breaking points
24- Testing auto-scaling behavior
25- Validating error handling under load
26- Testing recovery after failures
27- Planning capacity requirements
28- Verifying graceful degradation
29- Testing spike traffic handling
30
31## Quick Start
32
33Minimal working example:
34
35```javascript
36// stress-test.js
37import http from "k6/http";
38import { check, sleep } from "k6";
39import { Rate } from "k6/metrics";
40
41const errorRate = new Rate("errors");
42
43export const options = {
44 stages: [
45 // Stress testing: Progressive load increase
46 { duration: "2m", target: 100 }, // Normal load
47 { duration: "5m", target: 100 }, // Sustain normal
48 { duration: "2m", target: 200 }, // Above normal
49 { duration: "5m", target: 200 }, // Sustain above normal
50 { duration: "2m", target: 300 }, // Breaking point approaching
51 { duration: "5m", target: 300 }, // Sustain high load
52 { duration: "2m", target: 400 }, // Beyond capacity
53 { duration: "5m", target: 400 }, // System under stress
54 { duration: "5m", target: 0 }, // Gradual recovery
55 ],
56 thresholds: {
57 http_req_duration: ["p(99)<1000"], // 99% under 1s during stress
58 http_req_failed: ["rate<0.05"], // Allow 5% error rate under stress
59 errors: ["rate<0.1"],
60 },
61// ... (see reference guides for full implementation)
62```
63
64## Reference Guides
65
66Detailed implementations in the `references/` directory:
67
68| Guide | Contents |
69|---|---|
70| [k6 Stress Testing](references/k6-stress-testing.md) | k6 Stress Testing |
71| [Spike Testing](references/spike-testing.md) | Spike Testing |
72| [Soak/Endurance Testing](references/soakendurance-testing.md) | Soak/Endurance Testing |
73| [JMeter Stress Test](references/jmeter-stress-test.md) | JMeter Stress Test |
74| [Auto-Scaling Validation](references/auto-scaling-validation.md) | Auto-Scaling Validation |
75| [Breaking Point Analysis](references/breaking-point-analysis.md) | Breaking Point Analysis |
76
77## Best Practices
78
79### ✅ DO
80
81- Test in production-like environment
82- Monitor all system resources
83- Gradually increase load to find limits
84- Test recovery after stress
85- Document breaking points
86- Test auto-scaling behavior
87- Plan for graceful degradation
88- Monitor for memory leaks
89
90### ❌ DON'T
91
92- Test in production without safeguards
93- Skip recovery testing
94- Ignore warning signs (CPU, memory)
95- Test only success scenarios
96- Assume linear scalability
97- Forget database capacity
98- Skip monitoring third-party dependencies
99- Test without proper cleanup