Appboard/2.5/admin/performance and sizing - Revision history

imported>Jason.nicholls: /* Scaling AppBoard */

2015-05-14T09:52:11Z

Scaling AppBoard

← Older revision		Revision as of 09:52, 14 May 2015
Line 46:		Line 46:
	== Scaling AppBoard ==		== Scaling AppBoard ==

	Scaling AppBoard beyond a single server is supported ~~with the~~ ideal configuration ~~being~~ a load-balanced cluster~~. As the load on AppBoard is directly related to the demand (concurrent users) then clustering provides~~ a linear way to scale and service additional concurrent users.		Scaling AppBoard vertically on a single server is a matter of ensuring adequate memory and CPU resources as mentioned above. Also, depending on the number of concurrent users, the underlying Tomcat application server may need tuning to increase the number of worker threads.

			Scaling horizontally beyond a single server is also supported by AppBoard. The ideal configuration in this case is a load-balanced cluster which offers a linear way to scale and service additional concurrent users.

	For more information please refer to the [[appboard/2.5/admin/clustering_and_failover\|Clustering & Failover]] guide.		For more information please refer to the [[appboard/2.5/admin/clustering_and_failover\|Clustering & Failover]] guide.

imported>Jason.nicholls: /* Responsiveness */

2015-03-05T11:50:41Z

Responsiveness

← Older revision		Revision as of 11:50, 5 March 2015
Line 39:		Line 39:
	Some of these can be mitigated to an extent by isolating the problem and trying to reduce or eliminate it. Some examples:		Some of these can be mitigated to an extent by isolating the problem and trying to reduce or eliminate it. Some examples:

	* slow database query: increase the AppBoard cache timeout if applicable, restructure the query, perhaps indexes may help on the database, pre-fetch the data with a batch process and store in a local database which can serve the data much quicker.		* slow database query: increase the AppBoard cache timeout if applicable, restructure the query, perhaps indexes may help on the database, enable Server Polling, or handle it external to AppBoard by pre-fetch the data with a batch process and store in a local database which can serve the data much quicker.
	* large data-sets: restructure the query to return the minimum data required. Use server-side-filters to reduce data transferred to the Viewer client.		* large data-sets: restructure the query to return the minimum data required. Use server-side-filters to reduce data transferred to the Viewer client.

			Refer to the [[appboard/2.5/builder/caching_and_polling\|Caching & Polling Overview]] for more information.

	== Scaling AppBoard ==		== Scaling AppBoard ==

imported>Jason.nicholls: /* Scaling AppBoard */

2014-07-22T06:14:35Z

Scaling AppBoard

← Older revision		Revision as of 06:14, 22 July 2014
Line 46:		Line 46:
	Scaling AppBoard beyond a single server is supported with the ideal configuration being a load-balanced cluster. As the load on AppBoard is directly related to the demand (concurrent users) then clustering provides a linear way to scale and service additional concurrent users.		Scaling AppBoard beyond a single server is supported with the ideal configuration being a load-balanced cluster. As the load on AppBoard is directly related to the demand (concurrent users) then clustering provides a linear way to scale and service additional concurrent users.

	For more information please refer to the [[~~Clustering_And_Failover~~\|Clustering & Failover]] guide.		For more information please refer to the [[appboard/2.5/admin/clustering_and_failover\|Clustering & Failover]] guide.

imported>Jason.nicholls at 08:37, 10 July 2014

2014-07-10T08:37:57Z

← Older revision		Revision as of 08:37, 10 July 2014
Line 5:		Line 5:

	Refer to the [[appboard/2.5/system_requirements\|System Requirements]] page for suggested server sizing depending on the deployment scenario. Typically the suggested sizing should handle hundreds of simultaneous users on the system - but this does vary and additional monitoring and tuning may be required for your particular situation.		Refer to the [[appboard/2.5/system_requirements\|System Requirements]] page for suggested server sizing depending on the deployment scenario. Typically the suggested sizing should handle hundreds of simultaneous users on the system - but this does vary and additional monitoring and tuning may be required for your particular situation.


	{{Tip\|Setting up system and application level memory and CPU monitoring is a recommended best practice to keep an eye on AppBoard performance.}}		{{Tip\|Setting up system and application level memory and CPU monitoring is a recommended best practice to keep an eye on AppBoard performance.}}

imported>Jason.nicholls at 08:37, 10 July 2014

2014-07-10T08:37:13Z

← Older revision		Revision as of 08:37, 10 July 2014
Line 2:		Line 2:
	[[Category:AppBoard 2.5]]		[[Category:AppBoard 2.5]]

	On the ~~recommended hardware~~ enPortal ~~should support 100-200 concurrent user sessions depending on how active / how many simultaneous requests are made overall~~.		AppBoard performance is heavily influenced by the size of data-sets, caching times, client polling frequencies, and the miscellaneous ways to transform data such as sub-queries, filtering, and data processing scripts. In addition, if using AppBoard in conjunction with enPortal proxied content then this will also introduce additional load.

	~~For AppBoard the situation is quite different due~~ to the ~~AppBoard~~ server ~~caching and data processing~~. ~~This can be heavily influenced by~~ the ~~size~~ of ~~data~~-~~sets, caching times, client polling frequencies,~~ and ~~the miscellaneous ways to transform data such as sub-queries, filtering,~~ and ~~data processing scripts. For a moderate deployment the number of concurrent users~~ may be ~~in the range of 50 or so on reasonable hardware but could vary greatly~~.		Refer to the [[appboard/2.5/system_requirements\|System Requirements]] page for suggested server sizing depending on the deployment scenario. Typically the suggested sizing should handle hundreds of simultaneous users on the system - but this does vary and additional monitoring and tuning may be required for your particular situation.

	{{Tip\|Setting up system and application level memory and CPU monitoring is a recommended best practice to keep an eye on AppBoard performance.}}		{{Tip\|Setting up system and application level memory and CPU monitoring is a recommended best practice to keep an eye on AppBoard performance.}}

