Hello Denis, please let me know if 10 users in the room will be OK we need to change the way cluster works in case current configuration is not stable/powerful enough
On Thu, 22 Oct 2020 at 13:33, Denis Noctor <[email protected]> wrote: > Actually... this is something that had crossed my mind recently. > Previously, I’ve had on average 5 users per group... but on occasion if > there more than 5 users (in and around 7-10) some users... some would > intentionally drop drop their cam... and sometimes mic... (I thought it > might have been due to bandwidth issues on their side)... but I’ve got my > own kids taking online classes via their schools... whereby there are a min > of 20 attending a class and so on (different platforms etc.) > > I have about a combination of 5 to 6 computers at home due to home office > / covid restrictions etc. and am happy to log in to either the OM demo > sites or others to try replicate this scenario. (and my own, of course). > > Yep, I’ve been reading up on WebRTC and Kurento regarding connectivity > limitations regarding audio and video... this has been covered a lot > recently in previous posts in this forum... and from memory it is somewhere > between 200-300 connections... (per server? / instance?) > > For example... if you have 5 users in a room (using audio and video) this > will result in 5 (users) x 5 audio connections x 5 video connections... > giving “125” connections... but if you have 7 users in a room receiving and > experiencing audio and vid... that is 7x7x7= 343 connections... which > obviously exceeds the connections as per previous posts. > > I have had a scenario whereby 3 classes were held at the same time on the > same AWS instance... and nobody has reported a problem (yet... or they > unknowingly downplayed it due to internet bandwidth problems etc.)... but > the max number of students per room has been 4-5.... > > I am happy to test this more with others, if you are up for it and am > watching this carefully. > > I have a scheduled meeting with 10 participants next week and am now > nervous... and curious to see how it works out. > > Talk soon. > > Denis > > > > Sent from my iPhone > > > On Oct 21, 2020, at 7:57 PM, dww <[email protected]> wrote: > > > > Does anyone have an idea why the client browser seems to limited to 5 > > video pods when each user connects with both video and microphone. > > > > It seems to definitely max out the CPU(s) on the client computer. How > > do other applications like Zoom or Microsoft Teams get around this > > issue. Do they throttle back the streaming of the video pods or views > > of many or most of the pods and do it in some kind of round-robin > > update? > > > > Am I just doing something wrong. > > > > Any response would be appreciated. I would like to start uses OM for > > meetings next month. > > > > Thanks, > > Dennis > > > > > >> On Sun, 2020-10-18 at 17:40 -0400, dww wrote: > >> When creating 3 guests on each of 2 other laptops that I run into the > >> same issues,so it seems that the main limitation is the number of > >> video/audio pods within a client. Is there anyway to get around that > >> as > >> it implies that one annot have more than 4 or 5 guests with both > >> video > >> and audio? > >> > >> Dennis > >> > >> > >> > >>> On Sun, 2020-10-18 at 13:00 -0400, dww wrote: > >>> Yes I get the same result, however, this does not appear to be a > >>> valid > >>> stress test of kms. This stress tests a client machine with > >>> multiple > >>> tabs or browser windows each with connections and determines that > >>> it > >>> is > >>> CPU bound. > >>> > >>> It seems the only way to stress test kms is to do this with > >>> multiple > >>> client machines. I have 3 laptops here and a couple of smart phones > >>> so > >>> I will try distributing the client windows among all of them. > >>> > >>> Dennis > >>> > >>>> On Sun, 2020-10-18 at 10:56 +0700, Maxim Solodovnik wrote: > >>>> I'm on Ubuntu 20.04 desktop? so i can use UI > >>>> if you are using server I would recommend `htop` > >>>> > >>>>> On Sun, 18 Oct 2020 at 10:54, dww <[email protected]> wrote: > >>>>> May I ask for your linux command line that got the CPU > >>>>> percentage > >>>>> for all cores? > >>>>> thanks, > >>>>> Dennis > >>>>> > >>>>> > >>>>> > >>>>>> On Sat, 2020-10-17 at 12:59 +0700, Maxim Solodovnik wrote: > >>>>>> Hello, > >>>>>> > >>>>>> i just have tried the following script > >>>>>> started as `./run10.sh 5` > >>>>>> > >>>>>> everything seems to work, but my CPU was 800% busy (all cores > >>>>>> were 100% busy) > >>>>>> > >>>>>> without `--use-fake-device-for-media-stream` parameter I had > >>>>>> lots > >>>>>> of permission errors due to camera was "captured" by first > >>>>>> browser > >>>>>> other have reported "Camera busy" error > >>>>>> > >>>>>> > >>>>>> _HASH_HERE_ - should be replaced with real hash (I have > >>>>>> created > >>>>>> endless invitation hash to the private conference room) > >>>>>> > >>>>>> the script > >>>>>> =============================================== > >>>>>> #!/bin/bash > >>>>>> > >>>>>> i=$1 > >>>>>> > >>>>>> if [ -z "${i}" ]; then > >>>>>> i=30 > >>>>>> fi > >>>>>> let "i += 0" > >>>>>> > >>>>>> rm -rf /tmp/delme* > >>>>>> > >>>>>> while ((i--)); do > >>>>>> #echo "${i}" > >>>>>> mkdir /tmp/delme${i} > >>>>>> > >>>>>> #local conference > >>>>>> chromium-browser --user-data-dir=/tmp/delme${i} --disable- > >>>>>> infobars --no-default-browser-check --allow-insecure- > >>>>>> localhost > >>>>>> -- > >>>>>> use-fake-device-for-media-stream ' > >>>>>> > https://localhost:5443/openmeetings/hash?invitation=_HASH_HERE_&language=1 > ' > >>>>>> & > >>>>>> done > >>>>>> > >>>>>> On Fri, 16 Oct 2020 at 09:10, dww <[email protected]> > >>>>>> wrote: > >>>>>>> I mentioned earlier that I wanted to experiment with > >>>>>>> clustering > >>>>>>> using > >>>>>>> docker swarm for the kms service. > >>>>>>> > >>>>>>> I wanted to establish a base line using one container for > >>>>>>> kms. > >>>>>>> All the > >>>>>>> components are in one Linode with 8 GB of RAM. > >>>>>>> > >>>>>>> For this experiment. I start entering the video and > >>>>>>> whiteboard > >>>>>>> room > >>>>>>> from my admin login from Firefox on one laptop. I allowed > >>>>>>> both > >>>>>>> video > >>>>>>> and microphone and the video pod was the lowest resolution. > >>>>>>> I > >>>>>>> generate > >>>>>>> a guest url to the room. > >>>>>>> > >>>>>>> On another laptop also on the same connection to the > >>>>>>> internet > >>>>>>> I > >>>>>>> enter > >>>>>>> the room on firefox and allow both video ( lowest > >>>>>>> resolution) > >>>>>>> and > >>>>>>> microphone on a new tab each time. > >>>>>>> > >>>>>>> Up to 4 guest clients load quickly and the pods are created > >>>>>>> almost > >>>>>>> immediately on all 5 tabs. On the first attempt on the 5th > >>>>>>> guest the > >>>>>>> pod for this guest on the admin laptop took a couple of > >>>>>>> minutes > >>>>>>> to load > >>>>>>> the video. On the 5th guest tab, the pods for guest 1, 2 > >>>>>>> and > >>>>>>> 4 > >>>>>>> would > >>>>>>> not refresh( pod frames present but no video. > >>>>>>> > >>>>>>> RAM and CPU usage was not significant on the server. > >>>>>>> > >>>>>>> I closed the tabs for all the guests and redid the > >>>>>>> experiment, > >>>>>>> The > >>>>>>> first 4 guests again loaded quickly without any issues. The > >>>>>>> 5th > >>>>>>> guest > >>>>>>> loaded to completion but took about 40 seconds for all 6 > >>>>>>> tabs > >>>>>>> to > >>>>>>> complete. On the 6th guest there were multiple connection > >>>>>>> drops > >>>>>>> and > >>>>>>> retries and the tabs were reduced to about 3 pods working, > >>>>>>> the > >>>>>>> others > >>>>>>> gone, this was on all tabs. > >>>>>>> > >>>>>>> So based on this it seems that up to 5 users using both > >>>>>>> video > >>>>>>> and > >>>>>>> microphone seem to work fine. > >>>>>>> > >>>>>>> Does this agree with anyone else's experience? I had from > >>>>>>> other > >>>>>>> posts > >>>>>>> that we can expect 14-15 users per kms instance. Does both > >>>>>>> laptop on > >>>>>>> the same network have any influence on this? > >>>>>>> > >>>>>>> I will try a swarm next after I gets some feedback. > >>>>>>> > >>>>>>> > > > -- Best regards, Maxim
