[Solved]Scaling Jibri

@yasen ,

Once again thanks for your valuable support. we successfully deployed Jibri with AWS auto scale environment. It works perfectly as expected.
except AWS instance lunch time was taken 90 seconds to be in service for new recorder available.

Regards,
Ram U

Yes, unfortunately using cloud instances will always lead to some longer boot time. Not only the infrastructure needs to provide the resources and the installed applications need to kick in, but it’s a whole OS that needs to be started in the meantime. So a minute or minute and a half is normal.

You can double check that you don’t have any unneeded software installed and running at boot time. Nowadays almost all the instance types are EBS-backed, the root volume is optimized for fast provisioning over network, it is a “virtual” disk and booting from there is managed by the AWS host machine(s). So there is not much more to do to speed it up.

In AWS the scaling groups always terminate the instances - this means that when you want to scale out, you will always provision the new instances from scratch - which is slower than just starting a stopped instance.

An (untested) hack that just comes to mind is to try to make the scaling group de facto stop/start the instances, instead of terminating/provisioning them - for example:

scale in:

  • put the instance in standby and stop the group health checks
  • stop the instance

scale out:

  • find a stopped instance in the group and start it
  • set it to “in service”

This will all have to be controlled by custom scripts, because like I mentioned ASG always terminate instances that are unhealthy or above the limits.

This is all untested! It is just an idea - if I have an option to test it someday, I’ll write again, but for now this is not an advice at all.

(P.S.: You can start/stop the instances outside ASG - manually or with scripts through the AWS API, then you won’t need to care about the scaling termination)

Another thing to consider - even if this works, I’m not sure whether AWS charges for the suspended/stopped instances or not. Generally all separate stopped instances are not being charged for, but I’m not sure if the same applies to instances in ASGs.

Even if this works, it will not gain you much boot time advantage.

If boot time is the issue, you should go the Docker way. It’s not a full virtualization, you don’t have a full server to provision and it’s a matter of seconds to have a new and ready to be used service.

1 Like

Hi @damencho It’s been a year after this question has been posted. Are there any improvements in Jibri recording to be cost-effective? Can we run more than one Jibri instance per 4 GB or is it still the same?

No change. It all depends on chrome and ffmpeg if they dropped usage of memory …

@damencho Alright. Thanks for the update.