Autoscaling Recommendations

Hey Devs,

I am creating this topic inspired by the topic AWS Scalability Help for Jitsi and Jibri. I posted the question there but it seems like that is not getting enough attention.

I have an idea about auto-scaling on AWS but considering the data transfer cost on AWS, I am planning to work on a custom auto-scaling solution for Digitalocean. I could not find out a convincing workflow on DO for auto-scaling. I have some questions about the model meet.jit.si uses.

  1. Is there any specific reason for using NetworkOut for scaling meet.jit.si? Is it fine if we use CPU utilization? What is your recommendation?
  2. AFAIK, AWS will take some time to spin up the new servers. What if a number of requests come in for the meeting creation simultaneously? Is there a chance that those meetings start on available JVBs and the server crashes when more members join?
  3. On average, how many users c5.xlarge system can handle for a single session (all are using chrome, video is on)?
  4. Is it possible to span a meeting across multiple JVBs? For example 50 users on one JVB and 25 users on the other one, both are in the same meeting.
  5. Is there anyone running Jitsi on DO with auto-scaling?

Thanks in advance!

1 Like

damencho - could you please point me to the right direction?

We have moved to using the system load for scale out, rather than NetworkOut. We use custom cloudwatch metrics to track this value, and scale up around an average system load of 2 on a 4-core instance type (c5.xlarge). We don’t have great values for how many conferences/users a single JVB can take, as it depends on the size of the conference. Using octo you can split participants across JVBs.

1 Like

Thanks much @Aaron_K_van_Meerten. Could you help me with the following point too?

I am working on a script to autoscale JVBs on Digitalocean. Your inputs are gonna help me to build a stable set up.

Also,

Does it mean that the CPU is overloaded by 100% (200% utilization)?

No, this is the system load metric, (seen from the “uptime” command, for instance). It’s actually the number of processes waiting on CPU. So for a 4 core instance, load of 2 is approximately 50% utilization across all cores. However, load is NOT exactly just CPU utilization, as it takes into account waiting on other resources such as network or disk I/O. We found that using CPU directly wasn’t as good as using load, for estimating to autoscale up.

1 Like