Results 1 to 5 of 5

Thread: EC2 performance for live streaming not so great...

  1. #1

    Unhappy EC2 performance for live streaming not so great...


    on our (dedicated) Wowza server in Germany we are experiencing several difficulties from users who want to access our Wowza live streaming application from countries like Brazil or China. That's why we test our platform on a Amazon EC2 server in the US where especially people from those countries seem to have a better connection to and therefore a more stable performance.

    We have a c1.medium instance there, which should be pretty good for this job (we even don't have hundreds of parallel streams by the way). But there are some interesting limitations. For example, each user nearly never gets a downstream performance of more than 2000 kbit/s (normally much less). Well, this is not a big problem for our rather less demanding live streaming platform but when it comes to downloading documents with rich media (or even a swf of just 1 MByte in size) you can see and wait for the loading progress bar.

    The biggest problem we have encountered so far is a quite often poor connection of single users or all users of an application instance. Those users have usually top notch connections to the Web using dedicated lines and had never similar issues in the past.
    There you can also see that the performance most often only affects people who access an application instance at first or in the first minutes. After 5-10 minutes or so (and maybe a reconnect) the performance gets better.
    I don't know if this is related to the EC2 virtual machine hosting approach where loads are dynamically allocated and shared but it makes a live application not very reliable.

    We have also an interesting issue, that the first stream that gets published behaves strange when it gets unpublished later.
    Then all the subscribing clients get their unpublishing event about 20-30 seconds later (even when they all have a great connection performance).

    Maybe that's all related to the big distance to the US server from Europe... or an expensive dedicated server is the only way to go.
    But we currently don't know what we can expect when it comes to Wowza/Flash live performance.

    Last edited by dpMediaDev; 03-04-2013 at 06:59 AM.

  2. #2
    Join Date
    Dec 2007



    I think most or all of the problem is the great distance, we have heard similar accounts. But the c1.medium is not a very substantial instance type, you might try the c1.xlarge

    If you are packetizing for HTTP clients (e.g. iOS devices) you could also try packetizing on the edge instead of the origin. Remove the packetizer(s) from the origin Application.xml /LiveStreamPacketizers (make it empty) and change the edge Application.xml /LiveStreamPacketizers from the repeater packetizers to the regular packetizers (what you were using on the origin)


  3. #3


    Thanks for your reply.

    Right now we focus on classic RTMP(T) streaming so we don't need to support HTTP clients like iOS.
    The c1.xlarge instance is much more expensive but beside the better IO performance all the other parameters are just overkill especially the heavy computation power we surely don't need. Maybe a m1.large instance fits better the job because it has high IO performance, too.
    Well, at least we have a Wowza license that can be used everywhere (because of the new 3.x licensing) so testing new servers around the world should be doable. But it would be great if we would know where to start. E.g. one of the well known live streaming platforms (delivering it as a service) focus heavily on SoftLayer servers... Maybe they deliver better performance for that kind of stuff, we just don't know.

    Last edited by dpMediaDev; 03-05-2013 at 06:04 AM.

  4. #4


    Hmm... I was mistaken here: This high IO performance is only related to disk access. It doesn't say anything about the performance of the connections. So I guess you can't get an instance having just a better connection with higher usable bandwidth for each, isn't it?
    Maybe we should just try another region from what Amazon offers.

  5. #5
    Join Date
    Dec 2007


    Actually, referring to this list, I think "IO Performance" refers to network throughput. Notice the Cluster types are more specific: I/O Performance: Very High (10 Gigabit Ethernet)


Similar Threads

  1. ec2 upload performance
    By thejerm in forum Wowza Streaming Engine in the Cloud
    Replies: 1
    Last Post: 09-10-2014, 08:45 AM
  2. Improving EC2 Wowza Streaming Performance
    By abhi158005 in forum Performance and Tuning
    Replies: 1
    Last Post: 03-14-2014, 05:58 AM
  3. Live streaming to Android devices not working (all other browsers are great)
    By stevefink in forum Live Streaming and Encoder Discussion
    Replies: 3
    Last Post: 10-08-2013, 11:24 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts