[jitsi-dev] dev Digest, Vol 38, Issue 76


#1

The "videostreams" value you see in the COLIBRI stats is just an
estimation of the total number of streams the bridge forwards. It
doesn't take into account any receive-only endpoints (it assumes that
everyone is sending), so it grows quadratically as you observed (unless
you enable lastN).

Aha great, so it's not even a problem? So imagine i have 300 people, 1
sending webcam + screenshare, 299 receiving and watching without
sending anything. It will show 300*300*2=180000 'videostreams' and
that's still fine? I was worried about the number of threads in the
same colibri stats, which got over 400 with just 11 clients and 242 of
those virtual 'videostreams' in, which made an impression that each
that 'videostream' spawns a thread. Hope i am mistaken.


#2

The number of threads will grow with participants, but it should be linear. Definitely no new thread for each 'videostream', that's just a number we calculate for the stats.

Boris

ยทยทยท

On 23/05/16 09:28, Mikhail Novikov wrote:

The "videostreams" value you see in the COLIBRI stats is just an
estimation of the total number of streams the bridge forwards. It
doesn't take into account any receive-only endpoints (it assumes that
everyone is sending), so it grows quadratically as you observed (unless
you enable lastN).

Aha great, so it's not even a problem? So imagine i have 300 people, 1
sending webcam + screenshare, 299 receiving and watching without
sending anything. It will show 300*300*2=180000 'videostreams' and
that's still fine? I was worried about the number of threads in the
same colibri stats, which got over 400 with just 11 clients and 242 of
those virtual 'videostreams' in, which made an impression that each
that 'videostream' spawns a thread. Hope i am mistaken.


#3

The number of threads will grow with participants, but it should be linear.
Definitely no new thread for each 'videostream', that's just a number we
calculate for the stats.

Yeah thanks Boris, i will run another session of load testing today
and see how it goes


#4

Hi!

So far at anything over 40 participants in a room, it disconnects
participants faster than i am able to add new ones. They just randomly
disconnect.

It is not an artifact of testing, because testing is done from 2
identical servers, on each there are 20 viewers (each playing 2
streams - webcam and screen share). When i start first machine with 20
clients, it works rock solid, never dropping anyone, but as soon as i
add other 20 it starts dropping some of the users so it never even
reaches 40, and then they gradually drop until getting to as low as
32-34 or so, then working stable.

Sometimes attempting to get to 40 participants results in it reaching
about 36-38, holding steady for a few minutes, then dropping to 0 -
probably because the next randomly dropped user is the presenter, who
streams both videos up, so all streams cease, and all clients
disconnect.

What kind of information can i provide so you could give me an advice
where to go from there? Here is the client code i am using :
https://github.com/novikovmaa/demio_tmp/blob/master/app.js , it runs
in xvfb on Docker containers on a Packet.net type 1 server, 20
containers per server. I don't think testing server load is a problem
because again, with just 1 server everything works fine, problems
start when i add a second one.

When it is close to 40 connected users = 80 streams, it has about 2000
threads on the Jitsi server, based on that colibri stats tells me. Is
this OK?

Thanks for any ideas!

Mikhail