Introduction

This white paper discusses the deployment, performance and scalability to the Azure Cloud platform of a streaming server solution – Evostream Enterprise Media Server (EMS).

Tests of performance have been conducted by the EvoStream team but were not audited by a third party. That said, we are disclosing all the details and data so that you can arrive at your own conclusions.

Advanced Load balancing and bandwidth management

For larger deployments, EvoStream Media Server provides an advanced Load Balancer Solution template leveraging the Azure load balancing and auto-scaling capabilities.

These load balancing schemas and bandwidth reducing features optimize the VM capacity and software license require to support your live streaming requirements. Using the EvoStream Media Server in a clustered environment only multiplies the cost savings.

This tremendous value is achieved by an ultra-efficient software architecture along with utilizing the native C/C++ programming language instead of running on a complex Java platform. Deploying to the cloud leveraging from advanced load balancing and bandwidth management you can expect a saving in TCO.

The EvoStream Media Server can reduce your Total Cost per stream. There are many costs associated with operating a streaming service, but typically software and VM cloud licensing costs are chief among them.

The key EvoStream Media Server cost-saving driver is its efficiency which allows a server to handle 4 times as many concurrent streams. This means one server can now do the job of 4, drastically increasing your capacity or drastically reducing the amount of cloud capacity (VMs) needed to accomplish a target project.

EvoStream on Azure

Architecture

A simple scaling live-stream for redundant and low-latent live streams.  HTML5 delivery (to browsers or apps), legacy RTMP, or fall back to HLS and/or DASH can be used.

After deployment, the following VMs will be provided:

• 1 SM (Stream Manager) VM
• 1 Origin VM
• 2 Edge instances in a VMSS with autoscaler
• 1 Load-Balancer

All VMs communicate with each other through the local VNET.

The Origin VM and Edge VMSS connect to stream sources and players (respectively) via their public network interface and IP address.

Each Edge/Origin VM has one running instance of the EMS.

The Edge VMSS autoscales from 2 to 5 instances depending on bandwidth usage.

Stream manager

• The SM manages stream replication from the Origin VM to the Edge VMs.
• When a stream is created at the Origin VM, the Origin notifies the SM of a new stream.
• The SM commands each Edge VM to pull the new stream from the Origin VM.

Origin and Edge EMS servers

• The Origin EMS is where inbound streams are aggregated.
• Clients may push streams to the Origin EMS.

Load Balancer

• Distributes load among Edges

Auto-Scaler

• Automatically scales Edges based on bandwidth usage

Azure Load Balancer and Auto-Scaling

When a client pulls or plays a stream from the Edge server, the load balancer selects an Edge VM to connect to the client.

The load balancer uses Hash-based distribution mode. When the client closes and reopens the connection or starts a new session from the same source IP, the source port changes. This may cause the traffic to go to a different Edge VM.

Besides the load balancer, the Edge VMSS is also equipped with a VM Scale Set (VMSS) autoscaler. The autoscaler is assigned for the scaling in and out of the Edge VMSS.

• Scaling out: When the total outbound bandwidth exceeds a preset upper limit, the autoscaler creates an additional Edge VM.

• Scaling in: When the total outbound bandwidth drops below a preset lower limit, the autoscaler deletes an Edge VM.

Please note that scaling up/down is normally used for increasing/decreasing the VM size. Scaling in/out is used for increasing/decreasing the number of VMSS instances without changing the VM size

A minimum of 5 minutes is required before the autoscaler scales out or in.

For more information at Quick Start Guide for Microsoft Azure Load Balancer.

Performance

EvoStream conducted several tests to see the performance of the load balancer. Below are the details for the tests:

Performance for a Standard D3_v2 Azure VM

Ramp up consists of several steps where the client adds a fixed number of streams to the ALB load. The client waits for some time after taking each step.  RAMP_STEPS is the number of steps taken during ramp up. RAMP_PULL_COUNT is the number of streams added at each step during ramp up. RAMP_STEP_DELAY is the number of seconds the client waits after taking each step during ramp up. In the example below, 170 streams are added at each step during ramp up. The ramp up rate is 170 streams every 60 seconds. The total ramp up time is 20 x 60 = 1200 seconds (or 20 minutes). The initial number off streams is zero (pulled by client from ALB). The final number of streams for ramp up is MAX_STREAMS which is the product of RAMP_STEPS and RAMP_PULL_COUNT. In the below example, there will be 20 x 170 = 3400 streams at the end of ramp up.

