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 syntaxerror...@libreoffice.org -- To unsubscribe e-mail to: website+unsubscr...@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