Elastic Instance Management¶
Before you can publish your applications for use by your team, you have to first set up one or more pools of production instances – this defines the “capacity” of your account. You can set up your system capacity to scale dynamically based on user demand. Elastic Instance Management or “elasticity” is a rule-engine in the Frame platform that allows an account administrator to configure instant-access to instances by defining how many instances should be started at specific times and circumstances. Admins can manage capacity for their users by clicking “Capacity” listed on the left side of the Dashboard.
Three key parameters define your system capacity:
- Minimum (Min): the minimum number of instances powered on at a given time, ready to start sessions immediately.
- Buffer: extra instances that are ready for a user within seconds. Set this to a number of users you expect will connect within any 2 minute window (the time it takes to boot an instance).
- Maximum (Max): the maximum number of concurrent users you expect. As users connect to the min and then start using buffer instances, Frame will scale automatically by booting more instances up to the max. This is essentially the largest number of instances that you will allow your system to automatically scale up to, based on user demand. This lets you cap the number of simultaneous users and defines the size of the “pool” of instances that are allocated for your account.
The max capacity limit is 1,000 sessions for any account.
As an example, let’s say that your minimum is 5, your buffer is 3, and your max is 20 under “Default capacity.” The system will work as follows:
- With no user load, 5 instances will be running ready to accept a connection (the minimum).
- Once three users connect, there will only be two left from the original set of “minimum” instances. Since the buffer is set to 3, the system will automatically power on an additional instance, so that there are at least 3 “buffer” instances – three in use and three ready for new users.
- Each time a new user connects to consume one of the buffer instances, another instance will automatically be turned on to replenish the buffer.
- As more users connect, more instances will get provisioned – but the system will always attempt to maintain a buffer of 3 instances to ensure that new users get connected as quickly as possible to a session.
- The platform will continue to scale up until it reaches the maximum value, which is 20 in this case. The 21st user (and all subsequent users) will get an “out-of-capacity” message when attempting to connect.
- As users disconnect and instances become free, the system will also scale down automatically. Note that instances will remain on in full one-hour increments and automatically turn off if not in use.
- Eventually, as user demand decreases back to zero, the instance count will go back down to the minimum of 5.
You can have a minimum of 0 and a buffer of 0 to ensure that instances only come online when a user requests the app. In this case, users will have to wait a few minutes (typically 2-3 minutes) for the instance to come up after they click on the app for the first time. (They’ll be notified that an instance is starting.)
It is best to set the min and buffer to 0 and the max to 1 when publishing for the first time since you are still testing everything out.
Note that min and buffer instances incur hourly usage whether users are connected or not. You can set both to 0, so instances will only boot on-demand. (This conserves usage, but users must wait approximately 2 minutes to start an app.)
Set Active Capacity¶
The Frame platform allows admins to define “active capacity” for certain times of day or days of the week. For example, you may want your minimum and buffer increased during specific hours on specific days when you expect an increase in usage. You can configure the system to create custom capacity curves to accommodate a variety of these scenarios by defining your active capacity.
For this example, we have kept the default settings from the previous example but have now set active capacity hours. Every Tuesday and Thursday between 9 AM and 5 PM, the minimum will be raised to 8 with a buffer of 5.
If the fields under active capacity are left blank, the system will use the default capacity specified on the right side of the page.
System Capacity by System Type¶
Admins can define platform capacity depending on the system type being used. For example, you may have a team of graphic designers who would require access to a GPU-backed system type for a few hours during the week. You can set active capacity for that system type by clicking on corresponding tab and defining those values.
In the example above, we have enabled a minimum of 2 Pro 64GB (GPU-backed) instances to be running and available between the hours of 9 AM and 3 PM UTC every Thursday and Friday of the week. The active capacity has only been set for the Pro 64GB system type. Administrators may specify default and active capacity settings for any of their system types by clicking on the corresponding tab, adjusting settings, and clicking “Save.”