[Solved]Scaling Jibri

Hi,

I have a docker setup and have successfully integrated jibri in my setup. I can record videos although only one at a time. So, I tried scaling up my jibri containers and ended up having 5 of them running simultaneously, which kills my free tier ec2 server. So, that got me wondering about my use case of having 100s of jibris running together to record calls simultaneously. Is it viable. If so, i found that jibri consumes a lot of resources. It spawns a chrome and ffmpeg together. I don’t know how my 1 GB system handled one of them, but even if i can get an instance with 8 GB ram, what’s the approximate maximum number of jibris i can spawn without killing my system? If jibri seems impractical for my use case, is there any other way i can save my recordings, i was thinking i can stream them to youtube and save there.

This uses the same jibri you have for recording.

I would say for running chrome you need at least 2GB, and running the rest you also need RAM, so I would say 4 as a minimum.

You can always create auto-scaling rules and spin up jibri instances on-demand and scale them down when they are not used, not sure how this is done with containers though … but this is what we do with VM jibri instances in aws.

4 GB per jibri instance seems a lot. I can auto scale with containers as well, but this process seems much costly than i figured it would be. Isn’t there a way where we can use the same chrome and ffmpeg to record multiple sessions? Also, does autoscaling mean that for every call i will have a jibri instance, and with a minimum 4GB required per instance, for 100 calls i will end up having 100 instances :no_mouth:

Nope.

Yes.

Ok, thanks for the help @damencho

@damencho can u elaborate more on this?

we are using jibri on aws gpu accelerated instances (running multiple jibris per one ec2 instance) with somehow manual scaling… how do you get the number of idle/busy jibri instances? do you count idle jibris in jibri brewery room and based on that number you spin more VMs? if possible, can you share some of the code that is behind this?

we basically need to know whether there is some meeting running and how many jibris are currently occupied. i’ll be glad if u can point me somewhere…

You can do a local http query for the status of jibri and report it to cloudwatch and base your autoscale logic based on the number of used/free jibris.

Thanks a lot, your tip to use api request to jibri http api simplifies whole thing a lot…

I guess than, that basically you have some cloudwatch agent present on each jibri instance (i suppose one jibri instance per ec2 instance) and you collect results from jibri api call via this agent to cloudwatch and then you have defined autoscaling(?) group in aws, that you scale up/down based on count of used/free jibris through cloudwatch thresholds or something like that. Am i guessing right?

Correct.