We have setup our own self hosted jitsi solution and we saw that our platform doesn’t support concurrent activities.
First we scaled our JVBs and switched from data-channel to websocket on our prosody and JVB connections. After that, everything is fine and with torture, we could test and make sure our system supports as many concurrent users as we need in large conferences. But since in the real world, meetings aren’t mostly that big, we are seeing issues when the same amount of users are in rooms of 3.
The problem is when we want to load test and add our desired amount of users with torture, it takes around 10 mins for all the torture users to enter the rooms and joining a room as a real person in that time, which normally takes under 5 seconds, is taking as long as 30 seconds to a minute.
Any ideas which part of the system might be not configured properly and what we could do to solve this issue?
P.S: we had few incidents in production level where the jicofo logged that it couldn’t see the JVB’s and our stats show that all conferences are dropped and the users are kicked out at the log time. That’s why we assumed either jicofo or prosody might not be able to process the load of users activity and it might infect the JVB healthcheck and since the jicofo assumes that the JVBs are not available, it starts dumping the users out.