BigBlueButton bandwidth and hardware usage

At our weekly meeting today there were 6 or so people, this is what the Munin traffic graph looks like for the meeting:

if_eno1-day

2 Likes

At the moment there are 42 people in the Open2020 room (the only room running on the server), there was a load spike up to 6 earlier (6 out of 48 cores fully used), committed memory usage has gone up to 25G (out of 96G available), I don’t think we are going to have any server load issues for this event, following are a couple of bandwidth graphs.

if_eno1-day

fw_packets-day

2 Likes

There were up to 46 users earlier, I see that they are switcing webcams off for people not speaking, the main resource usages seems to be kurento, freeswitch and node, I’ve add some graphs to the Munin output to track the processes using the most resources.

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                           
163336 kurento   20   0 30.364g 1.112g  23820 S  93.7  1.2  77:15.16 kurento-media-s                                                   
  2836 freeswi+  -2  19 7309012 347176  16004 S  73.5  0.4 144:03.13 freeswitch                                                        
  3923 root      20   0 1519796 254444  24624 S   3.6  0.3   9:33.37 node                             

These graphs should be more interesting later!

multips_memory-day

multips-day

Some more graphs, this is with around 50 users, bandwidth so far today:

if_eno1-day

fw_packets-day

CPU usage, basically it is the kurento-media-server and freeswitch that use a lot of CPU.

cpu_by_process-day

process_cpushare-day

And in terms of RAM it is java and the kurento-media-server:

multips_memory-day

But there isn’t a CPU shortage on this server:

cpu-day

And there is also plenty of RAM:

memory-day

3 Likes

A few more graphs from today, bandwidth:

if_eno1-pinpoint_1591852857_1591903752

fw_packets-pinpoint_1591855692_1591904022

RAM usage:

multips_memory-pinpoint_1591868813_1591904858

memory-pinpoint_1591859222_1591903637

CPU usage:

cpu_by_process-pinpoint_1591875962_1591904852

cpu-pinpoint_1591861382_1591899047

Note that some graphs above are for the whole duration of the meetings today where as some are just from when the graphs plugins were added to the server between 10am and noon.

Also note that I haven’t configured Munin on the TURN/STUN server yet.

2 Likes

The time is Montreal time, where the server is located, I assume?

No the times are UTC, the server generating the stats is in the UK.

lovely graphs - no idea what they mean - but glad we are helping u gather data! :wink:

3 Likes

Some Munin graphs from the 50+ people at the Open2020 meeting yesterday:

memory-day load-day cpu-day cpu_by_process-day fw_packets-day if_eno1-day

1 Like

There are 88 people in 4 rooms on ca.meet.coop at the moment for this event:

The server is coping without an issue, here are some munin graphs (the dip in memory usage on Friday was caused by me restarting everything after checking no rooms were in use and upgrading BBB in preparation for today):

multips_memory-day cpu-day memory-day load-day

fw_packets-day if_eno1-day

1 Like

I think the event today hit 110 mbit at peak:

if_eno1-pinpoint_1593257218,1593276928

1 Like

Thanks @Chris

I understand they ran one session in a “General” room in English and complemented with parallel rooms for the translations:

General: CommonsHorizons
Italiano: OrizzontiComuni [It]
English: CommonsHorizons [Eng]
Español: HorizontesComunes [Es]
Français: https://ca.meet.coop/b/mon-tlg-cbs
(or maybe finally it must have been one room less, if you spotted 4 rooms)

The people wishing translation needed to connect to two rooms, the General with the videos/whiteboard and muted audio, plus the translation room with listening only.

My colleagues mentioned that ideally they’d have the translation rooms configured as “listening only” without even passing by the echo test. Maybe an idea for future event services?

1 Like

I attended this session. There was a main room with ~80 users and 4 extra rooms that were used for translation and breakout sessions. Most of the time we had 6 or less video signals active. Overall quality was good and the issues we had (e.g. noisy audio signals) were apparently caused by poor connections or bad hardware on the client side.

Having the extra rooms for translations worked, but it was confusing for some people. Being able to open rooms in full listen-only mode would’ve made it easier. The ideal solution would be having multiple audio channels on the same room, but that would need significant development.

2 Likes

I also was in the session. I felt it worked well (congratulations, organisers :slight_smile: ) and switching audio on/off in two browser tabs (two room tabs) wasn’t difficult. Maybe for folks less used to juggling browser tabs in parallel, it could be a bit demanding or puzzling.

There might be a question here, of how much skill we assume exists in users, regarding simultaneously handling multiple tools in multiple windows (eg pads, webpages, BBB rooms). Our typical user will not be running two large screens, and might not even be able to run two browser windows on a single small screen (ie on a mobile device).

Perhaps we need to investigate what BBB feels like on mobile devices. For example, I find Firefox on IOS seems reluctant to access mic and camera.