Scheduling
OmniStream scheduling is how you manage the availability of your application while also keeping budgets in check. Using scheduling you can make sure streams are available near-instantly when required, and allow dynamic scaling to meet demand, while also capping the maximum number of available streams.
Simple capacity scheduling can be done through using the Boost functionality and more complex schedules can be arranged through your OmniStream account manager.
Boost
Boost allows you to set some streams to start coming online either immediately or at some point in the future and then stay online for a defined period of time.
To access Boost, click the "Boost" button located on each Render Service inside you Project in Portal.
This opens the Boost dialog, where you can enter the details for your Boost.
You can only have boost scheduled or active at a time. When you open the Boost dialog it will open showing the details that were last saved for that Render Service.
Boost Settings
Boost Start
The time your streams will be started. When setting this time, you need to take into account the amount of time it takes a stream to come ready, this varies per application and is usually a few minutes. For example if you want to be sure streams are ready to 10am you might schedule the Boost to start at 9:50am.
Boost Duration
The amount of time your Boost will be active for in hours. This must be a whole number of hours.
Number of Instances
The number of streams that will run for the whole of the Boost duration.
Additional Instances
If all of the streams specified by "Number of Instances" are in use by users then if additional users try and connect to a stream, up to this many additional instances will be started to meet this demand.
Boost Examples
Constant Boost
By setting the Number of Instances to 3, and the Additional Instances to 0 then 3 streams will run for the entire duration for the Boost. If more than 3 users try and connect, they will have to wait for one of the existing users to disconnect before they are able to obtain a stream. This sort of Boost would have a easily calculated cost as there is no dynamic scheduling.
Dynamic Only
It's possible to Number of Instances to 0, and the Additional Instances to 2. This would mean that is no users try and connect, no stream are started, if a user does connect then a stream will be started and the user will have to wait for the stream to be ready. Once a stream has started it wil keep running until the user disconnects then after the run on time you have specified it will shut down.
Modifying/Cancelling a Running Boost
If there is a Boost running that you would like to modify, then you can open the Boost dialog and make the changes you want and click "Apply" and this will be applied in a few seconds. You can use this functionality to remove a Boost by setting both Number of Instances and Additional Instances to 0. Any users that have already connected to streams will continue to be served until they disconnect, and then the streams will keep running until the run on time specified has elapsed.
Advanced Scheduling
While Boost allows for a number of scenarios to be catered for, if you require a more complex schedule then this can be arranged with your ZeroLight Account Manager. When arranging this there are a number of controls that can be set to give very granular control:
- “Maximum Instances” - The maximum number of streams that are allowed to be started during a schedule block.
- "Minimum Instances” - The number of streams that will be started at the beginning of a schedule block.
- "Minimum Free Instances" - The number of streams that are available for users to connect to. If all streams are in use, this will cause new streams to be started in preparation for more users to connect to.
These are all configurable per calendar hour and used to build blocks of schedules that can be repeated.
Scheduling Examples
Below are some examples that demonstrate how these controls can be used to balance stream availability and costs and also the close relationship between your schedule and the run on time you have configured on your render service.
Working Hours Only
If a Render Service was being used for internal testing or development, then it might be useful to set a schedule that only allowed a small number of streams during the working hours and no streams outside of this. To achieve this we would have 2 schedule blocks to be repeated Monday-Friday:
- 8am - 6pm - Maximum Instances 3, Minimum Instances 0, Minimum Free Instances 0
- 6pm - 8am - Maximum Instances 0, Minimum Instances 0, Minimum Free Instances 0
Up to 3 streams will be started on-demand when users ask for a stream during working hours. Outside of these hours, no streams will start and the users will not be able to connect. This will keep costs low, in exchange for a wait time when a stream is required. In this sort of schedule a long run on time might be desirable on the basis that when someone is actively looking at the stream, they're likely to be working in that area, possibly doing active development and will be needing to access the stream many times over the course of the day.
Peak Times Fixed Cost
In this example we know our demand peaks in the morning and afternoon evening, with a smaller amount during the day and little overnight. We'd like to always have at least 1 stream running, so serve users. In this example we'll set up this schedule to be repeated Monday-Sunday:
- 7am - 10am - Maximum Instances 10, Minimum Instances 5, Minimum Free Instances 3
- 10am - 4pm - Maximum Instances 5, Minimum Instances 2, Minimum Free Instances 1
- 4pm - 11pm - Maximum Instances 10, Minimum Instances 5, Minimum Free Instances 3
- 11pm - 7am - Maximum Instances 3, Minimum Instances 1, Minimum Free Instances 1
This means at 7am when the schedule starts, 5 streams will start and be ready for users shortly afterwards (depending on app time to ready). When the first user connects, they will be served a stream with in a few seconds. The same will be true for users 2-5, and when user 3 connects, the rule of Minimum Free Instances=3 wil trigger and a new stream will be started. The same will happen for users 4 & 5, so when 5 users are connects there will be 8 streams in total, with 5 serving users and 3 available for connecting to immediately by new users. This pattern will continue to a maximum of 10 running instances - so when there are 8 users connected there will be 10 streams and the Minimum Free Instances=3 will no longer be satisfied, as the system is constrained by the overall cap of Maximum Instances=10.
At 10am the schedule changes, and the number of running instances will be capped at 5 by Maximum Instances. If there are streams more than 5 streams running at 10am, they will continue to run for their run on time and then shut down, they will continue to run until a user disconnects and then shut down after the run on time. If demand continues to drop then more streams will shut down until the minimum of 2 and Minimum Free Instances 1 (so 2 users connected to streams would mean 3 streams running in total).
The 4pm-11pm schedule block mirrors the 7am-10am block, so will increase streaming capacity to a minimum of 5 streams with 3 free for users to connect to, up to an overall cap of 10 and the overnight schedule runs a really minimal schedule of 1 stream with 1 free and a maximum of 3 streams.
In this sort of schedule a very short run on time is probably desireable as the schedule is tightly controlling when streams are available, so it might be preferable to have streams shut down as soon as the schedule says.