Types of Load Testing: Objectives, Workloads, and Replay Examples

Choose a load test by the question you need to answer: can the service handle expected demand, survive a burst, remain stable over time, or meet its objectives at a larger scale? Then choose the request source and define how the result will be measured.

Synthetic scripts and recorded HTTP traffic are complementary sources. GoReplay can supply recorded requests to an isolated target. Your workload design, instrumentation and acceptance criteria turn that replay into a performance test.

Types of Load Testing

Terminology varies. For example, Grafana distinguishes stress and breakpoint tests, while Telerik’s load strategies group some objectives differently. Name the question and workload explicitly. The durations below describe how to choose a window; they are not universal test standards.

Stress Testing

Stress asks how the service behaves above its expected workload. Does a queue grow without bound? Do rejected requests trigger retries that increase demand? Does the system recover when the load drops? Establish a maximum duration and resource ceiling before starting. You can study overload without requiring a crash.

Soak Testing

Soak and endurance describe sustained testing over time. A short run can miss a connection leak or a scheduled task that slowly competes with requests. Choose a duration that includes the suspected behavior, monitor trends rather than only a final average, and account for cache warming or normal memory management.

Endurance Testing

Use the same sustained-load design as soak testing. Repeating a short file for several hours repeats that file’s data and endpoint mix; it does not create new users or new business scenarios. Check that the sample remains meaningful as tokens expire, records change and caches warm.

Spike Testing

A spike tests a fast workload transition and the recovery afterward. Keep a baseline before and after the burst so you can measure scaling delay, drained queues and restored latency. Starting separate replay processes at different speed factors can approximate stages, but process startup and queued requests affect the transition. Measure the actual arrival profile rather than assuming an ideal square wave.

Capacity Testing

Capacity is the load a specified configuration can sustain while meeting specified objectives. It is not another name for soak testing. Record instance counts, resource limits, dataset, request mix and the measured arrival/completion rates. The last passing plateau gives evidence for that configuration and workload, not an exact universal maximum or a count of supported users.

Breakpoint Testing

A breakpoint experiment searches for the boundary at which objectives fail. Increase load in controlled steps, investigate the bottleneck, and stop at predefined limits. The generator can saturate before the target does; distinguish a target limit from a test-harness limit. Retest any apparent boundary before using it for capacity planning.

Volume Testing

Vary the amount or distribution of stored data while keeping other inputs comparable. A search request against a small fixture and one against a large dataset can have different query plans and cache behavior. Sending a short capture faster changes request timing; it does not itself create the required dataset.

Throttle Testing

Specify what is constrained. Network throttling changes bandwidth or latency; an API quota test examines rate-limit responses and client retry behavior. A GoReplay input-file percentage changes the scheduling of requests. It does not emulate a slow client connection, inject network latency, or establish that the application enforces a quota.

Choose synthetic traffic, replay, or both

Use scripted traffic for deliberate new workflows, controlled parameter variation and cases that have not happened in production. Use recorded requests to exercise observed path, method and payload combinations. Compare those choices against the question you are testing rather than assuming either source is always more realistic.

A production capture can be unrepresentative, miss a rare path, contain stale credentials, or overrepresent one tenant. Filtering changes its mix. Repeating it can warm the same cache keys and mutate the same records. Document those limits and supplement the capture with explicit scenarios where necessary.

GoReplay file input schedules messages from recorded timestamp gaps. With --input-file "requests.gor|200%", those gaps are divided by two. That is not a guarantee of twice the achieved RPS, original completion order, or preserved application sessions. Workers, queues, the generator and the target affect observed traffic. The load-testing docs cover input speed and output options; PRO documentation identifies TCP-session recognition as a separate capability.

How to Conduct Load Testing

Practice the replay mechanics first

With Python 3.9+ and an installed GoReplay binary, save and inspect the local replay exercise, then run:

python3 replay-demo.py --gor /path/to/gor

The script creates synthetic file input, filters out a POST, saves the GETs using append mode, and replays them to a temporary loopback target. It asserts expected 200 and 422 observations and prints result: "passed" only when those checks pass. This is a small functionality exercise, not a load benchmark, packet-capture test or response-diff engine.

Capture a bounded, reviewed sample

Before capturing real traffic, select an authorized scope, configure required data transformations, and prepare a target with isolated downstream effects. Raw capture needs access to the interface and appropriate permissions. For HTTPS, capture an available plaintext leg after TLS termination; --input-raw does not decrypt TLS. See capture and HTTPS.

This command uses a fresh directory and records up to 30 seconds of GET requests:

capture_dir=$(mktemp -d)
sudo gor --input-raw :8080 --http-allow-method GET \
  --output-file "$capture_dir/requests.gor" --output-file-append \
  --exit-after 30s

The explicit append flag keeps one filename; default output uses indexed chunks. GET filtering is not sanitization and does not guarantee harmless behavior. Review the capture, and use filtering, rewriting or middleware for the actual requirements.

Run a finite rehearsal

Replace the example hostname with an isolated target you control. Start with a lower scheduling speed, loop the selected file, and end the run explicitly:

gor --input-file "$capture_dir/requests.gor|50%" \
  --input-file-loop --exit-after 30s \
  --output-http="http://staging.example.com"

--input-file-loop repeats the file; --exit-after bounds the process duration. The time limit may truncate a capture that takes longer to replay, or end a later pass before all its requests or responses complete. Record those incomplete results instead of treating them as successes. Thirty seconds is a rehearsal duration, not a soak-test recommendation.

For a controlled capacity investigation, use separately measured stages. This shell example makes three finite runs; the percentages are starting points to adapt after observing the target:

for speed in 50 100 200; do
  gor --input-file "$capture_dir/requests.gor|${speed}%" \
    --input-file-loop --exit-after 60s \
    --output-http="http://staging.example.com"
done

Monitor during each stage and stop early if your safety or failure threshold is reached. Allow the application to recover and reset data when the experiment requires it. This loop does not supply automatic SLO assertions, reset application state, or discover capacity by itself. It also does not make the same short capture suitable for every test type.

What to Measure During Load Testing

An HTTP response measurement is not browser rendering time. State whether latency is measured by the client, proxy or service, and keep that boundary consistent across runs. Report the request mix and counts with percentiles, especially when samples are small.

Best Practices for Load Testing

Write down the target configuration, dataset, sample source, workload shape, duration, acceptance criteria and stop conditions before running. Keep the same measurement definitions when comparing builds. Follow up an apparent regression with a reproducible investigation rather than attributing every difference to the code change.

Use the load-testing checklist to prepare the plan, file replay documentation for capture mechanics, and record and replay testing for application assertions and CI state management. A passing test supports the workload and conditions you measured; it does not guarantee production behavior outside them.