However, Denis, I think your experiment with multiple devices would be
valuable as then there is only one browser tab or window with the OM
room open as a guest on each device. Perhaps that will make a
difference.
Dennis
On Wed, 2020-11-11 at 08:24 -0500, dww wrote:
> Thanks, Denis,
>
> Back on Oct. 17 Maxim provided the following Bash script to be run on
> the machine with a client side browser for the psuedo guest users. (
> Use another machine to create the room administratively and send
> invitations) This is a far simpler way to stress test the client side
> browser.
>
> Dennis
>
> 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 Wed, 2020-11-11 at 01:53 -0600, Denis Noctor wrote:
> > Hi there everyone, this seems to be the “elephant in the room”
> > discussion, while there has been a HUGE amount of development and
> > progress in OM since March (thank you so much @Maxim) ... there is
> > the whole issue of, for example, the number of users per room...
> > which seems to be about 5-6 (and maybe even to 7) when pushed to
> > the
> > limit... with both audio and video being broadcasted from all
> > users... and, something else.. if there are simultaneous
> > classes/sessions being held on the same server... will this
> > restrict
> > things even further? Is this an overall limitation to using a
> > browser
> > based approach... or should we be taking approach?
> >
> > It was my intention to test out the OM “demo servers” over the last
> > 2
> > weeks but will take today off and try to test 10 real device
> > connections... with a combination of desktops, laptops, android
> > tablets and maybe even the odd iPhone or two.
> >
> > My million dollar question is... prior to WebRTC and Kurento... was
> > it possible to have 5-10 users in a room with audio and video
> > working
> > seamlessly in previous versions (for example, the old “flash” setup
> > (which will be redundant after Christmas... Chrome etc
> > notifications)
> > and if so, what has changed?
> >
> > If there is anyone out there that has no problem with user numbers
> > (using audio and vid)... exceeding a body of 7-10+, please let us
> > know.
> >
> > In the meantime, I’ll give you my feedback on my tests.
> >
> > I really appreciate everything that has been done to date.
> >
> > Thanks.
> >
> > Sent from my iPhone
> >
> > > On Nov 9, 2020, at 4:50 PM, dww <dwort...@mykolab.com> wrote:
> > >
> > > Hello Maxim,
> > >
> > > A couple of weeks ago there was an email thread about the 5 total
> > > users
> > > for one room, each user with video/microphone under the
> > > Subject: "docker container clustering experiments #1". In this
> > > case
> > > it
> > > appears the bottleneck is the CPU usage on the client machine
> > > with
> > > the
> > > browser.
> > >
> > > In a response to Denis Noctor on a similar thread you mentioned
> > > to
> > > try
> > > the following:
> > >
> > > "please check allowed amount of opened files for the user who
> > > starts
> > > OM/KMS/TURN
> > > increasing it might help"
> > >
> > > Might this help with the issue we discussed? Where approximately
> > > do
> > > I
> > > set the allowed amount of opened files?
> > >
> > > Also are there any other things that can be tried to improve this
> > > scalability? Are there areas in the code that can be examined to
> > > investigate how to improve this?
> > >
> > > Thanks,
> > > Dennis
> > >
> > >
