February 10, 2015

HLS, DASH and Icecast streaming load balancing

Nimble Streamer is used for reliable delivery of media streams. It is robust and has low resources usage so even a single server instance may handle several gigabits per second without any problems.

However, there are cases when you need several servers working as a single network:

  • Preventing hardware and network failures - if one server becomes inaccessible, other instances must take its load.
  • Handling amount of connections which is too big for single instance.
  • Handling significant bandwidth which is higher than single server throughput.
  • Geographical balancing to deliver content from the location nearest to the viewer.

For HTTP-based protocols like HLS, DASH, Icecast, Smooth etc. there are several balancing techniques, like HTTP 302 status redirection or DNS failover, but none of them are reliable. There are several reasons. Several HLS players do not handle redirection headers correctly. The same applies to DNS failover where an average player cannot guarantee that some chunks won't be obtained from different edges, breaking the sessions information. This is crucial for getting the audience metrics hence unacceptable for streaming systems. Production-grade networks cannot rely on such inconsistencies.

At the moment the only reliable way of balancing the connections is to manually give a link to the exact edge server at the location where a player takes the URL of the stream. This needs additional business logic on a server side but it gives a proper flexibility which is not achievable by other techniques.

Let's see how you can make a balancing for a network of Nimble Streamer instances. The following picture shows possible general workflow.

Basic steps for this workflow are as described below.

  1. Nimble Streamer has an API for obtaining general performance real-time information. So an "arbiter" service is created to collect edges' data and make decisions about incoming connections.
  2. The viewer opens a web page to watch the video or listen to some audio channel. The web framework which is used for generating this page calls an arbiter to know what is the best edge server to take the designated stream from.
  3. As a result, a viewer is shown a media with URL pointing to an appropriate media server.
  4. The viewer opens the media from pointed URL and gets stream while streaming network is loaded in a proper way.
The next viewer's connection request goes through the same steps. The URL being received has the best conditions for current client. Check the sequence diagram below as well see the time scale.

Load balancing sequence diagram.

We created some streaming balancing reference code in our github account for your convenience. Check this example which allows balance the load based on amount of bandwidth and connections of all specified servers in a given network. An arbiter here is a PHP class which calls Nimble Streamer API and optionally stores results in cache. You can use it for making modifications based on your own business logic.

Geo balancing

The described logic applies when you need to have users connect to the edge server located in the nearest geographical location. An "arbiter" may determine user location via IP geo-location database and propose the nearest edge. We've created a geo balancing reference code and, it's a PHP class with an example of its usage which you can use for your purposes.

The approach described in this article requires a bit of development to create an arbiter based on your business logic but it will certainly cover all of the load balancing use cases which you may need. Our reference code will help you develop the business logic which you need for your particular case.

If you'd like to check how you can deliver streams from origin to edges, check Building RTMP live streaming network via Nimble Streamer article for details.

Please also take a look at WMSPanel reporting feature set. You will be able to get variety of stats about your audience from all of your servers in a combined reports regardless of network infrastructure. Check also Icecast control API for Nimble Streamer.

Related documentation

Nimble Streamer, Nimble Streamer API reference, Media streaming reporting frameworkWMSPanel API referencePaywall framework, Icecast control Nimble API,


  1. I assume this goes in the nimble directory and we call on it ? the php files I mean

    1. You can place it anywhere you need, it's not locked to Nimble binaries location.