Autoscaling JVB on AWS

Install & Config
#1

Hello,

I have some questions about auto scaling JVB on AWS. We’re self hosting Jitsi on AWS and we want to support around 200 users in a single conference. Our use case is scheduled webinars where only a few people have video and speak and the rest don’t even have permission to enable their mic/camera.

Currently we have one c5a.large instance that’s running nginx, prosody, jicofo, and then we have one or multiple c5a.large instances for jvb. Jvb is in an autoscaling group and we scale up and down based on network out metric. We’re still testing what a good number is to scale out but currently we have set it to 250,000,000 for at least 2 minutes. Based on our use case we should plan for 200 users to join the conference almost simultaneously, however AWS needs at least 3 minutes to spin up a new instance of JVB. The problem is that even if a new jvb joins the pool, the participants that have joined before will stay on the first jvb and only new participants will be put on the new jvb.

So my questions are:

  1. What is a good metric to scale out jvb as soon as high load occurs?
  2. Is there any way to redirect already connected participants to the newly spawned jvb?
  3. Currently we’re using SplitBridgeSelectionStrategy, however I know that is meant more for testing so should we switch to IntraRegionBridgeSelectionStrategy? As I understand this splits participants based on bridge stress as well as config MAX_PARTICIPANTS_PER_BRIDGE. What would be good values for these configs?
#2

You can set 100 participants per bridge and have 3 bridges in advance. c5.xlarge bridges can handle 100 for sure and then scale up if stress goes up …

4Gb of ram for the signalling node in a loaded scenario, I’m worried is not enough, I would put there 8GB

#3

Thank you for your response. Is network out a good metric to scale up bridges?
Also how many conferences with ~200 users could a single signalling node with 8 gb ram handle?

#4

Its not the ram, its more the cpu as praody is single threaded… I would say 3 or 4 , … maybe more … this on c5.2xlarge, not sure what’s the cpu difference between 2xlarge and xlarge … and this with latest jitsi-meet we released …

#5

Thank you for yours answers.
I remember once that I read on this forum that you don’t host meet.jit.si exclusively on AWS anymore but you use another service provider for a part of it. Do you mind telling me which part is hosted at a different provider and which provider that is?

AWS is quite expensive for this use case so we’re thinking about using a different provider for most of the instances and then use AWS just for the scaled instances based on load (for example signalling node and 2 bridges on one provider and then additional bridges on aws if load increases even further).

#6

The bridges are in Oracle.