I was able to fix the missing Video Pods issue. And I think it was a successful test with 140 users.
See: https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+140+users+test+10-02-2021+with+256crypt+and+FLOW_STATE+fix+for+not+terminating+AUDIO Fixes in the branch I was testing: - The previously described fix to reduce the N factor in SCrypt calculation - The previous fix for adding some DB INdex on Address.email column And also in this one: Fix for not calling "stopBroadcast" when MediaFlowState.NOT_FLOWING is of type AUDIO. => I discovered in previous tests that there are almost exactly the amount of video pods missing compared to the log event: [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 I think AUDIO can stop flowing! there is no need to kill the stream in this scenario. To test and verify I updated my performance investigating branch to modify and add && MediaType.VIDEO == evt.getMediaType(): before https://github.com/apache/openmeetings/blob/feature/OPENMEETINGS-2567-investigate-performance-monitoring/openmeetings-core/src/main/java/org/apache/openmeetings/core/remote/KStream.java#L162 And I repeated the 140 user test and it's fine now! (well a lot better!) During this test there were almost 100 "Media Flow STATE :: NOT_FLOWING, type AUDIO" events BUT as you can see in the screenshots most video pods are fine: https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+140+users+test+10-02-2021+with+256crypt+and+FLOW_STATE+fix+for+not+terminating+AUDIO#OpenMeetings140userstest10022021with256cryptandFLOW_STATEfixfornotterminatingAUDIO-ScreenshotsfromeachroomwithVideoPods There are other issues :) There is a low percentage of video pods hanging (see screenshots on some pods). But previously those pods were completely missing and the ratio of pods missing was 50-70%!! => So I still call this a success :) Since it's a massive improvement from the results before. I will raise a separated PR for discussing lowering the SCrypt value (1) and how to address the issue around MediaState.NOT_FLOWING and type AUDIO to not close the broadCast in those cases (2). Unfortunate NOT_FLOWING for type AUDIO, I'm not sure but we may not be able to use this. I can also remember from the past that gaps in Audio streams can happen in a normal streaming scenario. Cause streaming tries to save bandwidth. So NOT_FLOWING for Audio may actually not mean anything. Thanks, Seb Sebastian Wagner Director Arrakeen Solutions, OM-Hosting.com http://arrakeen-solutions.co.nz/ https://om-hosting.com - Cloud & Server Hosting for HTML5 Video-Conferencing OpenMeetings <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url>
