Changes in this test
Compared to OpenMeetings 140 users test following changes:
- Reducing the N factor in Scrypt from 1024 * 16 to 256
- Change code in KStream::internalStartBroadcast to NOT stopBroadCast in case MediaFlowState.NOT_FLOWING and is of type Audio (Audio may stop flowing but stream might be still fine)
- Some minor change in Address DB object to add index on "email" to improve login query
Test run below:
- 145 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)
- 4GB OpenMeetings 1 core
- 4GB KMS 1 core
- No performance issues on login method
- Video pods mainly fine. Previously almost 50-70% of video pods in the conference rooms disappeared, cause you could see MediaFlowState.NOT_FLOWING Type Audio, while the stream was still working
Link to dashboard
CPU and memory usage
CPU and memory spike but no crash. Server seems to recover on the CPU.
Login and all web service calls are fine - under 0.25 seconds average duration
AddListener method takes up to 4 seconds
This leads to issues for participants. It takes quite a while when entering a conference room until the video stream starts.
Tomcat threads active - low utilisation
Screenshots from each room with Video Pods
Log events with Media Flow STATE NOT_FLOWING type AUDIO are working fine
There are almost 100 events of
"[34mINFO [0;39m 02-10 08:11:38.220 [36mo.a.o.c.r.KStream:160 [ventExec-e2-t48][0;39m - Media Flow STATE :: NOT_FLOWING, type MediaFlowOutStateChange, evt AUDIO, sid d6c5db69-0d30-4ba6-b863-aa3c297e17ac, uid 9ad475f3-e994-4850-97a3-3e3717bf755a"
=> However I just ignore them, and as you can see below, most videos are fine! There is no need to kill the video pod!
See full list of log with the "Media Flow STATE :: NOT_FLOWING, type MediaFlowOutStateChange, evt AUDIO"