Re: [libreoffice-website] TDF Jitsi instance issues with 20+ people

Hi all,

I'm sorry if I am just replying to Florian's mail, but I will try to
take into account all feedback received until now.

Il 13/03/20 16:22, Florian Effenberger ha scritto:
> Disabling video did not help.

I don't know if that can help, but what came to my mind is that the
default settings for video in Jitsi is HD. Since there are no specific
options for the audio, I would expect that this quality settings could
have some impacts on the audio part of the stream as well. Decreasing
audio quality a bit shouldn't be an issue.

> I looked at the VM during the meeting and the load was at about 8,

To me, this is mostly in line with a 8 vCPUs machine at ~100% load.
I don't have hw specs of the machine, but I suspect this is really near
the actual status of the machine, showing that hw specs can be binding
here. Again, only a theory for the moment.

> suggesting we can pump up the virtual hardware and see how that goes.
> Another option is to host not at our datacenter, but at some cloud
> provider with different connectivity.

That's another point. More on this below.

> The official Jitsi instance seems - given the amount of home office
> workers at the moment - rather problematic from what I've heard.

Indeed, and the second most recognized one (Framatalk, as pointed out by
William) either :-/

> As it's hard to test meetings with 20 people

Well, I've seen also testrtc pointed out elsewhere, other than Thorsten
(btw, thanks).

> I'd propose
> - assinging more resources to the VM -> Cloph, can you have a look?
> (Guilhem is on vacation right now)
> - finding out if there was any major spike in traffic on the VM recently
> -> also Cloph, can you have a look?
> - have someone from infra on standby during the next meeting to live
> debug the issues

Mostly agree on these ones, although I would share some more ideas in
some lines :)

> - have a fallback plan to have a proper meeting

That's the difficult part. Should we use an audio-only conferencing
system based on a PBX or something like it, instead? Probably audio-only
streams are better optimized that way.

Now back to my findings. I've invested some hours of my time (and I will
do again this afternoon, if possible) on learning more on Jitsi and its
guts. My primary source of information at the moment are this video:
https://www.youtube.com/watch?v=Jj8a6ZRgehI

And the documentation bits on the GitHub project:
https://github.com/jitsi/jitsi-meet

My first take on this is that cascading (in the sense of deploying
multiple servers in different parts of the world) would not solve the
participants number issue per se; it will obviously help with the
general status of the conferencing system indeed.

We have already pointed out the two most probable source of bottlenecks:
* Network
* CPU

On the first point, guys at Jitsi recommend 10GE connectivity. This can
be a problem, usually with VPSes this is something that is sold at high
prices. Plus, they are leaving their video streams on, and they show
flawless behavior with 15 people or something like it. I would expect
that taking away video streams the numbers of participants could raise
easily to 2.5 times (e.g. 35 people), but my take might be completely
wrong (e.g. video streams are produced anyways just for the sake of
deliver the audio streams).

Second point: CPU. I have an additional input to this. Since I feel the
most of the CPU would have been taken by the Videobridge module (the
SFU, as pointed out by William), but not all of the CPU (jitsi-meet,
prosody and jicofo modules will take resources as well), could be an
idea to explore to separate the Videobridge module in a dedicated VM.

Additionally, I don't think adding another Videobridge would be of any
help: from my understanding, a single conference room is associated with
one and only one videobridge.

So for the CPU part what can be actioned to me is to take out the
videobridge component in a new VM with the same hw capacities as the
first one (we can scale it up as we scale down the main -meet machine,
as it will take less resources).

What do you think?

Cheers,
-- 
Emiliano Vavassori
syntaxerrormmm@libreoffice.org


-- 
To unsubscribe e-mail to: website+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy