Replay Production Traffic for Realistic Load Testing

GoReplay can record HTTP requests and replay the captured mix against a test environment. This helps exercise request shapes that a scripted workload may miss. You still need to define the load objective, prepare target state and measure what the target actually receives.

Use replay for a known captured workload; use scripted journeys when you need to generate new behavior or correlate values from one response into a later request. A useful test can combine both approaches. TCP connection grouping and application sessions are different requirements.

How to Set Up Traffic Replay

What You Need for Setup

Choose an accessible plaintext HTTP capture point, a bounded sample, storage sized for that sample, and an isolated target. For HTTPS, locate the HTTP leg after TLS termination; a re-encrypted upstream is still encrypted. Follow capture permissions and interfaces and HTTPS setup.

Size from observations: captured bytes per second, sample duration, replay concurrency and target capacity. There is no universal minimum CPU count, disk size or retention period for a GoReplay test.

Keeping Data Secure and Staying Compliant

Define field transformations before collecting sensitive traffic. Account for headers, paths, queries and bodies. Method filtering alone does not remove credentials or make an endpoint side-effect free. Prepare the candidate’s databases, payment/email integrations and other downstream dependencies before replay.

Recommended Tools for Traffic Replay

Use GoReplay for request delivery, your application’s assertions for correctness, and your existing metrics stack for server behavior. The local exercise demonstrates why replay completion and a correct application outcome need separate checks.

How to Replay Production Traffic

Recording and Storing Traffic

This is a source-reviewed setup example, not an executed capture test. It uses a fresh directory, one explicit output filename and finite time limits:

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

# Inspect the sample and apply the transforms required by your application.
gor --input-file "$capture_dir/requests.gor" \
  --output-http http://staging.example.com --exit-after 30s

The time limit may stop a pass before every request or response finishes. Record attempted, received, completed and failed requests separately. The file replay documentation explains storage and replay options.

Replaying Traffic in Test Environments

Start with a small sample at recorded timing. Check whether target data, credentials, tokens and identifiers still make sense. Then run the same sample against a baseline build and candidate under comparable conditions. Reset state when an earlier pass would otherwise change the next one.

A file is not a complete regression test. Define allowed differences, expected responses and state changes. Record and replay testing covers those checks and CI boundaries.

Adjusting Traffic Volume and Load

An input percentage such as --input-file "requests.gor|200%" compresses recorded scheduling gaps. It does not promise twice the achieved RPS or preserved request-completion order. Generator resources, queues, target latency and output settings affect the observed result.

For staged tests, choose a small initial rate, a finite duration and explicit stop criteria. Record actual arrivals and completions at each stage. Consult load-test types and the planning checklist before increasing demand.

Tips for Better Traffic Replay

Keeping Data Accurate

Keep method/path mix, payload-size distribution, timestamps and request identity visible in the test record. Describe any filtering or rewriting that changes them. PRO’s documented TCP-session recognition is separate from authentication, cookies and business-state correlation; see session testing.

Tracking Results During Replay

Question	Evidence to collect
Did the candidate see the intended workload?	Arrivals by endpoint/method, bytes, attempted and completed requests
Is it slower than the baseline?	Comparable latency distributions by endpoint and outcome; target and generator resource measurements
Did behavior change?	Status/body assertions and resulting application state
Does a rate-limit policy work?	Documented key and quota, allowed/blocked outcomes, reset behavior and retry effects

A mixed replay can supply requests for a rate-limit test, but it does not by itself prove which user or tenant each request represents. Prepare the test identities and define the policy-specific expected result. Choose thresholds from your application’s requirements, not generic percentages.

Common Mistakes to Avoid

Do not confuse a scheduled replay rate with achieved throughput, a TCP connection with a signed-in user, or an exit code with a passing application test. Preserve failure observations as well as successful responses.

Advanced Uses and Custom Options

Using GoReplay for Live Traffic Shadowing

Shadow testing sends a copy to a candidate while the original service continues responding to users. Capture still consumes resources, and candidate requests can trigger downstream effects. Define isolation and comparison independently of traffic delivery.

Adding Traffic Replay to CI/CD Pipelines

The synthetic file exercise is a small reproducible starting point. Save and inspect it, then follow its usage instructions with an installed GoReplay binary. The saved September 8 check used three synthetic inputs: two GETs reached the local target with expected 200/422 responses; one POST was excluded. That check covered filtering and local replay, not raw capture, load capacity, TLS or PRO sessions.

For your CI job, replace those toy assertions with checks for the selected application’s contract. Store the test fixture, transformation rules, target build and results together.

Customizing Traffic with Middleware

Use rewriting and middleware for application-specific request changes and response processing. A recorded token may expire; decide whether to refresh it, replace it with a test identity, or exclude the request. Confirm that the transformed workload still tests the behavior you care about.

Final Thoughts and Suggestions

Select a concrete question, save a bounded workload, verify what reached the target, and inspect the application’s outcome. Start with the load-testing checklist, or follow the replay test guide for a CI-oriented workflow.