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