Video streaming do and don't

Streaming load tests have several failure modes that do not exist in REST API testing. A test that looks valid — it runs, it produces results, throughput looks plausible — can be completely wrong because of a missing sleep() or a misunderstood metric. This page collects the most impactful do/don’t rules from across the streaming testing section.

Do: fetch segments at real-time cadence

Every segment fetch must be followed by a pause equal to the segment duration. This is the single most critical rule in streaming load testing.

# Correct — real-time cadence
- label: segment
  url: https://cdn.example.com/stream/720p/seg-0002.ts
  think-time: 4s          # 4-second segment = 4-second wait

Without think-time, a single VU downloads segments as fast as the network allows — potentially 50–200 per second instead of 0.25 per second. Your “1,000 viewer” test is actually generating the load of 200,000+ viewers, maxing out your CDN or failing due to connection limits, while the results show nothing meaningful about viewer-scale behavior.

Don’t: fetch only the manifest

Testing only the master manifest endpoint is the most common streaming test mistake. It tests exactly one endpoint out of three (or more) in the player request chain. Segment delivery — the CDN object that must scale with every viewer — is completely untested.

A manifest-only test tells you nothing about:

• CDN segment delivery capacity
• Segment download time vs segment duration (the rebuffer gate)
• Origin segment packaging throughput
• Per-rendition delivery differences

Always implement the full player loop: master manifest → variant playlist → segment loop.

Do: label requests by type and rendition

Label every request so MaxoPerf can show per-label latency in the results breakdown:

requests:
  - label: master-manifest      # one label for manifest
    url: ...
  - label: variant-playlist-720p  # rendition-specific labels
    url: ...
  - label: segment-720p          # all 720p segments share this label
    url: ...

Without labels, all requests collapse into a single average that hides which part of the delivery chain is failing. The difference between a manifest server problem and a CDN segment problem is invisible in an unlabeled test.

Don’t: ignore the segment latency vs segment duration relationship

Raw millisecond latency numbers are not meaningful for streaming tests without comparing them to segment duration:

segment download time < segment duration → viewer does not buffer
segment download time ≥ segment duration → viewer buffers

A segment p95 of 3,200ms sounds fine. If the segment duration is 4,000ms, it is fine. If the segment duration is 2,000ms, 5% of your viewers are buffering on every segment.

Always configure failure criteria with segment duration as the threshold:

# In MaxoPerf test configuration
criteria:
  - p95(segment) > 4000ms for 2m: stop as failed  # 4s segment duration

Do: model the full viewer population with realistic rendition mix

Use multiple execution scenarios weighted to your actual viewer analytics data:

execution:
  - concurrency: 350    # 70% on 720p
    scenario: viewer-720p
  - concurrency: 100    # 20% on 1080p
    scenario: viewer-1080p
  - concurrency: 50     # 10% on 480p
    scenario: viewer-480p

If your test only uses the highest-quality rendition, each VU consumes 5–40× more bytes than an average viewer, which means you will either exhaust bandwidth limits at a fraction of your target viewer count, or your VU count underestimates the actual viewer concurrency needed to cause failure.

Don’t: use a slow ramp for live event tests

Live event kickoff spikes require a fast ramp — 30 to 90 seconds. A 5-minute ramp warms CDN caches progressively, hiding the cold-cache failure mode that happens when 15,000 viewers all arrive in the first minute:

# Wrong for live events — hides the kickoff failure mode
- concurrency: 10000
  ramp-up: 5m

# Correct for live events
- concurrency: 10000
  ramp-up: 30s          # model the actual kickoff spike

Do: include manifest re-fetch in live stream scenarios

For live HLS/DASH, viewers re-fetch the variant playlist every segment interval to discover new segments. At 10,000 concurrent viewers with 4-second segments, this adds 2,500 manifest requests per second — a significant load on the manifest server that your test must include.

# After every N segments in a live scenario, re-fetch the variant playlist
- label: variant-playlist-refresh
  url: https://live.example.com/stream/720p/playlist.m3u8
  method: GET

Don’t: hard-code tokens or credentials in test files

Use MaxoPerf secrets for all auth tokens, API keys, and signing credentials. Hard-coded tokens in test files create security risk if files are shared or committed, and they make credential rotation require test file edits rather than a single secrets update.

Do: run multi-region tests to catch edge PoP differences

MaxoPerf distributes VUs across runner regions. Use multiple regions to exercise different CDN edge nodes:

• A segment that is fast from EU-WEST may be slow from AP-SOUTH because that edge PoP is cold or under-sized.
• Multi-region tests catch geographic SLA differences before real viewers report them.

Don’t: treat error rates under 1% as acceptable without inspection

In REST API tests, a 0.5% error rate is typically worth investigating but might be acceptable. In streaming tests, a 0.5% segment error rate means 0.5% of every viewer’s segments fail — which means every viewer experiences approximately one buffering event per 800 segments (about 53 minutes at 4-second segments). That may or may not be acceptable depending on your SLA, but it should always be understood, not dismissed.

Inspect the Errors tab after every streaming run. Look for:

Error pattern	Likely cause
Segment 403 at scale	Token expiry, CDN auth rule, or key rotation issue
Segment 404 at scale	Segment not yet packaged, storage misconfiguration
Segment 5xx	Origin overwhelmed — autoscaling insufficient
Segment timeouts	CDN connection capacity exhausted
Manifest 429	Manifest server rate-limiting concurrent sessions

Do: run a QoE-gated soak test for 24/7 linear channels

Linear streaming infrastructure must sustain constant load for hours or days. Latency drift (gradual rise over time) indicates memory leaks or resource exhaustion in packaging services. A short 30-minute test will never reveal these patterns — run at least a 4-hour soak with failure criteria monitoring for gradual p95 drift:

criteria:
  - avg-rt of segment > 3000ms for 10m: stop as failed  # gradual drift gate

Where to go next

• HLS and DASH manifest and segment testing — the base player simulation pattern.
• Startup time and rebuffering QoE — the QoE metric relationships explained in depth.
• Concurrent viewers load — segment request rate math and multi-region configuration.
• Daily streaming scenarios — complete runnable scenarios for each streaming use case.