Time to go Live at Scale!
You’re about to launch a big marketing push for your live video streaming app. Your marketing team is confident that the event will attract somewhere between 1,000 (worst case) and 20,000 (best case) active, or concurrent, subscribers. Or even more challenging, what happens if your silent launch somehow attracts thousands more subscribers than you anticipated?
Clustering to the Rescue
Red5 Pro clustering can help you manage your overnight success! Clustering allows for near-infinite scale by distributing the streams to multiple instances. This post hopes to quickly get you up to speed on how to configure your app for that scale.
Our clustering solution is based on an Edge-Origin model. Origin servers accept published streams coming from broadcasting/publishing clients, and Edge Servers push those streams to subscriber clients.
Which Server Instance Should I Use?
Red5 Pro clustered solutions work best in a cloud hosted environment, such as Amazon Web Services or Google Developer Console, which allow users to spin up new instances at will. That said, if your business requires it, you can easily deploy Red5 Pro on your own internal network as well.
The two factors that you want to be looking at for a streaming server are (1) multiple CPUs and (2) good network throughput. Given those parameters, and assuming you are running Red5 Pro on Ubuntu (or other linux distribution) hosted on Amazon Web Services, we recommend either the m3.xlarge or the m4.large. Each of these server types have 4 CPUs and high network performance ratings, and can safely manage up to 2,000 concurrent subscriber connections.
The communication between the servers is handled through the Red5 Pro clustering plugin and a configuration file on each edge server that tells it the IP address of the origin server(s) with which to check in to receive stream information. This mechanic allows the customer to add edge servers to a cluster on the fly.
The origin server in a one to many broadcast use case has minimal load on it compared to each edge server, because it is only processing the broadcaster, and then handing off the subscribing to the edge servers in the cluster. The subscriber streams are distributed across the pool of edge servers.
The Mobile Client Side:
Once you have a cluster solution in place, you will need to:
- Direct your publisher to the Origin for broadcasting and
- Direct your subscribers to the Origin to find out which Edge server they should connect to for viewing the stream.
The publishing side of the equation is just your standard Red5 Pro publisher. You will want to consider your audience when you choose your resolution and bitrate for publishing. If your broadcast stream quality is too high, then your lower-end subscribers will experience some video anomalies. For example, you may be publishing from an iPhone 6S plus over wifi, but your audience could be subscribing via an iPhone 4S over 3G. The subscriber in this case just can’t support a high definition video stream.
We’ve found that using around 1500 kbps ceiling, 1024 X 768 resolution and enabling Adaptive Bitrate Publishing (examples: iOS Objective C, iOS Swift, Android) is a nice balance between quality and being able to deliver to the most people with smooth video. Note that our examples tend to use very low bitrates simply to not eat up your bandwidth usage while testing.
With a clustered server environment, mobile subscribers will need to be directed from the Origin server to an Edge server to receive the stream. Navigating to http://origin-server-ip:5080/cluster will display the next Edge server selected via a round-robin logic; refresh the page to see all of the edge servers that the origin is communicating with. This is also what the mobile clients use for round-robin cluster subscription.
Please check out the cluster subscribe examples in Github:
For more in-depth information on clustering with Red5 Pro, check out Red5 Pro Clustering documentation. Also, stay tuned for an amazing clustering update in one of the upcoming releases! Right now, this feature is top secret, but if you are curious, just get in touch, and we can discuss how our new solutions can work for your use case.