Performance / Scaling¶
OpenShot Cloud API was designed with scalability in mind. When configured correctly, you can achieve huge and rapid scalability on cloud infrastructure. This topic can get very tricky though, so feel free to send an email to discuss your specific application: firstname.lastname@example.org.
The performance of video exports/renders is highly dependent on CPU and Memory. Ideally, you want as many CPUs and as much memory as you can afford. A general rule of thumb is the average render takes about as long as the video length. A 60 second 1080p video will usually take around 60 seconds to render. If you have a more powerful EC2 instance type, and/or are rendering at a lower resolution, it will be faster than real-time. On a slower instance type, it will be slower than real-time.
There are a large number of possible cloud instance types and sizes, and some of them perform very differently than others. Here are some recommendations that work well for OpenShot Cloud API. In general, we recommend the compute optimized instance types.
AWS Instance Types
|c5.xlarge||Lower cost, but slower than real-time performance|
|c5.2xlarge||More expensive, but good performance (maintains real-time performance for most exports)|
|c5.4xlarge||Best performance and very expensive (faster than real-time performance)|
|c5.9xlarge||Similar performance to c5.4xlarge, but twice the price. Not recommended for that reason.|
Azure Instance Types
|F2s v2||Lower cost, but slower than real-time performance|
|F4s v2||More expensive, but good performance (maintains real-time performance for most exports)|
|F8s v2||Best performance and very expensive (faster than real-time performance)|
|F16s v2||Similar performance to c5.4xlarge, but twice the price. Not recommended for that reason.|
Both AWS and Azure offer auto scaling solutions (each with slightly different features, but generally they work about the same). Configure a sever and a separate worker. Configure auto scaling on the worker instance, and base it off of average CPU > 50% for X minutes, or the number of messages in the Queue (SQS or Azure Queue Storage). As your video export jobs queue up, more and more worker instances will come online and help render jobs. Once the workload has ended and the queue is empty, the pool of worker instances can shrink back down to 1.
This is an effective strategy for managing costs (i.e. keeping as few workers running as possible), but quickly scaling up as needed.