I have to admit I’m a bit baffled that the solution here is to analyze the variety of high-memory/performance impacting Jisti processes and go through a process of experimentation to disable these and see what works. IMO the Jitsi defaults should be prioritized to minimize performance issues and there should be a config UI for users to opt-in to whatever features these performance-impacting configurations support. Would love to contribute that, but I’m not a Java guy.
I’ve just set up docker-jitsi-meet on a Debian 9 2 core 4GB VPS. I had a 10 person call with multiple OS’s and browsers and two participants on macbooks had high CPU usage with one crashing his machine and being unable to join the call. The tile view would also constantly switch between video and the black/profile placeholder for most of the users.
I don’t even have a macbook, the users are non-technical, and I’m not in a position to get them back on the line and have them troubleshoot the issue with me using dev tools (much less get 10 people back on the line for apples-to-apples testing).
I was really hoping Jitsi would work well enough out of the box for up to around a 10 person call given the above specs and default configuration - or at least that there would be a clear and documented manner for a configuration that prioritized usability. As it stands, my participants gave the experience a 5/10.
I guess I’ll give Big Blue Button a try.