Performance issue with video conference
bli24 opened this issue · 8 comments
We are having trouble achieving the performance stated on this page, https://jitsi.org/jitsi-videobridge-performance-evaluation/. We have Openfire with the ofmeet and offocus plugin installed on a 16 core, 16GB RAM CentOS 7 server. With a 3 party video conference call, CPU usage is about 55%. We have also built the latest SNAPSHOT of 0.9.5 of ofmeet, and the result is about the same. If we run jitsi-hammer with 100 users on a call, the load average shot up to 26+. The Java thread count was about 1200.
For those of you who have similar installation of Openfire with ofmeet, what kind of performance do you get? If it's better, did you make any change to the configuration?
BTW, we have also tried a standalone installation of Jitsi Videobridge on a Ubuntu 16.04 server with 4 core, 8GB RAM. The performance is slightly better, but not much. 3-party video conference call uses about 45% of CPU.
Thanks for your help!
Please note that OFMeet was designed to provide ease of installation. Although it should perform well in a light to moderate usage context, it has not been designed for high-performance. For that, I recommend you use the stand-alone Jitsi components. Note that the Jitsi team has provided numerous resources that showcase how a very resilient, high-performant setup can be achieved.
@guusdk Thanks for your quick response. In my original post, I mentioned that we also tried the standalone Jitsi Videobridge with default installation/configuration. The result wasn't much better. Following your recommendation, we'll look into that again, and may seek help from the Jitsi team.
Good luck. Jitsi has a bunch of videos like these, which can be very helpful: https://jitsi.org/news/tag/tutorial/
We are having trouble achieving the performance stated on this page, https://jitsi.org/jitsi-videobridge-performance-evaluation/.
I don't think you can achieve those figures any more as they were done a while back before WebRTC 1.0 was confirmed. Since then, there has been default multiplexing on a single UDP port, H264 and VP9 video codecs to all take into consideration as far the server CPU load is concerned.
What happens to your CPU when you hit the magic 32x31 media streams and run out of bandwidth with a 1GB network adapter?
@deleolajide That's good to know. I wonder what kind of realistic performance data does the latest standalone Jitsi Videobridge have.
Good point on the bandwidth usage. There was some DTLS error when running Jitsi hammer against the ofmeet server. However, it did generate enough load on the server, without saturating the network based on iptraf. The main issue is that, even with a 3 party call on the standalone Jitsi installation, it was using 45% of CPU.
I was curious about the 45% CPU, so I ran a 3 person conference on my CentOS 7 server
I tried both top and mpstat. I can see Java (openfire meetings) consuming 34%, but I can't reconcile that with the CPU reported as being 99.xx% idle
Your server has 32 cores, 64GB RAM. With 33.3% usage by all the cores, it should be about 99% idle. On ours, Java CPU usage ranged from 3x% to 6x%.
Thank you for the explanation :-)