Contents

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 Details

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)

Hardware:

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

Test Results

  • 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

I will delete this dashboard shortly again

Test1 Prometheus metrics dashboard

Graphs

CPU and memory usage

CPU and memory spike but no crash. Server seems to recover on the CPU.

Network usage

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"

log-events-viewer-result_media_state_audio.csv

Room1 (4users)

Room2

Room3

Room4

Room5

Room6

Room7

Room8

Room9

Room10

Webinar1 (21 users)

Webinar2 

Webinar3

Webinar4

Webinar5




  • No labels