Daily streaming scenarios
This page gives concrete, runnable load test scenarios for the most common streaming use cases. Each scenario describes the load shape, how to configure it in MaxoPerf, what to watch in the results, and the failure modes to look for.
Before you start
Section titled “Before you start”- Read HLS and DASH manifest and segment testing for the core player simulation pattern all scenarios build on.
- Read Concurrent viewers load for the segment rate math.
Scenario 1: Live sports kickoff
Section titled “Scenario 1: Live sports kickoff”What it tests: The simultaneous viewer surge when a live sporting event starts — cold CDN caches, origin segment delivery under stress, and manifest server connection spike.
Load shape: Very fast ramp (30–60 seconds) to peak concurrency, then a 90-minute plateau with a natural late-viewer trickle during halftime.
How to run in MaxoPerf:
- Create a new test targeting your live HLS/DASH manifest and segment URLs.
- Set VU count to your peak concurrent viewer target (e.g., 25,000).
- Set ramp-up to 30 seconds — this is the distinguishing parameter for a kickoff spike vs a VOD load test.
- Set hold duration to 90 minutes to cover a full match.
- Add a second execution stage in Taurus (or a k6 stage) that drops 10–20% of VUs after the first 45 minutes to model halftime drop-off and then returns to near-peak for the second half.
- Choose runner regions matching your event’s viewer geography.
- Set failure criteria: segment p95 < segment_duration_ms, error rate < 0.5%.
- Run the test during a maintenance window — live infrastructure may not have burst capacity available otherwise.
What to watch:
- Segment p95 during the first 3 minutes (CDN cold window) — spikes here predict viewer buffering at kickoff.
- Manifest latency plateau (stays high throughout) — indicates manifest server is a sustained bottleneck.
- Error rate spike at kickoff, then recovery — normal if CDN autoscales and clears within 2–3 minutes; abnormal if errors persist.
Key failure modes:
- CDN origin overwhelmed during cold-cache surge (first 2–4 minutes).
- Manifest server connection exhaustion from 25,000 simultaneous polling viewers.
- License server saturation if DRM is used.
Scenario 2: Premiere / episode drop
Section titled “Scenario 2: Premiere / episode drop”What it tests: A scheduled VOD content release — all viewers arrive within a short window after the content goes live, with significant social amplification driving a secondary wave.
Load shape: Moderate ramp (2–3 minutes) to peak, then a 30–60 minute sustained plateau as viewers complete the episode, followed by a second smaller peak driven by social sharing 60–90 minutes after release.
How to run in MaxoPerf:
- Create a VOD test targeting the premiere episode manifest and segment URLs.
- Set VU count to peak estimate (typically 5–15% of your total subscriber base for a major premiere).
- Set ramp-up to 2 minutes — premiere releases have a faster ramp than typical VOD but slower than a live sports kickoff.
- Set hold to episode_duration + 30 minutes (e.g., 90 minutes for a 60-minute episode).
- Add a secondary wave in a second execution block: reduce to 60% VU count after the initial peak, then ramp back up to 80% at the 90-minute mark to model the social sharing wave.
- Include a VarioTest or multi-scenario test if the platform serves multiple episodes simultaneously (series binge scenario).
What to watch:
- CDN segment delivery during the initial VOD burst (first 5–10 minutes while caches warm).
- Manifest server behavior — for VOD, the master manifest is fetched once at start; high p95 manifest latency impacts startup time for all viewers.
- Segment p95 after cache warm — should drop to steady state within 5–10 minutes for VOD.
Key failure modes:
- Content packaging pipeline overwhelmed if content is being transcoded/packaged in real time at release.
- Origin database or metadata service saturation during entitlement checks at session start.
Scenario 3: 24/7 linear soak
Section titled “Scenario 3: 24/7 linear soak”What it tests: Sustained concurrent viewer load on a 24/7 linear channel — whether your CDN, manifest server, and packaging infrastructure hold steady over many hours.
Load shape: Gradual ramp to target concurrency (5–10 minutes), then a flat hold for 4–8 hours. This is a soak test.
How to run in MaxoPerf:
- Create a test with your linear channel’s live HLS or DASH manifest URL.
- Set VU count to your average concurrent viewer count for the channel.
- Set ramp-up to 5 minutes.
- Set hold duration to 4–8 hours (align with your soak test policy — see Test types: soak test).
- Include variant playlist re-fetch in the scenario loop (every segment interval) — critical for live linear streams.
- Set alerting thresholds in MaxoPerf failure criteria: fail if error rate exceeds 0.1% for more than 5 consecutive minutes, or if segment p95 exceeds segment duration for more than 3 minutes.
What to watch:
- Gradual memory growth or latency drift in the manifest server (common in long-running live packaging services).
- CDN cache-hit ratio drifting — some CDN configurations have TTL issues that cause increased origin load over time.
- Segment error rate baseline — linear channels can have ingest interruptions that appear as segment 5xx errors; distinguish these from load-induced errors.
Key failure modes:
- Manifest server memory leak causing gradual latency rise over hours.
- CDN object expiry policy mismatches that increase origin requests after a fixed interval.
- Packaging worker saturation during long continuous runs.
Scenario 4: Regional CDN failover
Section titled “Scenario 4: Regional CDN failover”What it tests: What happens when a CDN PoP or region fails and all traffic routes through surviving regions — whether origin can absorb the increased load during failover.
Load shape: Baseline load across multiple regions, then a simulated “PoP failure” by concentrating load in one region at 150–200% of normal per-region load.
How to run in MaxoPerf:
- Create a multi-region test with baseline VU counts distributed across 3–4 regions (e.g., 3,000 VUs each across US-EAST, EU-WEST, AP-SOUTH).
- Run a first test as baseline to establish normal per-region latency.
- Run a second test simulating PoP failure: double the VU count in one region (to 6,000), drop another region to 0 VUs. This models all traffic that was hitting the failed PoP now routing to a single surviving region.
- Compare results — segment p95 in the surviving region will rise as CDN capacity is strained.
- Run for 20–30 minutes to observe autoscaling behavior in your CDN and origin.
What to watch:
- Segment p95 in the surviving regions — does it stay below segment duration during peak failover load?
- CDN origin hit rate rising — failover causes more cache misses as traffic patterns change.
- Recovery latency — how long before latency returns to baseline after the failing region is restored?
Key failure modes:
- Single surviving region’s CDN capacity is insufficient for consolidated traffic.
- Origin autoscaling trigger thresholds are too slow to compensate for the sudden load increase.
- DNS TTL or CDN failover routing takes too long, causing prolonged viewer disruption.
Scenario 5: Ad insertion peak
Section titled “Scenario 5: Ad insertion peak”What it tests: The concurrent request spike that occurs at ad break boundaries — when every viewer simultaneously pauses content, fetches an ad manifest, plays ad segments, then resumes content.
Load shape: Sustained content playback load, then a synchronized spike (all VUs simultaneously switch from content segments to ad manifest + ad segments) at the ad break boundary, then return to content.
How to run in MaxoPerf:
- Model the scenario as a two-phase request sequence: content segments → ad manifest + ad segments → content segments.
- Use
think-timeto synchronize all VUs at the ad break boundary: add a fixed think-time pause before the ad manifest request. In Taurus, all VUs executing the same scenario step simultaneously creates the desired synchronized spike. - Set VU count to your peak content concurrency (this is your peak ad break load).
- For SSAI (server-side ad insertion), the ad manifest is stitched into the content manifest — test the stitched manifest endpoint under load. For CSAI (client-side), test the VAST/VMAP ad manifest endpoint separately.
scenarios: ad-insertion-viewer: requests: # Content playback phase - label: content-segment url: https://cdn.example.com/content/720p/seg-0001.ts method: GET - label: content-segment url: https://cdn.example.com/content/720p/seg-0002.ts method: GET think-time: 4s - label: content-segment url: https://cdn.example.com/content/720p/seg-0003.ts method: GET think-time: 4s
# Ad break boundary — all VUs hit this simultaneously - label: ad-manifest-vast url: https://ads.example.com/v1/vast?content_id=event-final&slot=mid1 method: GET - label: ad-segment url: https://ad-cdn.example.com/ad/720p/ad-seg-0001.ts method: GET - label: ad-segment url: https://ad-cdn.example.com/ad/720p/ad-seg-0002.ts method: GET think-time: 4s
# Return to content - label: content-segment url: https://cdn.example.com/content/720p/seg-0004.ts method: GET - label: content-segment url: https://cdn.example.com/content/720p/seg-0005.ts method: GET think-time: 4sWhat to watch:
ad-manifest-vastp95 latency spike at the synchronized ad break boundary.- Ad segment CDN performance — ad delivery CDN may have different SLA and capacity than content CDN.
- Content segment latency after the ad break — confirms origin and CDN recover after the ad spike.
Key failure modes:
- Ad server (VAST/VMAP endpoint) cannot handle all concurrent viewers requesting ad manifests in the same second.
- SSAI stitching service crashes when it must stitch ad content for all concurrent viewers simultaneously.
- Ad CDN is undersized relative to content CDN — ad delivery SLAs differ from content.
Where to go next
Section titled “Where to go next”- Live event streaming load — detailed configuration for kickoff spikes with LL-HLS/LL-DASH specifics.
- Concurrent viewers load — segment request math to size your VU counts correctly.
- DRM and token auth testing — adding auth layers to any scenario.
- Test types: soak test — soak test patterns for the 24/7 linear scenario.
- Test types: spike test — spike test patterns applicable to kickoff and ad-break scenarios.