The peak is where the client maintains the number of streams for a fixed duration. The peak duration is RAMP_PEAK_TIMES multiplied by RAMP_STEP_DELAY in seconds. In the example below, the peak duration is 20 x 60 = 1200 seconds (or 20 minutes).

Ramp down is the opposite of ramp up. At each step during ramp down, a fixed number of streams are removed by the client from the ALB load. The client waits for a fixed time before taking the next step. RAMP_STEPS is also the number of steps for ramp down. RAMP_PULL_COUNT is also the number of streams removed from the ALB load during ramp down. RAMP_STEP_DELAY is also the waiting time before taking the next step during ramp down.

MAX_DURATION is the total duration for the ramp test. This includes ramp up, peak, and ramp down. MAX_DURATION is the sum of ramp up time, peak, and ramp down time. This is calculated as (2 x RAMP_STEPS + RAMP_PEAK_TIMES) x RAMP_STEP_DELAY. In the example below, the total test duration is (2 x 20 + 20) x 60 = 60 x 60 = 3600 seconds (or 60 minutes).

The charts below shown are for a Standard D3 VM size using 0.5mbps stream source.

INPUTS:

• RAMP_STEPS = 20
• RAMP_PULL_COUNT = 170
• RAMP_STEP_DELAY = 60
• RAMP_PEAK_TIMES = 20

EXPECTED OUTPUT:

• MAX_STREAMS = 3400 (times 3)
• MAX_DURATION = 3600 sec = 01:00:00

Scalability and Reliability (with auto-scaling)

On these two charts above and below we can see the auto-scaling taking place from two VM edges to five VM edges with a total of streams going up to 10k (VM1 ~4k, VM2 ~4k, VM3 ~2k, VM4 and VM5 low volume).

The bandwidth, averaged over a 5-minute period, has to go above the upper threshold before scaling out occurs. Also, the bandwidth, averaged over a 5-minute period, has to go below the lower threshold before scaling in occurs.

Network bandwidth Efficiency (with auto-scaling)

On this chart above we can see that the total outbound bandwidth goes up to 6 Gbps (VM1 ~2Gbps, VM2 ~2Gbps, VM3 ~1.3Gbps, VM4 and VM5 low volume) when the total number of streams peaks at 10k.

Memory and CPU utilization (with auto-scaling)

On these two charts above and below we can see that the total CPU and Memory usage do not exceed 50% CPU and 14% RAM, respectively, with an outbound bandwidth going up to 6 Gbps and the total number of streams peaking at 10k.

Performance for a Standard D1_v2 Azure VM

The charts shown below are for Standard D1 Azure VM size using 0.5mbps stream source.

INPUTS:

• RAMP_STEPS = 20
• RAMP_PULL_COUNT = 100
• RAMP_STEP_DELAY = 60
• RAMP_PEAK_TIMES = 20

EXPECTED OUTPUT:

• MAX_STREAMS = 2000
• MAX_DURATION = 3600 sec = 01:00:00

Scalability and Reliability (with auto-scaling)

On these two charts above and below we can see the auto-scaling taking place from two VM edges to five VM edges with a total of streams going up to 2k (VM1 ~750k, VM2 ~750k, VM3 ~400k, VM4 and VM5 low volume)

The bandwidth, averaged over a 5-minute period, has to go above the upper threshold before scaling out occurs. Also, the bandwidth, averaged over a 5-minute period, has to go below the lower threshold before scaling in occurs.

Network bandwidth Efficiency (with auto-scaling)

On this chart above we can see that the total outbound bandwidth on the VM EMS edge 1 goes up to 1.8 Gbps (VM1 ~700Mbps, VM2 ~700Mbps,, VM3 ~300Mbps, VM4 and VM5 low volume) when the total number of streams peaks at 2k.

Memory and CPU utilization (with auto-scaling)

On these two charts above and below we can see that the total CPU and Memory usage do not exceed 75% CPU (momentary spikes) and 30% RAM, respectively, with an outbound bandwidth going up to 1.8 Gbps and the total number of streams peaking at 2k.

 

Conclusion

Deploying EvoStream HTML5 Low-Latency Broadcast Template for Azure leverages and optimize from the load balancing and auto-scaling capability to increase the performance, scalability and TCO.

EMS is one of the best solution on the market due to its native capability and auto-operability of deployment to any platforms and devices from cameras to mobile phones to the cloud.

Some of the benefits of the EMS solution:

• Multi-platforms, multi-browsers (HTML5)
• Multi-connectivity: Bi directional / peer2peer / cloud deployment
• High performance with Low latency (sub-second)
• Low deployment cost