Loading ...
close

Would you like to discuss your environment with a knowledgable engineer?

Preferred communication *

Thank you. We will be in touch with you shortly

Scaling Adobe Media Server on AWS

We tested the top OTT video server with aiVideo. See the results and a detailed technical breakdown below.

###
# Adobe Media Server HDS streaming
###
Transactions: 5797 hits
Transaction rate: 198.39 trans/sec
Concurrency: 19.96
###
# aiScaler HDS streaming
##
Transactions: 15480 hits
Transaction rate: 523.15 trans/sec
Concurrency: 19.97
#############################################
#############################################
#############################################
###
# Adobe Media Server HSL streaming
###
Transactions: 10580 hits
Transaction rate: 356.23 trans/sec
Concurrency: 19.98
###
# aiScaler HLS streaming
###
Transactions: 27890 hits
Transaction rate: 961.06 trans/sec
Concurrency: 19.95

aiScaler serves about 2.5 times as many transactions as an Adobe Media Server by itself, on exactly the same hardware. This means that by adding an aiScaler server to your AMS server -with exactly the same hardware-  you will increase your capacity by 3.5 times.

Complete results are in this file

 

First I created an aiScaler instance from Amazon Marketplace and made a configuration that would cache the stream manifest files and the actual video chunks. I used two high throughput instances (c3.8xlarge), to really test the limits of aiScaler and Adobe Media Server on AWS. The configuration used is this one (if you want to use it, just remember to replace the hostname and the origin server IP). I’ll explain some important parts in this configuration that are specific to this set up:

num_workers 32

This setting ensures that aiScaler is using all the cores the server provides.

pattern livestream.m3u8 simple 4 no_log
pattern livestream.f4m simple 4 no_log
pattern .*livestreamNum.*.ts regexp 60 no_log
pattern livestream.bootstrap simple 3 no_log
pattern .*livestreamSeg.* regexp 60 no_log

Here I have configured the patterns that will cache the manifest files and actual video chunks that will be distributed to watchers. livestream.m3u8, livestream.f4m and livestream.bootstrap are manifest files that will instruct players which video chunk should be downloaded next. Because video chunks are generated once every 4 seconds and bootstrap files have their new names I’ve set it to be cached for 4 seconds. Actual chunk files look like livestreamSeg23-Frag2206 or livestreamNum955.ts, thus I created a pattern that will match them. I’ve set to cache the chunk files for 60 seconds in case someone joined the streaming later aiScaler will provide the video file directly from cache.

Adobe Media Server 5.0 supports two HTTP streaming formats:

  • HLS (HTTP Live Streaming), supported by iOS devices
  • HDS (HTTP Dynamic Streaming), supported by Flash applications

I have started with HDS (chunks in this case have the name similar to livestreamSeg23-Frag2206), and from Adobe Media Server logs I was able to see the chunks fetched by the flash player, using those URLs I used siege to see how many streams can get through the Adobe Media Server and aiScaler. The same scenario was applied with HLS (chunks have the name similar to livestreamNum955.ts in this case). Each test lasted for 30 seconds, to make sure that cache didn’t expire, as I’ve set the TTL at 60 seconds.

US 1 (408) 744-6078   EU +44 20 7993 4587