Appboard/old/sizing and tuning - Revision history

imported>Jason.nicholls at 05:47, 17 July 2014

2014-07-17T05:47:13Z

← Older revision		Revision as of 05:47, 17 July 2014
Line 1:		Line 1:
	{{DISPLAYTITLE:Sizing & Tuning}}		{{DISPLAYTITLE:Sizing & Tuning}}
	[[~~Catgegory~~:AppBoard old]]		[[Category:AppBoard old]]
	When first configuring an AppBoard system, it is important to think about how much load is expected to be placed on the system, as well as how the system can be tuned to best accommodate the expected load with minimal inconvenience to the end user.		When first configuring an AppBoard system, it is important to think about how much load is expected to be placed on the system, as well as how the system can be tuned to best accommodate the expected load with minimal inconvenience to the end user.

imported>Jason.nicholls at 05:46, 17 July 2014

2014-07-17T05:46:58Z

← Older revision		Revision as of 05:46, 17 July 2014
Line 1:		Line 1:
			{{DISPLAYTITLE:Sizing & Tuning}}
			[[Catgegory:AppBoard old]]
	When first configuring an AppBoard system, it is important to think about how much load is expected to be placed on the system, as well as how the system can be tuned to best accommodate the expected load with minimal inconvenience to the end user.		When first configuring an AppBoard system, it is important to think about how much load is expected to be placed on the system, as well as how the system can be tuned to best accommodate the expected load with minimal inconvenience to the end user.

imported>Jason.nicholls: moved Sizing and Tuning to appboard/old/sizing and tuning

2014-07-17T05:46:29Z

moved Sizing and Tuning to appboard/old/sizing and tuning

← Older revision	Revision as of 05:46, 17 July 2014
(No difference)

imported>Mike.berman: created page

2013-06-04T18:50:57Z

created page

New page

When first configuring an AppBoard system, it is important to think about how much load is expected to be placed on the system, as well as how the system can be tuned to best accommodate the expected load with minimal inconvenience to the end user.

== Sizing an AppBoard System ==

Some important questions to consider for AppBoard sizing are:

* On a typical dashboard, how many queries are required to populate the Widgets? (A typical answer may be 4-8)
* For those queries, do they use parameters like credentials that vary by user, customer, and/or account, or are they globally shared?
* Depending on the answers to the questions above, how many users or customers/accounts are there?
* How often does the data need to refresh?
* How large are the results of the queries?

The first four items above are multiplied (along with a factor to get the refresh period in times/minute) to arrive at the number of queries per minute. An example would be:

5 queries are required, which vary by account, and there are 10 accounts. The data needs to refresh every 30 seconds. For that, one could estimate looking at about 100 queries per minute. There is some load based on the active number of users, but if caching is enabled for the data, a new user for an account that is already being hit would not add significant load.

The last question has a less direct impact on the load calculation, but if the result sets are large (such as thousands of rows with lots of data, tens or hundreds of thousands of rows with less data each), then the number of queries that can be supported is reduced. An estimate for the number of not large queries AppBoard could support is probably around 300 per minute, assuming the back-end systems could handle it and there are enough connections to use. On the low end, with large queries, perhaps the number is closer to 100 queries per minute. For most systems with refresh rates that are not near real-time, the gating factor should be the back-end queries running or the data transfer to the client.