Load testing HLS with Ruby JMeter

Load testing video streaming using Ruby JMeter and Flood

In this post we're going to demonstrate how to test Apple's HTTP Live Streaming (HLS) using Ruby JMeter.


Real Time Messaging Protocol (RTMP) was initially a proprietary protocol for streaming audio, video and data over the Internet, between a Flash player and a server.

First let's take a look at what RTMP looks like in the browser. Not much to see here! We have an embedded Flash player and in terms of HTTP traffic, not much going on. The reason is because the Flash player itself is communicating via an alternate TCP port to the server which is streaming the content.

Let's take another look with a packet sniffer. Now we can see the packet headers and what looks like encoded binary content being streamed to the client. This is going to be difficult to simulate using tools like JMeter or any other generic load testing tool that typically favours HTTP.

The biggest drawback is that RTMP only works in Flash and not in HTML5. New HTTP streaming protocols, like Apple's HTTP Live Streaming (HLS), have wider device support (e.g. iOS) and will likely replace RTMP over the coming years.


HLS works by breaking the overall stream into a sequence of small HTTP-based file downloads, each download loading one short chunk of an overall potentially unbounded transport stream. We can see the following in the browser.

Notice the request made to playlist.m3u8. This effectively serves as a pointer to the other chunks that will need to be downloaded as part of a stream. We can see this as follows:

curl http://wowzaec2demo.streamlock.net/vod/_definst_/smil:streaming_tutorial/streaming_tutorial.smil/playlist.m3u8

The first chunk is chunklist_w1057647775_b3128000 and you can see each subsequent chunk after that. Each chunk will reveal the media URI to be downloaded by the client. We can see this as follows:

curl http://wowzaec2demo.streamlock.net/vod/_definst_/smil:streaming_tutorial/streaming_tutorial.smil/chunklist_w570392994_b3128000.m3u8

`media_w570392994_b3128000_0.ts` is the first media sequence of the first chunk. For example:

curl -I http://wowzaec2demo.streamlock.net/vod/_definst_/smil:streaming_tutorial/streaming_tutorial.smil/media_w570392994_b528000_0.ts
HTTP/1.1 200 OK
Date: Mon, 09 Jun 2014 21:51:20 GMT
Content-Type: video/MP2T
Accept-Ranges: bytes
Server: FlashCom/3.5.7
Cache-Control: no-cache
Content-Length: 426008

Ruby JMeter

The logic to this is straightforward.

Essentially our first request is to get the playlist. In the response we will extract the chunklist. We then make a request to each chunk. In the response of each we extract the streams. We then make a request to each media stream.

We can simulate this in Ruby JMeter as follows:

get name: 'playlist', url: "#{base_path}/playlist.m3u8" do
 random_timer 1000, 3000

 extract regex: 'chunklist_(.+?)\.m3u8',
         match_num: -1,
         name: 'chunklist'

exists 'chunklist_matchNr' do
 foreach_controller inputVal: 'chunklist', returnVal: 'chunk' do
   get name: 'chunk', url: "#{base_path}/chunklist_${chunk}.m3u8" do

     extract regex: 'media_(.+?)\.ts',
             match_num: -1,
             name: 'streams'

   exists 'streams_matchNr' do
     foreach_controller inputVal: 'streams', returnVal: 'stream' do
       get name: 'stream', url: "#{base_path}/media_${stream}.ts"

Notice how we've made use of the match_num: -1 in order to extract all response body matches for each of the items we're interested in, chunklist and streams. We check that the relevant capture has more than one matchNr before making subsequent requests. We also use the foreach_controller of JMeter to loop through each of these results.

You can see the full Ruby JMeter script in detail here. If you don't want to use ruby-jmeter you can also download a copy of the same JMeter test plan here.

Running it on Flood IO

You can upload the JMeter test plan or use the ruby-jmeter gem to execute this demonstration on Flood IO for free. Here are some example results.

What type of results would we be looking for? Flat response times would be of importance, especially for the stream transaction as this is the transaction that is delivering media to the client.

We'd obviously be interested in any response time variation of this transaction as we increase the concurrency (and subsequent network throughput) against the system under test.

Obviously this sort of testing with full HLS media is likely to generate enormous bandwidth between the simulated clients and system under test. This is a perfect reason to consider solutions like Flood IO to generate this type of load.

Start load testing now

It only takes 30 seconds to create an account, and get access to our free-tier to begin load testing without any risk.

Keep reading: related stories
Return to the Flood Blog