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 <[email protected]> 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
> >
> >
