Performance Testing Low Latency HLS servers

In our previous blog we explained the benefits of Low Latency HLS (LL-HLS) and how it works. This new release of UbikLoadPack streaming solution now automatically handles the protocol and makes it easy for you to load test streaming applications or servers delivering such format.

Why low latency is needed ?

Before Low Latency, the average latency of a live event was around 30s, meaning you had 30 s delay between the time the real life event happens and the time it is seen by users through Live Streaming.

Although this latency could be acceptable for Concert, theaters, it was still a problem for business fields like:

• gambling
• live auctions
• betting
• gaming
• live chat

LL-HLS is a revolution in the live streaming field, as it aims at decreasing latency to less than two seconds, some players go even lower up to 0.5 seconds. It becomes close to real time and opens live streaming to new business models.

Low Latency HLS challenges for streaming providers

Firstly, as you can understand, with the introduction of Low Latency HLS, providers face multiple challenges:

• Player will have more aggressive request rate since smaller segments (partial) are used
• Players requests will pile up waiting for chunk to become available if using PRELOAD-HINT
• They need to fine tune latency
• Ensuring their software works accordingly and scales well

Considering those challenges, it is critical to test the performances of the software and architecture delivering LL-HLS.

How UbikLoadPack Video Streaming Plugin helps you

Hopefully, UbikLoadPack solution will make your performance testing experience as smooth as possible by supporting Out Of The Box the main features of LL-HLS:

• Partial Segments
• Delta update
• Preload
• Blocking Reload

In addition to requesting the manifest, parsing it, requesting the chunks and then simulating the reading as a real player would; it will handle tags related to LL-HLS and request chunks / manifests the way a Player is expected to handle LL-HLS.

As such it supports all LL-HLS specific tags involving client/server communication:

• EXT-X-SERVER-CONTROL (CAN-BLOCK-RELOAD, CAN-SKIP-UNTIL, PART-HOLD-BACK)
• EXT-X-PART-INF / EXT-X-PART
• EXT-X-PRELOAD-HINT
• EXT-X-SKIP

As you can guess, the testing of LL-HLS streams is much easier as all the complex work is done automagically.

Just provide the manifest URL of your low latency stream to the plugin, and it will do the rest.

No need for you to maintain custom and complex script, the plugin does everything for you !

Firstly, In the picture below, notice the plugin automatically requests the Audio and Video Partial Segments of 0.5s each instead of the 2s Segment:

Secondly, in the picture below, the plugin automatically handles Block reload by issuing a request with _HLS_msn / _HLS_part parameters:

Thirdly, in the screenshots below, the plugin handles Preload by issuing a request on the URI mentioned in EXT-X-PRELOAD-HINT tag:

Fourthly, as you can see in the picture below, the plugin automatically handles Delta update by issuing a request with _HLS_part / _HLS_skip parameters:

In conclusion, thanks to the plugin, you can now focus all your energy on optimizing your software stacks and fine tuning your architecture.

Reporting and Custom Metrics

Besides simulating Player behaviour, the plugin generates at 60 seconds interval a technical Sample Result of type VideoStreamingSampleResult (ULP_VS below).

This element provides useful custom streaming related metrics.

Indeed, aside from the metrics provided by Apache JMeter, the plugin also adds custom metrics relative to video streaming such as:

• the buffer fill time
• the lag time
• the lag ratio (with and without buffer fill time)
• the speed rates (for Low Latency DASH)

Identifying Server side time vs Client Side time

In Low-Latency HLS, a server may block until a resource is available for blocking reload and preloading hinted resources. As we need to know this “server side” spent time in order to compute the response time metrics correctly on client side, your server needs to expose this timing in a way.

Some implementations of LL-HLS expose this timing in a response header. In order to handle this, the plugin allows you to configure this header name through property:

ulp_streaming.ll_hls_support.server_blocking_time_extractor.possible_header_names

If your servers provide this information, you can configure the below property. For example AKAMAI uses a header name “block-duration”, in this case configuration would be:

• ulp_streaming.ll_hls_support.server_blocking_time_extractor.possible_header_names=block-duration,blocking_time

Of course, if you want to expose this “server side time” in a different way, we provide ability to customize this extraction.

How to setup

Follow the setup instruction described in this blog UBIK LOAD PACK VIDEO STREAMING PLUGIN.

Then add to user.properties this section:

ulp_streaming.ll_hls_support=part,delta,block,preload

This property describes the features of LL-HLS your server supports and you would like to validate.

You’ll probably also like:

• Performance Testing Low Latency Dash servers with UbikLoadPack
• Performance Testing Low Latency HLS servers
• Load testing MPEG-DASH Video Streaming with Apache JMeter and UbikLoadPack
• Video Streaming: CMAF and Low-Latency
• Cases studies

• How Low latency HLS will improve User Experience in Video Streaming and OTT