6 load testing patterns and what they reveal
A practical guide to choosing the right traffic curve in Gatling, grouped into validation, scaling, and resilience.
Get the full datasheet in your inbox
All 6 patterns, code snippets included, as a PDF for your team.
Injection components reference
This datasheet focuses on open workload models (user arrival rate). For closed workload guidance and examples, reach out to us.
Validation
Smoke test
Minimal traffic to verify scenario correctness and environment readiness before scaling.
One immediate user arrival. Used for fast validation, not for performance measurement.
When to use it
- checkValidate test setup end-to-end (authentication, routing, data, dependencies)
- checkSanity-check pre-merge or pre-pipeline before heavier tests
- checkConfirm telemetry wiring (metrics visible, dashboards populated, traces available)
What it reveals
- insightsImmediate functional failures (unauthorized responses, server errors, timeouts)
- insightsEnvironment misconfiguration (domain name resolution, credentials, routing rules)
- insightsMissing instrumentation or broken telemetry before load
Ramp-hold test
Ramp to a target arrival rate, then hold steady to validate performance and service level compliance under stable peak conditions.
Ramp from 0 to vu users per second over ramp_duration, then hold at vu users per second for duration.
When to use it
- checkRelease validation or continuous integration performance gating
- checkConfirm service level objectives at expected peak traffic
- checkCompare baseline vs new release under identical traffic shape
What it reveals
- insightsRamp behavior vs steady-state behavior (warm-up, scaling stabilization)
- insightsWhether performance stabilizes or continues degrading under constant load
- insightsRegression signals compared to previous baseline runs
Scaling
Capacity test
A stepwise traffic increase with stabilized plateaus to measure sustainable throughput and identify scaling limits.
Progressively increase the arrival rate in steps, holding each level long enough for the system to stabilize and reveal sustainable throughput limits.
When to use it
- checkValidate expected peak traffic under controlled increments
- checkMeasure scaling behavior (automatic scaling, resource saturation, throughput ceilings)
- checkEstablish a repeatable capacity baseline to compare releases or infrastructure changes
What it reveals
- insightsThe traffic level where latency percentiles (p95 and p99) start diverging
- insightsThroughput ceilings and early saturation thresholds (CPU, queues, connection pools, load balancers, gateways)
- insightsNon-linear scaling zones (automatic scaling delays, contention, backlog accumulation)
Breakpoint test
A continuous ramp-up to determine the traffic threshold where service level objectives break and the system loses stability.
Linear ramp from 0 to vu users per second over duration. Often paired with automatic stop criteria (error rate thresholds, percentile thresholds, time limits).
When to use it
- checkFind the maximum sustainable arrival rate (true capacity limit)
- checkQuantify headroom and define a safe operating range
- checkValidate infrastructure ceilings such as load balancers, gateways, and database connection limits
What it reveals
- insightsThe load level where service level objectives fail (p99 spikes, errors increase, throughput collapses)
- insightsWhich layer saturates first (edge, gateway, service, or dependency)
- insightsWhether automatic scaling can delay or prevent failure
Resilience
Stress test
Sustained high arrival rate to push the system beyond normal operating conditions and expose failure modes under overload.
Sustained peak traffic at vu users per second for duration. Designed to force saturation and observe failure behavior.
When to use it
- checkValidate resilience beyond expected peak traffic
- checkObserve failure behavior: error cliffs, timeouts, and recovery dynamics
- checkTest protective mechanisms such as rate limiting, backpressure, and circuit breakers
What it reveals
- insightsTail latency explosions (p99 and p99.9) caused by contention and queueing
- insightsError cliffs and timeout cascades caused by retries and overload
- insightsStability limits under sustained saturation (CPU, database connections, network throughput)
Soak test
A constant arrival rate sustained over time to validate stability and detect slow degradation.
Constant traffic at vu users per second for the full duration.
When to use it
- checkDetect memory leaks or slow resource exhaustion
- checkValidate long-run stability under steady business-as-usual traffic
- checkIdentify drift caused by cache eviction, background jobs, or state accumulation
What it reveals
- insightsLatency drift and tail degradation over time
- insightsSlow-growing error rates and saturation trends
- insightsResource growth patterns leading to collapse (memory pressure, connection pool exhaustion)
Each pattern answers a different question
Use this table as a shortcut: each test pattern reveals a different class of failure modes, scaling limits, or stability risks.
| Test type | Main question | Common duration | When to perform | Key outputs |
|---|---|---|---|---|
| Smoke | Does the scenario run end-to-end? | 15–30 min | Before any serious performance testing | Setup errors, broken flows, missing dependencies |
| Ramp-Hold | Do service level objectives hold at peak? | 30 min | Before production releases / after major updates | p95 / p99, error rate, steady-state stability |
| Capacity | What is the maximum sustainable traffic? | Several hours (until failure) | Before scaling decisions / infrastructure changes | Throughput ceiling, saturation thresholds, scaling behavior |
| Breakpoint | At which traffic level do we break? | 1 hour | Before a known high-traffic event / product launch | Failure threshold, first saturated layer, safe operating range |
| Stress | How does the system behave under overload? | 2–3 hours | Before a known high-traffic event / product launch | Error cliffs, timeout cascades, recovery behavior |
| Soak | Does performance degrade over time? | 24–72 hours | Before production / after major updates | Drift, leaks, long-run degradation patterns |
Built to test any use case or protocol, at scale
Gatling Enterprise Edition is a developer-first load testing platform for modern, high-scale systems. It supports APIs, microservices, real-time protocols, and legacy tech across HTTP, WebSockets, gRPC, and more.
Web applications
Simulate user interactions and ensure fast, reliable front-end performance under load.
Public and private APIs
Validate your API performance, latency, and error handling across high concurrency.
Cloud-based infrastructures
Evaluate performance and resiliency of cloud-native apps, especially after migrations from on-premise.
SQL databases
Measure query response times and throughput under real-world usage scenarios.
Microservices architectures
Test internal service-to-service communication and isolate performance bottlenecks.
IoT systems and protocols
Emulate device fleets and message flows using MQTT, AMQP, and other IoT protocols.
Mobile applications
Reproduce mobile usage patterns and variable network conditions for realistic testing.
LLM and AI-powered APIs
Evaluate AI inference latency and ensure consistent performance for high-volume requests.
Ready to evaluate Enterprise Edition?
Whether you're scaling APIs, migrating to the cloud, or handling flash-traffic spikes, Gatling helps you deliver fast, reliable performance.