Guide Load Testing Specialist

Performance engineering agent that designs, executes, and analyzes load testing scenarios to identify system bottlenecks, validate SLAs, and guide capacity planning decisions.

When to Use This Agent

Choose this agent when you need to:

• Design progressive load test plans from baseline through stress and soak testing phases
• Identify system breaking points and resource bottlenecks under concurrent user load
• Validate that infrastructure meets defined SLAs for response time, throughput, and error rate
• Generate capacity planning recommendations based on empirical load test data

Consider alternatives when:

• Your performance issues are specifically in React component rendering (use the React Performance Consultant)
• You are focused exclusively on Core Web Vitals metrics for end-user experience (use the Web Vitals Optimizer Agent)

Quick Start

Configuration

Copy
name: guide-load-testing-specialist
type: agent
category: performance-testing

Example Invocation

Copy
claude agent:invoke guide-load-testing-specialist "Design a load test plan for our checkout API targeting 500 concurrent users with p99 latency under 800ms"

Example Output

Load Test Plan — Checkout API
Target: 500 concurrent users, p99 < 800ms, error rate < 0.1%

Phase 1 — Baseline (5 min): 50 users, establish performance baseline
Phase 2 — Ramp (10 min): Linear ramp 50 → 500 users
Phase 3 — Steady State (15 min): Hold 500 users, measure SLA compliance
Phase 4 — Stress (10 min): Ramp to 750 users, identify breaking point
Phase 5 — Recovery (5 min): Drop to 50 users, verify system recovery

Resource Monitors: CPU, memory, DB connections, queue depth, network I/O
Bottleneck Detected: Database connection pool saturates at 420 concurrent users
Recommendation: Increase pool size from 20 to 50, add read replicas for catalog queries

Core Concepts

Load Testing Methodology Overview

Aspect	Details
Test Types	Baseline, load, stress, soak (endurance), spike, and breakpoint testing
Key Metrics	Throughput (req/s), latency (p50/p95/p99), error rate, resource utilization
User Modeling	Think time, session duration, transaction mix, geographic distribution
Infrastructure Scope	Application servers, databases, caches, message queues, CDNs, load balancers

Load Test Execution Architecture

┌─────────────────┐     ┌─────────────────┐
│  Scenario        │────▶│  Virtual User   │
│  Definition      │     │  Generator      │
└─────────────────┘     └─────────────────┘
        │                       │
        ▼                       ▼
┌─────────────────┐     ┌─────────────────┐
│  Load Profile    │────▶│  Target System  │
│  Controller      │     │  Under Test     │
└─────────────────┘     └─────────────────┘
        │                       │
        ▼                       ▼
┌─────────────────┐     ┌─────────────────┐
│  Resource        │────▶│  Results        │
│  Monitor Agent   │     │  Analyzer       │
└─────────────────┘     └─────────────────┘

Configuration

Parameter	Type	Default	Description
target_users	integer	100	Peak concurrent virtual users for the steady-state phase
ramp_duration	string	5m	Duration of the linear ramp-up period before steady state
steady_duration	string	15m	Duration to hold peak load for SLA measurement
sla_p99_latency	string	500ms	Maximum acceptable 99th-percentile response time
error_threshold	float	0.001	Maximum acceptable error rate (0.1% = 0.001) as a fraction

Best Practices

1. Establish a Reliable Baseline Before Scaling Up Run a low-concurrency baseline test first to capture nominal performance metrics. Without a clean baseline, you cannot distinguish between regressions introduced by load volume and pre-existing performance issues. Store baseline results as versioned artifacts alongside your test scripts.

2. Model Realistic User Behavior, Not Just Raw Throughput Real users pause between clicks, abandon carts, and follow varied navigation paths. Incorporating think times, session variability, and a realistic transaction mix produces load profiles that mirror production traffic far more accurately than uniform request floods.

3. Monitor Infrastructure Resources Alongside Application Metrics Application-level metrics (latency, error rate) tell you something is wrong; infrastructure metrics (CPU, memory, disk I/O, connection pools) tell you why. Always collect both simultaneously so you can correlate performance degradation with the specific resource constraint causing it.

4. Integrate Load Tests into CI/CD for Regression Detection Running abbreviated load tests on every deployment catches performance regressions before they reach production. Define a performance budget (e.g., p95 latency must not increase by more than 10% compared to baseline) and fail the pipeline when it is exceeded.

5. Test Recovery, Not Just Peak Performance A system that handles 500 concurrent users but fails to recover after a spike is not production-ready. Include a cooldown phase in every test plan and verify that latency, error rate, and resource utilization return to baseline levels within an acceptable time window.

Common Issues

1. Connection pool exhaustion under moderate load Database or HTTP client connection pools are frequently the first bottleneck. Symptoms include sudden latency spikes and timeout errors even when CPU and memory appear healthy. Monitor active connection counts during load tests and size pools based on observed peak concurrency plus a 20-30% headroom margin.

2. Coordinated omission skewing latency percentiles When a load generator waits for each response before sending the next request, slow responses reduce the actual request rate, hiding the true latency impact. Use open-loop or constant-rate load generators and apply coordinated omission correction (e.g., HdrHistogram) to get accurate percentile measurements.

3. Test environment not representative of production Undersized staging environments produce misleading results because bottlenecks appear at different thresholds than in production. Either scale your test environment to match production proportionally or apply a documented scaling factor when interpreting results, and always note the environment discrepancy in reports.