Load Testing for Latency-Sensitive Live Streaming

Load test a live stream the way viewers watch it

A live viewer is a loop: fetch the playlist every few seconds, fetch the newest segment, play it, repeat. Latency matters twice: a slow segment stalls playback, and a slow playlist drifts every viewer further behind live. This template runs that loop for thousands of viewers from several regions and measures the two requests that decide whether the stream stalls: playlist refresh and segment download.

Configuration

Run this templateOpens the cloud test form with these values filled in. Free plan runs it at the free user limit; sign in or create a free account first.

The button prefills viewers, duration and ramp-up. Add the playlist URL and a segment URL pattern, set the think time to your segment length, pick the regions and start. Point it at a test stream: 2,000 viewers on a real event is real bandwidth.

What to read in the results

• Segment download time by region. A segment must download faster than it plays. p95 above the segment length in any region means viewers there are stalling; compare regions to tell an edge problem from an origin problem.
• Playlist p95. Playlist requests are small and frequent. If their p95 climbs with viewers, the origin is serving them uncached, or the CDN TTL is shorter than the segment length.
• Errors and cache status. 404 on segments is the playlist advertising a segment before it exists (packager timing). 5xx from the origin at the top of the ramp is the CDN falling back to origin on every miss at once.

Pass/fail thresholds for this template

Save them on the test and rerun before each event with the expected audience size.

The same scenario as a k6 script

The viewer loop as a k6 script. It reads the media playlist, fetches the last segment it lists, and waits one segment length. Replace the URLs with your test stream.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [{ duration: '2m', target: 2000 }, { duration: '13m', target: 2000 }],
  thresholds: { 'http_req_duration{name:segment}': ['p(95)<2000'], http_req_failed: ['rate<0.002'] },
};

const PLAYLIST = 'https://live.example.com/event/index_720p.m3u8';
const SEGMENT_LENGTH = 4;

export default function () {
  const pl = http.get(PLAYLIST, { tags: { name: 'playlist' } });
  check(pl, { 'playlist 200': (r) => r.status === 200 });
  const lines = pl.body.split('\n').filter((l) => l && !l.startsWith('#'));
  const last = lines[lines.length - 1];
  if (last) {
    const seg = http.get(new URL(last, PLAYLIST).toString(), { tags: { name: 'segment' } });
    check(seg, { 'segment 200': (r) => r.status === 200, 'segment in time': (r) => r.timings.duration < SEGMENT_LENGTH * 1000 });
  }
  sleep(SEGMENT_LENGTH);
}

When to run it

• Before a ticketed or announced live event with the audience size you sold or forecast.
• After changing packager, segment length or CDN each changes the request pattern.
• After adding a region to confirm the edge there is warm and reachable.

FAQ on live streaming load testing

Does this test video quality?

No. It tests delivery: whether segments arrive in time from each region at the audience size. Rendering quality is a player concern; stalls caused by slow delivery are what this finds.

Should I test through the CDN or against the origin?

Through the CDN, from several regions, because that is where viewers are. Then read the origin’s own metrics during the run to see the miss rate the CDN passed through.

DASH instead of HLS?

Same loop with an MPD manifest and segment templates. The cloud test needs the manifest URL and a segment URL; the k6 script needs the manifest parsing swapped for the MPD format.

How much bandwidth does 2,000 viewers use?

Bitrate times viewers: a 3 Mbps rendition at 2,000 viewers is 6 Gbps at the edges. The load generators spread it across regions; your CDN bill sees all of it, so use a test stream.