imported>Jason.nicholls: /* Memory */

2014-07-10T08:25:44Z

Memory

← Older revision		Revision as of 08:25, 10 July 2014
Line 16:		Line 16:
	As a general rule, if experiencing performance issues and/or out of memory errors then increase the memory allocated to Java. If memory usage stays well within the allocated maximum memory and performance is still an issue then the performance issues could be elsewhere.		As a general rule, if experiencing performance issues and/or out of memory errors then increase the memory allocated to Java. If memory usage stays well within the allocated maximum memory and performance is still an issue then the performance issues could be elsewhere.

	For more information on configuring AppBoard's memory parameters refer to the [[~~Memory_Configuration~~\|Memory Configuration]] page.		For more information on configuring AppBoard's memory parameters refer to the [[appboard/2.5/admin/memory_configuration\|Memory Configuration]] page.

	== CPU ==		== CPU ==

imported>Jason.nicholls: 1 revision

2014-06-26T15:52:00Z

1 revision

← Older revision	Revision as of 15:52, 26 June 2014
(No difference)

imported>Jason.nicholls at 06:39, 14 December 2013

2013-12-14T06:39:39Z

New page

{{DISPLAYTITLE:Performance Tuning & Sizing}}
[[Category:AppBoard 2.5]]

On the recommended hardware enPortal should support 100-200 concurrent user sessions depending on how active / how many simultaneous requests are made overall.

For AppBoard the situation is quite different due to the AppBoard server caching and data processing. This can be heavily influenced by the size of data-sets, caching times, client polling frequencies, and the miscellaneous ways to transform data such as sub-queries, filtering, and data processing scripts. For a moderate deployment the number of concurrent users may be in the range of 50 or so on reasonable hardware but could vary greatly.

{{Tip|Setting up system and application level memory and CPU monitoring is a recommended best practice to keep an eye on AppBoard performance.}}

== Memory ==

As with ''any'' Java application performance is greatly impacted if there is insufficient memory and greater amounts of CPU time is given up trying to free memory until the point it becomes too slow and <tt>OutOfMemoryErrors</tt> occur.

While it's possible to profile, analyse and determine the ideal amount of memory to allocate this can be a lengthy process.

As a general rule, if experiencing performance issues and/or out of memory errors then increase the memory allocated to Java. If memory usage stays well within the allocated maximum memory and performance is still an issue then the performance issues could be elsewhere.

For more information on configuring AppBoard's memory parameters refer to the [[Memory_Configuration|Memory Configuration]] page.

== CPU ==

If memory is not an issue but CPU utilization is constantly high then AppBoard isn't able to cope with the load. Java applications automatically make use of multiple CPU cores so allocating additional CPUs, or migrating to a faster/better system will help - or scaling out horizontally (see Scaling AppBoard below).

The CPU load by AppBoard is directly related to demand which depends on how many concurrent users are logged in and what dashboard happen to be active. By using appropriate caching and avoiding processing large data-sets it may be possible to reduce the load on the system.

Also, if AppBoard is sharing the system with other processes then monitoring will be needed to determine what's using the resources.

== Responsiveness ==

Responsiveness can influence the ''perceived'' performance of AppBoard by end-users of the system. Clearly the AppBoard server is a factor but in the situation both memory and CPU utilization are not an issue then the problem could be due to other reasons. Consider:

* slow responses from data sources: such as slow running database queries, high latency links / remote data sources, and poorly performing data sources which is sometimes the case with web APIs.
* transferring large amounts of data, this applies from the AppBoard server to data sources, and the AppBoard server to clients.
* Viewer client system doesn't have enough memory
* Viewer client system is already slow and/or loaded due to other applications
* Viewer client using large amounts of CPU due to misc reasons such as widgets trying to show too much data, too many widgets, etc...

Some of these can be mitigated to an extent by isolating the problem and trying to reduce or eliminate it. Some examples:

* slow database query: increase the AppBoard cache timeout if applicable, restructure the query, perhaps indexes may help on the database, pre-fetch the data with a batch process and store in a local database which can serve the data much quicker.
* large data-sets: restructure the query to return the minimum data required. Use server-side-filters to reduce data transferred to the Viewer client.

== Scaling AppBoard ==

Scaling AppBoard beyond a single server is supported with the ideal configuration being a load-balanced cluster. As the load on AppBoard is directly related to the demand (concurrent users) then clustering provides a linear way to scale and service additional concurrent users.

For more information please refer to the [[Clustering_And_Failover|Clustering & Failover]] guide.