Appboard/2.4/admin/performance and sizing: Difference between revisions

imported>Jason.nicholls
No edit summary
imported>Jason.nicholls
No edit summary
Line 5: Line 5:
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 but could vary greatly.
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 but could vary greatly.


As a general rule when it comes to tuning it's critical there is sufficient memory allocated to enPortal/AppBoard or CPU time will increase greatly. If there is sufficient memory, or memory capacity is exhausted, or CPU is exhausted then the way to scale is via load-balanced clustering.
== 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.
 
== 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.

Revision as of 11:57, 28 August 2013


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 but could vary greatly.

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 OutOfMemoryErrors 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.

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 & Failover guide.