Thanks for participating in the audio stress test this morning at 9am.
Here's a summary of the results.
Caveat: Each server is different -- virtual vs dedicated, # of cores,
hyperthreadig, and memory -- so take this test as a data point. Your
mileage will vary.
Server:
Core2Duo E8400 Dual Core running 4G (dedicated server). This server
has Hyperthreading, so it reports 8 cores.
Software:
FreeSWITCH 1.0.6
red5 0.91
Internal build of BigBlueButton 0.8 using 16khz wide-band speex
(encode quality of 6).
Heres a breakdown of the sequence of test. Note: We actually started
the testing at 9am EST, but the time on the graph is skewed, so I'll
summarize the results based on the graph (see attached image).
7:48 -- We had 20 users in voice with ~30% CPU
7:57 -- We had 40 users in voice with ~45% CPU
8:05 -- We had 60 users in voice with ~70% CPU
8:08 -- We had 80 users in voice with ~90% CPU <-- Audio stared to degrade
We roughly had about 30 real users running BigBlueButton, spread all
over the world, so to get to 60 and 90 BigBlueButton sessions, we
asked everyone to open additional browser tabs. To the BigBlueButton
server, each browser tab is a distinct user.
At 80 users the overall CPU (average of all 8 cores) was at 90% CPU.
At this point, FreeSWITCH starts to have challenges decoding/encoding
speex, and the audio started to degrade. We dropped the number of
users back to 60 (by closing some browser tabs), and the audio
returned to normal. We then asked everyone to open a webcam .
8:09 -- We had 80 users in voice with 20 webcams with ~70% CPU
At this point, we had 60 users with 20 simultaneous webcams (see
attached screen shot), audio remained good. This makes sense because
there isn't much additional CPU processing required for the video
packets: they are just broadcasted out to users. We then started
desktop sharing, which triggered a crash of red5. We've opened an
issue for this at
http://code.google.com/p/bigbluebutton/issues/detail?id=910
We're definitely going to look into why desktop sharing caused red5 to
crash with 60 users.
In summary: the purpose of this stress test was to test the audio, and
remote users reported the audio was good for 60 simultaneous users,
and it remained good when we started up 20 webcams.
In observing the bandwidth with small number of users, we estimate
each audio connection requires roughly 60 Kbits/sec to transmit to the
server, and 60 Kbits/sec to receive. So, here's how the bandwidth
scales for audio.
1 60 0.06
2 120 0.12
3 180 0.18
4 240 0.24
5 300 0.30
6 360 0.36
7 420 0.42
8 480 0.48
9 540 0.54
10 600 0.60
20 1200 1.20
30 1800 1.80
40 2400 2.40
50 3000 3.00
60 3600 3.60
70 4200 4.20
80 4800 4.80
The first colum is # of users, the second is Kbits/sec bandwidth, the
third colum is Mbits/sec. So, for 60 users the server had roughly 3.6
Mbits/sec transmission and 3.6 Mbits/sec receiving.
Thanks again to everyone who participated. Here's some locations for the users:
Chahira - 09:13 : Bonn, Germany
Chris K - 09:13 : Dearborn, Michigan
Dave - 09:13 : Ottawa, Canada
David Butler_Chrome 2 - 09:13 : Switzerland
Dip - 09:13 : Near Boston
Fred - 09:13 : Ottawa, Ontario, Canada
Gerry - 09:13 : Ottawa
HostBBB - 09:13 : northern maine
Kako - 09:13 : La Serena, Chile
Leonardo 2 - 09:13 : Brazil, Porto Alegre
Nelson - 09:13 : Toronto, Canada
Ophileonb - 09:13 : Netherlands that is
Pascal St-Jean - 09:13 : Ottawa, Ontario
Ravi - 09:13 : Abuja , Nigeria
RobertPlummer - 09:13 : Midwest - USA
Shylesh - 09:13 : Hong Kong
Suzanne Cadwell - 09:13 : durham, nc, usa
Séverin TERRIER - 09:13 : Toulouse, France
Tom C - 09:13 : Waskom Texas
hans - 09:13 : Netherlands
james - 09:13 : Winston-Salem NC
kimberly - 09:13 : Ottawa
ranjeev - 09:13 : Nice, France
susana2 - 09:13 : Ottawa
trevor - 09:13 : Ireland
Regards,... Fred
I'll let some of the other users post their response.
> Also, I'm confused about the server's CPU.
1 CPU, 4 cores with hyper-threading, so the OS reports 8 cores. See
http://en.wikipedia.org/wiki/Hyper-threading
Regards,... Fred
> --
> You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
> To post to this group, send email to bigblueb...@googlegroups.com.
> To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
>
I was thinking about your question early this morning ... the server
was reporting 8 cores, but the specs for E8400 are dual core. Turns
out you were right!
After double-checking, I realized my mistake. The server we used for
the voice testing yesterday was running a Xenon 3450 quad core running
2.66 Ghz. It has hyper-threading, and thus the OS reports 8 cores.
Thanks Andrew!
Regards,... Fred
There is a solution.
Putting on my Blindside Networks hat for a moment, we have developed a
commercial load balancing server for BigBlueButton that we are
currently using to scale BigBlueButton in the way you described.
If a university or college want to use BigBlueButton for thousand of
students, they should be achieving a significant cost savings over
commercial solutions. (Just like Moodle and Sakai help them reduce
their costs over commercial LMS systems)
For a university or college to use BigBlueButton for thousands of
students, they need three components (I'm simplifying here, but these
are the core):
1) BigBlueButton must have the features they need (such as record and
playback) and it must be solid, really solid
2) Load balancing
3) Commercial support
Yourself Josh, and everyone else who uses BigBlueButton, are counting
on us to deliver (1). Along with other very talented open source
developers, we've been working hard on BigBlueButton for over three
years to achieve that goal. We're not going to let you down.
(2) and (3) are funding our efforts to achieve (1).
I want to emphasize the BigBlueButton ecosystem is not just Blindside
Networks. Today, if you need commercial support and hosting, you can
contact any one of the companies listed at
http://bigbluebutton.org/support.
Others may develop open source solutions for load balancing. And
that's OK as well (just don't ask us to help you do it :-). The
developers working on BigBlueButton -- whether from Blindside Networks
or other companies -- are all entrepreneurs. We are working hard to
create a complete solution for real-time distance education, and if we
can achieve that, everyone wins.
Regards,... Fred
If you can help implement it, patches and pull request
(http://help.github.com/pull-requests/) are welcome.
Richard
> --
> You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
> To post to this group, send email to bigblueb...@googlegroups.com.
> To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
>
--
---
BigBlueButton
http://www.bigbluebutton.org
http://code.google.com/p/bigbluebutton
--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-dev/-/BE2RWD8sXcIJ.
--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-dev/-/pyp3HI3b8jsJ.
To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-dev/-/XF68755ebzQJ.
To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-dev/-/LHKqv4C1oscJ.
hi
<action application="conference" data="[bridge:]confname[@profile][+[pin][+flags{mute|deaf|...}]]">