...

Compared to OpenMeetings 140 users test reducing the CPU value for the Scrypt implementation from 1024 * 8 to 256. 

Test Details

Test run below:

• 140 users
• staggered to enter in a time period around 5-10min
• distributed into
  • 10 conference rooms 4x4 = 40 users

...

• • 5 webinars with

...

• • 21 users each =

...

• • 105 users
• Each test runs calls the API to login/createRoomHash and then load the URL with the room (plus start webcam/audio stream in the conference rooms)

Hardware:

• 4GB OpenMeetings 1 core
• 4GB KMS 1 core

Test Results

• Reduces the login command to perform without any increase. It's completely gone from being a problematic call.
• However now the StreamProcessor::onMessage shows a curve and sending a single message in this method takes out of sudden almost 1 second. This wasn't previous the case. It seems like we moved the bottleneck to the next level. We speed up the login command but now, because login is much faster, the next method becomes problematic

...

• There are still lots of video pods not triggering.
• CPU still spikes to 95%. Same profile

Link to dashboard

Test1 - Prometheus Dashboard with metrics 

Test2 - Prometheus Dashboard with metrics

Graphs

CPU and memory usage

Login web service call is fine all web service calls are fine

None of the calls take longer than 0.35seconds. That seems okay

...