Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Maxing out a c3.8xlarge instance: 500, 1000 or 2000 simultaneous viewers?

  1. #1
    Join Date
    Nov 2012
    Posts
    103

    Wink Maxing out a c3.8xlarge instance: 500, 1000 or 2000 simultaneous viewers?

    Can you help me estimate how many connected users Amazons most powerful instance can handle?

    Use case: One encoder in Copenhagen streams to the c3.8xlarge instance (32 vCPU, 60 GB RAM and 10 Gigabit*4) in Ireland with 5000 Kbit/s. The 5000 Mbps stream is transcoded on the instance to three bitrates, 500 Kbps, 1000 Kbps and 2000 Kbps.

    500 simultaneous viewers
    500 simultaneous viewers residing in Denmark, consume the stream in the three bitrates. One third at 500 Kbps, one third at 1000 Kbps and one third at 2000 Kbps totalling 250 GB during this hour.

    1000 simultaneous viewers
    1000 simultaneous viewers residing in Denmark, consume the stream in the three bitrates. One third at 500 Kbps, one third at 1000 Kbps and one third at 2000 Kbps totalling 500 GB during this hour.

    2000 simultaneous viewers:
    2000 simultaneous viewers residing in Denmark, consume the stream in the three bitrates. One third at 500 Kbps, one third at 1000 Kbps and one third at 2000 Kbps totalling 1000 GB during this hour.

    • When would I hit the limit? Before 500 users? 1000 users? 2000 users?
    • Does it matter if the streams are RTMP, HTTP or a mix of the two?
    • Also, does the number of simultaneous viewers actually matter a whole lot, or is it simply a matter of throughput: Does 100 viewers consuming a 2 Mbit/s stream equal to 1000 users consuming a 200 Kbit/s stream?
    • Lastly, if the number of simultaneous viewers rise above what a single server can handle, can you lay out the difference between Dynamic Load Balancing AddOn and Elastic Load Balancing? What are use cases for the Dynamic Load Balancing AddOn vs. the use cases for Elastic Load Balancing? And when would you combine the two?

  2. #2
    Join Date
    Sep 2011
    Posts
    1,934

    Default

    Hi,
    Wowza does not have a hard limit to the cumber of connections it can handle, this is based on the hardware and bandwidth available to the server.

    500 kbps + 1000 kbps + 2000 kbps = 3500 kbps | 3500 kbps /3 = 1166.6 Kbps 
    
    500 connections with an average bitrate of 1166.6 Kbsp = 583300 Kbps == 583.3 Mbps == 262 Gig per hour
    
    1000 connections with an average bitrate of 1166.6 Kbsp = 1166600 Kbps == 1.166 Gbps == 524 Gig per hour
    
    2000 connections with an average bitrate of 1166.6 Kbsp = 2333200 Kbps == 2.332 Gbps == 1048 Gig per hour
    The only hard limitation I can see is the network interface which as you can see, your usage is far below what the interface can handle.
    Having a large number of connections for a low bitrate stream is marginally more load as Wowza is handling more connections with the same bandwidth but this will not be noticeable.
    Having HTTP clients rather than RTMP clients is also slightly more load but has an incredibly small difference which again wouldn't be noticeable.
    The Dynamic Load Balancing AddOn and Elastic Load Balancing would not be used together as they are different methods of load balancing.

    Dynamic Load Balancing would be used with an origin edge configuration, the origin and edge servers would already be configured to receive the load directed from the load balancer.
    Elastic Load Balancing creates instances to handle the load you have but this would be better described by a member of staff at Amazon.

    Jason

  3. #3
    Join Date
    Nov 2012
    Posts
    103

    Default

    The only hard limitation I can see is the network interface which as you can see, your usage is far below what the interface can handle.
    What real world performance should I expect from the c3.8xlarge 10 Gigabit*4 network interfaces?

    The Dynamic Load Balancing AddOn and Elastic Load Balancing would not be used together as they are different methods of load balancing.
    Am I right in assuming that the use of the Dynamic Load Balancing AddOn has the potential of escalating my Wowza license costs, as well as the number of Amazon instance hours? Instead of needing a single Wowza license like I would if I could stay on a single instance, I would need four licenses if I wanted three Edge/Load Balancer Senders:


    Instance 1: Combined origin and load balancer listener
    • 1 Wowza license
    • 1 Transcoder AddOn

    Instance 2: Edge/Load Balancer Sender #1
    • 1 Wowza license

    Instance 3: Edge/Load Balancer Sender #2
    • 1 Wowza license

    Instance 4: Edge/Load Balancer Sender #3
    • 1 Wowza license



    I would also need to quadruple the number of instance hours:


    Instance 1: Combined origin and load balancer listener
    • 1 instance hour

    Instance 2: Edge/Load Balancer Sender #1
    • 1 instance hour

    Instance 3: Edge/Load Balancer Sender #2
    • 1 instance hour

    Instance 4: Edge/Load Balancer Sender #3
    • 1 instance hour


    So, while it is not entirely accurate (traffic out is not quadrupled and only a single Transcoder AddOn is needed), this would almost multiply my cost by four. This is well worth the money when the solution is actually needed, but for us this might be the case in only 10 out of 251 working days. The vast majority of events we stream will not have simultaneous viewer counts exceeding 500.

    Then there is the natural limitation of the Dynamic Load Balancing AddOn. It does balance the number of connected viewers between a fixed number of instances, and does this very well as far as I can tell from the feedback I have read and heard. It does not however, do anything when it comes to an origin instance that's struggling to cope with too many incoming streams that has to be transcoded on the server.

    It that correct?

    The CPU in a c3.8xlarge instance will be taxed ~ 15 % when taking one incoming stream and transcoding it to three other bitrates. This means, to stay below 50 % CPU utilization which is your recommendation when user the Transcoder AddOn, the server can cope with three incoming streams. Now this is fine for us for the events we stream the majority of the year. But there might be these 10 out of 251 working days where we need, say six incoming streams. This would cause a CPU load of 90 % and the Dynamic Load Balancing AddOn won't make the the origin instance capable of decreasing the CPU load.

    But AWS Elastic Load Balancing + Auto Scaling would, right? I'm not quite sure if I understand the concepts of Amazons Elastic Load Balancing and Auto Scaling fully, but I imagine that it can indeed help the instance handling the incoming streams and transcoding to never trespass a CPU-utilization limit set in CloudWatch.

    Is that also correct?

    What about cost for an AWS Elastic Load Balancing + Auto Scaling solution? I imagine I would only pay for the instance hours when they are actually needed? And what about Wowza licenses? Would the solution mean that only a single Wowza license is needed? Or would each instance that "helps" need to be preconfigured with a license?
    Last edited by niemion; 01-21-2014 at 10:35 AM.

  4. #4
    Join Date
    Nov 2012
    Posts
    103

    Default

    The only hard limitation I can see is the network interface which as you can see, your usage is far below what the interface can handle.
    What can the interface 10 Gigabit*4 handle?

    From tests such as this showing 10 GbE speeds of up to 900.6MB/s, would we then be able to multiply this by four and then assume this throuhput:

    900.6 MB/s * 4 = 3,5 GB/s
    3,5 GB/s amounts to 28 Gbps, so the c3.8xlarge instance with its 10 Gigabit*4 should be possible to handle 25296 viewers each consuming 1166.6 Kbsp:

    25296 connections with an average bitrate of 1166.6 Kbps = 29510313,6 Kbps == 28.144 Gbps == 12665 Gig per hour
    This is insane. Please correct me.

    Edit: I just noticed that the *4 refers to a footnote and not that the instance has four 10 Gigabit interfaces.

    So I should not multiple 900.6 MB/s with four. It's just 900.6 MB/s == 0.879 GB/s == 7.036 Gbps == 7377715 Kbps.

    7377715 Kbps / 1166.6 Kbps = 6324 concurrent connections.
    Last edited by niemion; 01-22-2014 at 04:31 PM.

  5. #5
    Join Date
    Sep 2011
    Posts
    1,934

    Default

    Hi,
    What real world performance should I expect from the c3.8xlarge 10 Gigabit*4 network interfaces?
    Java has a limitation of 5 Gbps so this would be a limitation as to how many concurrent connections you can have which will vary based on the bitrate of the streams being viewed.

    Am I right in assuming that the use of the Dynamic Load Balancing AddOn has the potential of escalating my Wowza license costs, as well as the number of Amazon instance hours? Instead of needing a single Wowza license like I would if I could stay on a single instance, I would need four licenses if I wanted three Edge/Load Balancer Senders:
    The origin and each edge would require a license so yes this would increase licensing costs and would be a total of four with one origin and three edges.
    You can use Devpay or BYOL which is up to your personal preference.

    Then there is the natural limitation of the Dynamic Load Balancing AddOn. It does balance the number of connected viewers between a fixed number of instances, and does this very well as far as I can tell from the feedback I have read and heard. It does not however, do anything when it comes to an origin instance that's struggling to cope with too many incoming streams that has to be transcoded on the server.
    You can have an origin which is also an edge at the same time by setting the StreamType to "liverepeater-edge-origin" this can have load directed to it like any of the other edges.
    That's correct, the elastic load balancing solution may be better for your needs but I recommend asking the Amazon staff for more information on this as I haven't used it myself.

    But AWS Elastic Load Balancing + Auto Scaling would, right? I'm not quite sure if I understand the concepts of Amazons Elastic Load Balancing and Auto Scaling fully, but I imagine that it can indeed help the instance handling the incoming streams and transcoding to never trespass a CPU-utilization limit set in CloudWatch.
    Is that also correct?
    I think questions regarding Amazon's load balancing and network solutions are better directed at the Amazon support staff, although they are using Wowza we do not support their network and so can't give accurate information on server load capabilities for an individual server type.

    What about cost for an AWS Elastic Load Balancing + Auto Scaling solution? I imagine I would only pay for the instance hours when they are actually needed? And what about Wowza licenses? Would the solution mean that only a single Wowza license is needed? Or would each instance that "helps" need to be preconfigured with a license?
    Again this would be better directed at the Amazon support staff who will be able to answer these questions more accurately, I would not like to comment on what you may or may not get billed for.

    Jason

  6. #6
    Join Date
    Nov 2012
    Posts
    103

    Default

    Thank you Jason.

    Java has a limitation of 5 Gbps so this would be a limitation as to how many concurrent connections you can have which will vary based on the bitrate of the streams being viewed.
    This makes it pretty straightforward then, to calculate how many concurrent connections a c3.8xlarge instance can handle:

    5 Gbps equals 5242880 Kbps
    Then we divide the limit of 5242880 Kbps with the average bitrate.

    5242880 Kbps / 1166.6 Kbps = 4494
    4494 conccurent connections.

    Since there is this 5 Gbps Java limitation, it does not matter if my instance has 5 GbE, 10 GbE or even 10 GbE * 4 like in the case with the c3.8xlarge instance. Am I correct in this, and the 4494 concurrent connections?

  7. #7
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    These huge servers might not be the best solution. An edge cluster can be many m1-small instances. Here is instance types to compare The throughput on smaller sizes is not specified exactly. You may only get 150mbs on an m1-small, but we do not have hard numbers because AWS does not publish them

    Richard
    Last edited by rrlanham; 01-23-2014 at 06:37 AM.

  8. #8
    Join Date
    Nov 2012
    Posts
    103

    Default

    These huge servers might not be the best solution.
    Why is that? Because of the fact that the Java limitation prevents the saturation of 10 GbE?

    Here is "]' to compare
    Should there be a link a here?

  9. #9
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    Here is the link to EC2 instance types

    Many smaller edges, if managed well, might be more cost effective, and is certainly more flexible. It is best to have uniform edge cluster, all edges the same size and approx throughput

    Richard

  10. #10
    Join Date
    Nov 2012
    Posts
    103

    Default

    ... if managed well ...
    And that's one of the reason I would prefer to stay on a single instance, as I then only have to monitor and maintain a single Wowza Server. One of the other reasons being that I would then avoid buying an excessive number of Wowza licenses.

    If one high performance instance like the c3.8xlarge can handle 4494 concurrent connections (see the calculations in #6), that is actually enough for us. But can it?

Page 1 of 3 123 LastLast

Similar Threads

  1. Live Record 1000 simultaneous streams
    By arpan_synapse in forum General Forum
    Replies: 10
    Last Post: 05-18-2014, 02:01 PM
  2. Eventstreaming for ~ 2000 Viewers
    By SilSte in forum General Forum
    Replies: 1
    Last Post: 10-02-2013, 06:32 AM
  3. Replies: 1
    Last Post: 04-09-2013, 11:16 PM

Posting Permissions

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