I think that’s just a general testing framework for Jitsi, not a load generator.
50+ users on Jitsi is a challenge, though. You’d need a pretty beefy server to handle it, and even then it might be pushing some limits. I think the usual advice for giant meetings is to stream the meeting to YouTube and have view-only participants watch there.
You should also look at the “Last N” config options for that many users. Instead of everyone streaming their video up, it (theoretically) organizes people by who spoke last, and only the last N users send video up - other users effectively have their video stream auto-muted.
If only a few people are streaming content at once, you should be fine - I’d look at something like 4vCPUs and 4GB of RAM to be on the safe side, but I’d expect it to handle it. It’s when you try to have 50 people all pushing video/audio up that things get a mess.
But “stress testing Jitsi” is definitely an open question at this point.
Guys, having experience many issues with JIBRI the only way you can reliably test and reproduce “real world” experiences is through multiple VMs, as “people” are not great when you want to test out of hours.
To reproduce some recent issues I bit the bullet and built & replicated over 40 VMs, 30 win10s and more of mixed Linux desktops etc. All have OS + 4 or 5 browsers, OBS and virtual microphones. I have a couple of dedicated desktop Win10s that “present” (by running multiple videos on loop through OBS & virtual mic) and control the meeting participants etc. All browser sessions run virtual camera & are can be set to an image/multiple image show/videos etc.
All VMs spread over multiple servers/IPs and 10GB connections.
Each VM can handle 2 same-browser sessions to each test (or live) install of jitsi/jibri - can multi-stream to YouTube/Private Web Site/Facebook etc simultaneously. Happy to organise tests of environments if required - get in touch.