{"__v":9,"_id":"569590bfcb14e11700f8a877","category":{"__v":10,"_id":"55e75b39e06f4b190080dbfe","pages":["56959043fe18811700c9c09e","569590bfcb14e11700f8a877","569590f7fcb1032d0089e033","5695917dfcb1032d0089e035","5695964a77ba0d2300cf3912","5695967edcaf0d1700cb8752","569618eccb14e11700f8a910","56961d937596a90d0014e571","5696ba13480534370022a37a","56dd002ee5c8570e00a79865"],"project":"55d535ca988e130d000b3f5c","version":"55d535cb988e130d000b3f5f","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-09-02T20:25:29.622Z","from_sync":false,"order":3,"slug":"frame-for-business","title":"Frame for Business"},"parentDoc":null,"project":"55d535ca988e130d000b3f5c","user":"55d535835082980d0009c965","version":{"__v":12,"_id":"55d535cb988e130d000b3f5f","hasDoc":true,"hasReference":false,"project":"55d535ca988e130d000b3f5c","createdAt":"2015-08-20T02:04:59.052Z","releaseDate":"2015-08-20T02:04:59.052Z","categories":["55d535cc988e130d000b3f60","55d6b238d2a8eb1900109eef","55d6b4f3250d7d0d004274cd","55d7967960fc730d00fc2852","55da9804e835f20d009fc5d0","55e75b1de06f4b190080dbfd","55e75b39e06f4b190080dbfe","55e75b7ae06f4b190080dbff","564f5a4e33082f0d001bb709","570fb64aa38d470e0060cbff","586d0dd89a854123001acd65","586d0e3b9a854123001acd66"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-01-12T23:48:15.610Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"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. For Frame for Business and Frame Platform accounts that support multiple users, you can set up your system capacity to scale dynamically based on user demand.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Using Elastic Instance Management (or \\\"elasticity\\\")\"\n}\n[/block]\nNavigate to your Dashboard, select Settings on the left hand side, and click on the Production tab.\n\nThree key parameters define your system capacity: the minimum, the buffer, and the maximum:\n \n  * **Min (minimum):**  the minimum number of instances powered on at a given time, ready to accept sessions.\n  \n  * **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).\n  \n  * **Max (maximum):**  the maximum number of concurrent users you expect. As users connect to the min and then 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. \n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/KRk2kVuFTzulvWhrRnYV_Screenshot%202015-09-15%2016.44.35.png\",\n        \"Screenshot 2015-09-15 16.44.35.png\",\n        \"738\",\n        \"443\",\n        \"#5c94cc\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nFor example, if your minimum is 5, your buffer is 3, and your maximum is 20, as shown above, the system will work as follows:\n\n  * With no user load, 5 instances will be running ready to accept a connection (the minimum).\n  * Once three users connect, there will only be two left from the original set of \"minimum\" instances. And 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.\n  * Now, each time a new user connects to consume one of the buffer instances, another instance will automatically be turned on to replenish the buffer.  \n  * As more users connect, more instances will get provisioned -- but the system will always attempt to maintain a buffer of 3 instances, so that new users get connected as quickly as possible to your application.\n  * The system will continue to scale up, until it reaches the maximum value, in this case 20 -- at which point the 21st user and subsequent users will get an \"out-of-capacity\" message.\n  * As users disconnect and instances become free, the system will also scale down automatically. But note that instances will remain on in full one-hour increments.\n  * Eventually, as user demand decreases back to zero (e.g., at night), the instance count will go back down to the minimum of 5.\n\nNote that you can have a minimum of 0 and a buffer of 0. This essentially amounts to instances only coming online when a user requests the app by clicking on a player. 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 Frame player for the first time. (They'll be notified that an instance is starting.)  \n\nWhen you're getting ready to publish for the first time, it's best to set the min and buffer to 0, and then set the max to a small number like 1 --  as you're testing everything out.\n\n\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"IMPORTANT\",\n  \"body\": \"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.)\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Scheduling exceptions\"\n}\n[/block]\nIn most cases, you'll want to set up some exceptions to your elastic scaling parameters for certain times of day or days of the week. For example, you may want your minimum and buffer reduced to zero at night, when you don't expect any users. Or there may be a particular time of day when you expect a large number of users. You can configure the system to create custom capacity curves to accommodate a variety of these scenarios by scheduling daily or weekly exceptions:\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/ydOMXUzHRJO5pK6NxkjA_Screenshot%202015-09-15%2017.01.06.png\",\n        \"Screenshot 2015-09-15 17.01.06.png\",\n        \"300\",\n        \"209\",\n        \"#5c94cc\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nWhen you set up exceptions, you'll define one or more time intervals (up to 20) during which the system will use parameters that are different from the default settings:\n\nDaily exceptions let you pick a specific time interval each day during which the parameters differ from the default. For example, you might want to set the minimum to a higher number from 9 a.m. to 11 a.m. because you expect a higher load during that time. Your elasticity settings would look like this:\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/zmUKJ8gSPu6ZrCVz72PJ_Screenshot%202015-09-15%2017.09.58.png\",\n        \"Screenshot 2015-09-15 17.09.58.png\",\n        \"775\",\n        \"417\",\n        \"#84acd5\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nWeekly exceptions let you define specific times on specific days of the week when you want to differ from the default settings. For example, if I know that my peak load only happens on Thursdays between 9 and 11 a.m., my settings would look like this:\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/LlWMpKcYQEivhAAIcys7_Screenshot%202015-09-15%2017.14.37.png\",\n        \"Screenshot 2015-09-15 17.14.37.png\",\n        \"800\",\n        \"518\",\n        \"#649ccc\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Guidelines for changing settings\"\n}\n[/block]\nWhen you change your settings, there are several things to be aware of in terms of how the system responds:\n\n**All time set points are defaulted to UTC (Coordinated Universal Time, e.g., London)**, so be sure to change the timezone setting on the production settings page in your account to reflect your local time zone.  \n\n**You must define all intervals between midnight and midnight** (the system will check to be sure that your \"start time\" is less than your \"end time\"). This means you cannot set an interval to be 10:00 p.m. to 2:00 a.m.  As a best practice when using intervals, set your default parameters to be what you expect to have overnight, and then setup exceptions for time intervals during the day. Once you make a change in your Dashboard's settings, the system will take approximately 5 minutes to initiate the platform changes. The system does check to see if the changed value affects the set points for the current time (you do not have to wait for the set point time for a change to occur). \n\n**The first time you set the maximum, and any time you increase it thereafter, the system will take up to an hour to prepare new instances for on-demand access.** Once provisioned in this process, they will be ready to come online based on your user demand within 1-2 minutes from the time the user clicks the player.  \n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"IMPORTANT:  Keep \\\"Max\\\" settings the same for all intervals including the default\",\n  \"body\": \"Note that in most cases, you will want the maximum to be the same for all set intervals including the default setting. (Otherwise, if you change the maximum setting, instances will unnecessarily get terminated when you reduce the maximum, just to be re-provisioned when the maximum increases -- and will unnecessarily incur instance hour usage on your account.)  You'll get a notification warning you about this if your maximum settings are not all the same.\"\n}\n[/block]\nYou can create up to twenty intervals for scheduled exceptions. Note that once you add an interval, you can delete it as well (hover over the interval and click the red X at the right, as shown below).  \n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/KaQ7rNwRaMeztTsCdudw_Instances%20Management.PNG\",\n        \"Instances Management.PNG\",\n        \"1040\",\n        \"631\",\n        \"#566988\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]","excerpt":"","slug":"set-up-capacity-and-scaling","type":"basic","title":"Set up capacity and scaling"}

Set up capacity and scaling


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. For Frame for Business and Frame Platform accounts that support multiple users, you can set up your system capacity to scale dynamically based on user demand. [block:api-header] { "type": "basic", "title": "Using Elastic Instance Management (or \"elasticity\")" } [/block] Navigate to your Dashboard, select Settings on the left hand side, and click on the Production tab. Three key parameters define your system capacity: the minimum, the buffer, and the maximum: * **Min (minimum):** the minimum number of instances powered on at a given time, ready to accept sessions. * **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). * **Max (maximum):** the maximum number of concurrent users you expect. As users connect to the min and then 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. [block:image] { "images": [ { "image": [ "https://files.readme.io/KRk2kVuFTzulvWhrRnYV_Screenshot%202015-09-15%2016.44.35.png", "Screenshot 2015-09-15 16.44.35.png", "738", "443", "#5c94cc", "" ] } ] } [/block] For example, if your minimum is 5, your buffer is 3, and your maximum is 20, as shown above, 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. And 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. * Now, 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, so that new users get connected as quickly as possible to your application. * The system will continue to scale up, until it reaches the maximum value, in this case 20 -- at which point the 21st user and subsequent users will get an "out-of-capacity" message. * As users disconnect and instances become free, the system will also scale down automatically. But note that instances will remain on in full one-hour increments. * Eventually, as user demand decreases back to zero (e.g., at night), the instance count will go back down to the minimum of 5. Note that you can have a minimum of 0 and a buffer of 0. This essentially amounts to instances only coming online when a user requests the app by clicking on a player. 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 Frame player for the first time. (They'll be notified that an instance is starting.) When you're getting ready to publish for the first time, it's best to set the min and buffer to 0, and then set the max to a small number like 1 -- as you're testing everything out. [block:callout] { "type": "warning", "title": "IMPORTANT", "body": "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.)" } [/block] [block:api-header] { "type": "basic", "title": "Scheduling exceptions" } [/block] In most cases, you'll want to set up some exceptions to your elastic scaling parameters for certain times of day or days of the week. For example, you may want your minimum and buffer reduced to zero at night, when you don't expect any users. Or there may be a particular time of day when you expect a large number of users. You can configure the system to create custom capacity curves to accommodate a variety of these scenarios by scheduling daily or weekly exceptions: [block:image] { "images": [ { "image": [ "https://files.readme.io/ydOMXUzHRJO5pK6NxkjA_Screenshot%202015-09-15%2017.01.06.png", "Screenshot 2015-09-15 17.01.06.png", "300", "209", "#5c94cc", "" ] } ] } [/block] When you set up exceptions, you'll define one or more time intervals (up to 20) during which the system will use parameters that are different from the default settings: Daily exceptions let you pick a specific time interval each day during which the parameters differ from the default. For example, you might want to set the minimum to a higher number from 9 a.m. to 11 a.m. because you expect a higher load during that time. Your elasticity settings would look like this: [block:image] { "images": [ { "image": [ "https://files.readme.io/zmUKJ8gSPu6ZrCVz72PJ_Screenshot%202015-09-15%2017.09.58.png", "Screenshot 2015-09-15 17.09.58.png", "775", "417", "#84acd5", "" ] } ] } [/block] Weekly exceptions let you define specific times on specific days of the week when you want to differ from the default settings. For example, if I know that my peak load only happens on Thursdays between 9 and 11 a.m., my settings would look like this: [block:image] { "images": [ { "image": [ "https://files.readme.io/LlWMpKcYQEivhAAIcys7_Screenshot%202015-09-15%2017.14.37.png", "Screenshot 2015-09-15 17.14.37.png", "800", "518", "#649ccc", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Guidelines for changing settings" } [/block] When you change your settings, there are several things to be aware of in terms of how the system responds: **All time set points are defaulted to UTC (Coordinated Universal Time, e.g., London)**, so be sure to change the timezone setting on the production settings page in your account to reflect your local time zone. **You must define all intervals between midnight and midnight** (the system will check to be sure that your "start time" is less than your "end time"). This means you cannot set an interval to be 10:00 p.m. to 2:00 a.m. As a best practice when using intervals, set your default parameters to be what you expect to have overnight, and then setup exceptions for time intervals during the day. Once you make a change in your Dashboard's settings, the system will take approximately 5 minutes to initiate the platform changes. The system does check to see if the changed value affects the set points for the current time (you do not have to wait for the set point time for a change to occur). **The first time you set the maximum, and any time you increase it thereafter, the system will take up to an hour to prepare new instances for on-demand access.** Once provisioned in this process, they will be ready to come online based on your user demand within 1-2 minutes from the time the user clicks the player. [block:callout] { "type": "warning", "title": "IMPORTANT: Keep \"Max\" settings the same for all intervals including the default", "body": "Note that in most cases, you will want the maximum to be the same for all set intervals including the default setting. (Otherwise, if you change the maximum setting, instances will unnecessarily get terminated when you reduce the maximum, just to be re-provisioned when the maximum increases -- and will unnecessarily incur instance hour usage on your account.) You'll get a notification warning you about this if your maximum settings are not all the same." } [/block] You can create up to twenty intervals for scheduled exceptions. Note that once you add an interval, you can delete it as well (hover over the interval and click the red X at the right, as shown below). [block:image] { "images": [ { "image": [ "https://files.readme.io/KaQ7rNwRaMeztTsCdudw_Instances%20Management.PNG", "Instances Management.PNG", "1040", "631", "#566988", "" ] } ] } [/block]