cloudthinker-ai Load Test Plan Skill
Design and execute load testing for {{ service_name }} targeting {{ target_rps }} RPS.
Workflow
Step 1 — Test Objectives
Define what this load test will validate:
TEST OBJECTIVES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Target: {{ service_name }}
Target RPS: {{ target_rps }}
Duration: {{ test_duration | "30 minutes" }}
Goals:
[ ] Validate service handles {{ target_rps }} RPS within SLO
[ ] Identify performance bottlenecks before they hit production
[ ] Establish performance baseline for regression detection
[ ] Determine maximum throughput before degradation
[ ] Validate autoscaling behavior under load
Success criteria:
- P95 latency: < ___ms
- P99 latency: < ___ms
- Error rate: < ___%
- Throughput: ≥ {{ target_rps }} RPS sustained
Step 2 — Test Scenarios
SCENARIO DESIGN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Scenario 1 — Baseline (current production traffic)
- RPS: [current production average]
- Duration: 10 minutes
- Purpose: Capture baseline metrics
Scenario 2 — Target Load
- RPS: {{ target_rps }}
- Duration: {{ test_duration | "30 minutes" }}
- Ramp-up: 5 minutes linear ramp
- Purpose: Validate target capacity
Scenario 3 — Peak Load (2x target)
- RPS: [2x {{ target_rps }}]
- Duration: 15 minutes
- Purpose: Find breaking point and validate graceful degradation
Scenario 4 — Stress Test (ramp to failure)
- RPS: Ramp from {{ target_rps }} to max, +10% every 2 minutes
- Purpose: Determine absolute maximum throughput
Scenario 5 — Soak Test (optional)
- RPS: {{ target_rps }}
- Duration: 2-4 hours
- Purpose: Detect memory leaks, connection pool exhaustion
Step 3 — Test Configuration
REQUEST PROFILE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| Endpoint | Method | Weight | Payload |
|----------|--------|--------|---------|
| [path] | GET | 60% | - |
| [path] | POST | 25% | [size] |
| [path] | PUT | 10% | [size] |
| [path] | DELETE | 5% | - |
Test data:
[ ] Test user accounts provisioned
[ ] Test data seeded in database
[ ] Authentication tokens pre-generated
[ ] Request payloads prepared (realistic size/complexity)
Environment:
[ ] Test environment isolated from production
[ ] Test environment matches production spec (or scaled proportionally)
[ ] Load generators provisioned in same region as target
[ ] Monitoring dashboards configured
Step 4 — Pre-Test Checklist
PRE-TEST
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Stakeholders notified of test window
[ ] Target service team aware and monitoring
[ ] Baseline metrics captured (before test)
[ ] Rate limiters adjusted or bypassed for test traffic
[ ] Autoscaling verified (or fixed replica count for controlled test)
[ ] Test script dry-run successful (low RPS sanity check)
[ ] Kill switch ready to stop test immediately
[ ] Database capacity sufficient for test data volume
Step 5 — Execution & Monitoring
DURING TEST — MONITOR
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Service metrics:
[ ] Request rate (actual vs target)
[ ] Error rate (by status code: 4xx, 5xx)
[ ] Latency (P50, P95, P99)
[ ] Throughput (successful requests/sec)
Infrastructure metrics:
[ ] CPU utilization (per instance and aggregate)
[ ] Memory utilization
[ ] Network I/O
[ ] Disk I/O (if applicable)
Dependency metrics:
[ ] Database query time and connection pool usage
[ ] Cache hit ratio and latency
[ ] External API response time
[ ] Message queue depth (if applicable)
ABORT CRITERIA:
[ ] Error rate > 10% for > 2 minutes
[ ] Service becomes unresponsive
[ ] Downstream services impacted
[ ] Data corruption detected
Step 6 — Results Analysis
RESULTS TEMPLATE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| Metric | Baseline | Target Load | Peak Load | SLO | Status |
|--------|----------|------------|-----------|-----|--------|
| RPS achieved | ___ | ___ | ___ | {{ target_rps }} | PASS/FAIL |
| P50 latency | ___ms | ___ms | ___ms | ___ms | PASS/FAIL |
| P95 latency | ___ms | ___ms | ___ms | ___ms | PASS/FAIL |
| P99 latency | ___ms | ___ms | ___ms | ___ms | PASS/FAIL |
| Error rate | ___% | ___% | ___% | ___% | PASS/FAIL |
| Max CPU | ___% | ___% | ___% | 80% | PASS/FAIL |
| Max memory | ___% | ___% | ___% | 80% | PASS/FAIL |
Breaking point: ___ RPS (where error rate > 1% or P95 > SLO)
Headroom: ___% above target RPS before degradation
Step 7 — Recommendations
Produce actionable recommendations:
- Bottlenecks identified: [resource, threshold, impact]
- Optimization opportunities: [specific tuning recommendations]
- Scaling recommendations: [infrastructure changes needed]
- Retest needed: [YES/NO, with specific scenarios]
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|---|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
Output Format
Produce a load test report with:
- Test configuration (scenarios, endpoints, traffic profile)
- Results table with metrics per scenario vs SLO
- Bottleneck analysis with graphs/data showing saturation points
- Recommendations prioritized by impact
- Comparison with previous test runs (if available)