There are several parts of performance to a Portal site, one aspect is the load time when testing from a single user perspective, secondly there is sustained load and the average response time. This post will focus on the sustained load and how to minimize the response time spiking, memory minimization and preventing session overloading. The most optimal configuration is to have a page response time that do not increase under load or a sustained load for a long period of time. All of this is possible with WebCenter Portal/Spaces deployments as long as few rules are adhered to.
By minimizing each session foot print, we cannot only sustain a longer load, we can also entertain a higher session count, there is two important configurations that can be used from a core level configuration in the ADF/JEE environment. This configuration is managed in the web.xml file located in the WEB-INF folder of the Portal/Spaces ear file.
<context-param> <param-name>org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS</param-name> <param-value>3</param-value> </context-param>
<context-param> <param-name>org.apache.myfaces.trinidad.COMPRESS_VIEW_STATE</param-name> <param-value>true</param-value> </context-param>
By updating/adding above options the session size will be reduced, ease the memory footprint, minimize the GC impact and reduce the GC iterations
GC= Java Garbage Collection
The session timeout value is a deal breaker for portal sites where a large volume of session is used for anonymous users, the reason for this is simply no logout is issued when the session is abandoned, therefore the implementation has to rely on the timeout to clean up the session. Best recommendation for this type of scenarios is to have a session timeout at 10 minutes or less, this will limit the max session count under load.
<session-config> <session-timeout>10</session-timeout> </session-config>
By updating/adding above options the session size will be reduced, ease the memory footprint, minimize the GC impact and reduce the GC iterations, this will also reduce the risk of overflowing the heap memory in the JVM.
ATEAM has supported several performance tuning exercises and the conclusion is: by distributing the sessions over several Managed Servers (JVM) the GC impact as well as the response stability can be vastly improved.
Based on several load tests with various intensity and load the best approach is to have more than one managed server in the cluster, this doesn't mean that you have more physical hardware, you can simply setup multiple managed server instances on each host by assigning unique ports. Example configuration proved not to exceed the 3 GB heap at anytime during a constant 1200 users load test:
Hopefully this third posting around performance will guide you in a good direction, if you want to get more details on this topic please continue reading here: