4 Tips for Sizing Streaming Server Hardware

Sizing streaming media server hardware can be a difficult process. When people are asked how much server horsepower they want, answers usually include “as little as possible,” and “enough to get the job done.”

This uncertainty is understandable; you don’t want to buy too much, but you don’t want to end up short, either. However, these types of answers leave a lot of wiggle room—which is compounded by the unpredictable, resource-intensive nature of streaming-video delivery. If you’re using Wowza Streaming Engine, there’s no limit to the number of streams you can transcode and deliver—but you will be limited by your server hardware and the bandwidth offered by your hosting provider or data center.

So, how do you determine how much horsepower you actually need when selecting a media server? While many factors play a role, the most important consideration is balancing two constraints: network bandwidth and processing capacity.

For scenarios where you have large numbers of sources—and, therefore, large numbers of streams—these constraints can quickly become bottlenecks in your streaming video delivery. Hitting bandwidth limitations and running out of memory are two common ways servers hit maximum capacity when streaming.

Luckily, there are some best practices you can follow to avoid reaching server overload. These four tips will help you choose media server hardware that meets your streaming demands.

Tip #1: Determine Your Number of Incoming Streams and How They’ll Be Packaged

A server’s processing capacity is affected by the central processing unit (CPU) and available memory (random access memory, or RAM). To avoid overloads caused by limitations on processing capacity, you need to know how many streams your server will have to process concurrently, and how much memory this will require.

How Many Streams Do You Need to Transcode?

Not all processing tasks require the same amount of processing power. After understanding the number of incoming streams your server will need to handle, you should identify how you plan to package your streams for delivery.

Media encoding and transcoding tasks are inherently CPU-intensive processes. For example, running something like Flash Media Live Encoder (FMLE) in a desktop environment consumes up to 80 percent of a single core CPU.

The amount of CPU necessary for traditional transcoding tasks varies, however. “Transcoding” can refer to either changing codecs (e.g., converting VP8 to H.264), or transrating a stream for adaptive bitrate, or “ABR,” delivery (e.g., converting a single bitrate stream into four renditions). While both jobs will consume CPU, transrating streams for ABR delivery will use a lot more.

Alternatively, sometimes a workflow will only require a stream to be transmuxed (e.g., converting a single RTMP stream to HLS). This is called “passthrough processing”—a task that requires much less CPU for packaging.

If you need to transcode multiple streams for ABR delivery, you’ll need a server with greater processing capacity. The number of streams a given server can transcode varies significantly. However, we regularly benchmark servers and workloads to help users understand what to expect. Read our latest transcoding benchmark report to learn more.

Here’s a sample configuration for a typical OTT (over-the-top) broadcaster workflow:

This benchmark is meant to represent the maximum amount of resources used when running inputs and transcoding, it doesn’t fully reflect an entire workflow and we don’t recommend running the CPU over 80% utilization in production.

How Much Memory Do You Need?

Memory consumed during the ingest and packaging processes typically corresponds with the total number of incoming stream connections, which are viewable as Java processes. The more incoming sources and streams you have, the more processing capacity your server will require.

As part of the Wowza Streaming Engine installation, the necessary server version of Java Runtime Environment (JRE) is automatically installed. Some legacy hardware users report JRE limiting the usage of RAM to 8 GB—however, modern hardware installations should be able to handle up to 16 GB.

The default setting in Wowza Streaming Engine is 10 GB, but this value can be edited in the XML, up to the maximum of 16 GB per instance.  Pushing the RAM configuration to 32 GB is usually sufficient to accommodate large numbers of input sources.

Tip #2: Estimate Peak Concurrent Streams From Your Server

While the relationship between stream bitrate and bandwidth is pretty much the same for ingest and egress, the outbound side gets a little more challenging. Why? It’s not always easy to guess the number of viewers you’ll have, or the renditions those viewers will need.

To avoid bandwidth-related overloads, estimate the peak outbound bandwidth your server will need to handle. Here’s a sample use case to walk you through the process:

Example: Estimating Peak Concurrent Streams

Let’s assume you use a data center that provides a maximum throughput capacity of 2 GB/s. Given our 80-percent rule from above, this means you should plan for a maximum bandwidth pipe of 1.6 GB/s.

To understand how many streams you can fit in a 1.6 GB/s pipe, you should first estimate the average size of the streams being delivered to end viewers. To note, your average viewer’s stream resolution may be different than your source stream resolution. If you are transcoding your source stream down to smaller renditions, viewers may be watching a stream 40 percent smaller than the stream source (when it comes to outbound streams, we are most concerned with the stream size of the average viewer).

Assuming 30 frames per second, some good guidelines for stream size are:

Stream Resolution	Streaming Bitrate
8K	21 – 50 Mbps
4K	13 – 34 Mbps
1080p	3 – 6 Mbps
720p	1.5 – 4 Mbps
420p	0.5 – 2 Mbps
360p	0.4 – 1 Mbps

Using the average viewer stream size you’ve determined, you can now estimate your bandwidth requirements. To do this, simply multiply the stream bitrate by the peak number of streams:

stream bitrate * number of peak concurrent streams < 80% of total available bandwidth

Continuing with our example, here are a few scenarios for peak connections, given different average-viewer stream sizes:

Average Viewer Stream Size	Total Viewers	Outbound Bandwidth	Useable Bandwidth	Total Pipe
1080p @ 6 Mbps	258	1.55 Gbps	1.6 Gbps	2 Gbps
720p @ 2 Mbps	775	1.55 Gbps	1.6 Gbps	2 Gbps
360p @ 0.5 Mbps	3,100	1.55 Gbps	1.6 Gbps	2 Gbps

Keep in mind that you also need to account for your incoming stream bandwidth. While this will typically be a small percentage of your total concurrent streams, in scenarios with a large number of one-to-one or one-to-few broadcasts, the bandwidth for incoming streams can really add up.

Finally, if this calculation reveals that your server bandwidth is insufficient, you can use a content delivery network (CDN), such as Wowza CDN, to deliver streams to any size audience. The Stream Targets functionality allows you to push a single stream or a group of transcoded stream renditions from Wowza Streaming Engine to Wowza CDN out to any number of viewers.

Tip #3: Choose the Right Deployment Model 

Another consideration is whether to deploy on a cloud infrastructure, or to deploy on-premises using a “bare-metal” hardware server. Cloud deployment has many benefits, such as more efficient resource utilization and reduced overhead costs.

However, cloud infrastructure also employs virtualization and orchestration management software stacks—which adds additional workload to physical resources, including CPU, networking and RAM. When combined with common overprovisioning practices, this overhead will reduce the load serviceable on a given virtual machine.

A bare-metal configuration, on the other hand, typically allows for greater processing capacity. On a bare-metal server, you can expect to utilize up to 80 percent of total network bandwidth, and even higher percentages of CPU. In comparable virtualized and cloud deployments, useable CPU typically tops out around 65 percent, and accessible networking at around 50 percent.

While bare-metal configurations have the advantage of greater resource availability, virtualized cloud environments are flexible, easy to use and offer self-service capabilities. For many people, these positives outweigh the negatives.

Tip #4: Use GPU Offload and Content Delivery Networks

To get the most out of your server’s processing capacity, there are a few other infrastructure capabilities you can make use of: GPU offload and CDNs.

GPU Offload and Acceleration

Wowza Streaming Engine supports the use of graphics-processor offload of transcoder workloads, so you can maximize your processing power. By utilizing GPU scaling, users of both cloud and bare-metal configurations have successfully offloaded up to 75 percent of their CPU transcoding workload.

Going back to Figure 1, enabling GPU scaling reduces CPU consumption from 68 percent to 43 percent. Recent improvements in Wowza Streaming Engine’s GPU utilization can facilitate even greater CPU-workload reductions: In some cases, more than 90-percent reductions in primary CPU workload are possible.

Content Delivery Networks

Employing and pushing streams to a CDN is one of the most common ways to remove a bottleneck with a single server. Using a CDN, it’s possible to reduce the outbound streams to a single stream for each rendition.

As mentioned, you can use the Stream Targets functionality in Wowza Streaming Engine to push a single or multi-bitrate stream to Wowza CDN to efficiently scale stream delivery to a global audience. This takes the burden of delivery off of your server, so you can stream to larger numbers of concurrent viewers without worrying about hitting your bandwidth capacity.

It’s important to note that configuration options within your CDN—including cache-miss ratio and time-to-live (TTL) for cached content—can significantly increase the number of requests to your Wowza Streaming Engine server.

While not definitive or absolute, hopefully these tips help you narrow your options and size your server resources appropriately. Even after sizing, we highly recommend that you test performance under load, and/or utilize a virtualization/orchestration stack that enables you to adjust and add resources.

For more information on sizing hardware and virtual machines for the deployment of Wowza Streaming Engine, please see the Wowza Transcoder Benchmarking test reports. You can also check out the Wowza Forums for topics such as:

Capturing Transcoder Testing/Benchmarking
Published Wowza Transcoder Benchmarking Results
Get the Wowza Streaming Engine RTMP Load Test Tool
Wowza Streaming Engine Cloud Deployment
Wowza Streaming Engine Scaling and Load Balancing How to Stream to Wowza CDN