Skip to content

Load balancing in Flussonic

Load balancing in Flussonic

Increasing number of viewers causes growing server load. To avoid server's overload load balancing is used. It efficiently distributes the network traffic across the number of servers to keep your viewers happy and to prevent video stream from interrupting.

Flussonic can balance users between several Flussonic Media Server nodes. Load balancing is achieved by redirecting client requests to another, less loaded server in a cluster.

You can enable load balancing without the use of IPTV plugin or Catena. It may be configured straight in Flussonic.

How do you know you need a balancer?
If your streaming platform or a service has more than 10 000 viewers, then you should definitely take it into consideration. Otherwise, you might experience server's overload, which will result in stream interruption and malfunction, which leads to bad viewer experience.

To use the balancer add it to the configuration file (/etc/flussonic/flussonic.conf):



balancer lb {
  peer p1 max_bitrate=40M;
  peer p2;
  peer p3 max_bitrate=60M;
}


You have to specify:

  • lb — balancer name
  • peer — peer (like peer1.example.com)
  • max_bitrate — max output bitrate of the server in Mbps (optional)

Example of a URL for a stream channel1 request:

http://flussonic/lb/channel1/index.m3u8

You can configure a few balancers at a time if there is a need.

How does the balancer decide where to redirect the client?
The decision is made based on the the max output bitrate.
Let's consider an example: p1 is the least loaded server in a cluster based on the config above. Client requests one of the streams from our cluster. Flussonic redirects the client to that p1 server giving him an access to the desired stream. So the client's request is sent to the least loaded server.
In case there are multiple Flussonic Media Servers with the same least output bitrate level (practically it happens when the value equals to 0), then the server for redirection is chosen randomly.

It should be pointed out that the same client (the same token, IP address) will be receiving his own cached response for 10 seconds since the last request regardless of Flussonic server health.
In other words, the same client's request for the same stream will be redirected to the same server, if the stream is still running there. if not, the client will be redirected to another server within 10 seconds, where this stream is running.