.. Copyright (c) 2008-2016 OpenShot Studios, LLC
 (http://www.openshotstudios.com). This file is part of
 OpenShot Video Editor (http://www.openshot.org), an open-source project
 dedicated to delivering high quality video editing and animation solutions
 to the world.

.. OpenShot Video Editor is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation, either version 3 of the License, or
 (at your option) any later version.

.. OpenShot Video Editor is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.

.. You should have received a copy of the GNU General Public License
 along with OpenShot Library.  If not, see <http://www.gnu.org/licenses/>.

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: cloud-support@openshot.org.

Performance
-----------
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.

Instance Types
--------------
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.
=========== ==============

Auto Scaling
------------
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.