up vote 0 down vote favorite
share [g+] share [fb]

I'm always asked this by potential and actual clients: how many streams can I run simultaneously?

I always explain that it's maxServerUpstreamBandwidth / (streamDownstreamBandwidth * numberOfStreams) theoretically speaking. In all actuality, it'll probably be less.

However, in real-world scenarios, it seems to be different; we seem to be getting more clients than what is theoretically possible.

For example, if I have a 1 megabit per second stream published to a server with a 100 megabit per second line, theoretically, I should be able to have 100 clients watch that stream at 1 megabits per second down each. This is crazy, 1 server only serving 100 clients!?!? I thus concluded that I must be doing the math wrong.

What am I missing here?

link|improve this question
81% accept rate
I'm kinda confused on where numberOfClients would come in. In my mind, numStreams = serverBandwidth / avgStreamBandWidth. – digitxp Aug 5 '11 at 18:06
That's what I mean, sorry, I'll edit it. – TK Kocheran Aug 5 '11 at 18:09
1  
I would assume it's a result of clients being slower than you would expect. A ton slower. – digitxp Aug 5 '11 at 18:15
3  
You didn't specify what exactly a "stream" is, e.g. what protocol you're using and on what kind network you're distributing on. There's something called statistical multiplexing where a pipe can be used to serve more channels than it theoretically can if not all the channels are transmitting at the same time. Almost all IP network is based on this. Alternatively you might be using something like multi-casting. – billc.cn Aug 5 '11 at 19:17
protocol: RTMP over TCP via Wowza. – TK Kocheran Aug 5 '11 at 19:18
feedback

3 Answers

up vote 1 down vote accepted

There's three factors that I see that will allow you to stream more streams than your theorectical number:

  1. There's less data being streamed than you think. A stream usually consists of compressed data, and some data is compressed more than others. So when you say it's a 1 megabit stream, that may be with worst-case compression (or maybe your 1 megabit number is uncompressed?). This will naturally be bursty, as the data stream changes over time the compression ratio will change. Other factors, such as paused streams can also reduce the actual rate.
  2. Clients have bottlenecks. Even if your server has a 100 megabit line, the client may have a slow internet connection (e.g. a shared wi-fi connection at a coffee shop).
  3. Auto throttling protocol. I don't know about your setup, but many streaming protocols will automatically adjust the stream rate when bandwidth is limited. So, (using your example) even if you can only handle 100 streams at 1 megabit, the system can handle more clients because it automatically drops to 0.5 megabit when 20 clients are connected.

This answer doesn't help you with your math (there is no hard numbers!), but it may be ammunition when describing the situation to your customers.

link|improve this answer
feedback
up vote 0 down vote

It seems foolish to think that everyone is going at the max pace all the time, and if another user wants to open a stream the server does not allow it. It just slows everyone down, creating the new bandwidth.

link|improve this answer
feedback
up vote 0 down vote

You are also dealing with overhead and other competing protocols and streams on that same pipe.

In your theoretical example you are dealing with a perfect environment in which there are no other requests using that 100Mbps pipe at all. In actual practice you'll never experience this. That 100Mbps connection is hosting all manner of chatty protocols between those hundred client computers.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.