X

Best Practices from Oracle Development's A‑Team

Improving WebCenter Performance – Part 3

Introduction

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.

Main Article

Session size

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.

Setting ADF Client State Token

<context-param>    <param-name>org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS</param-name>    <param-value>3</param-value> </context-param>

Setting ADF View State Compression

<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

Session timeout

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.

Distributing load

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:

  • WC Portal Host 1:
    • Managed Server 1 (5GB of max heap)
    • Managed Server 3 (5GB of max heap)
  • WC Portal Host 2:
    • Managed Server 2 (5GB of max heap)
    • Managed Server 4 (5GB of max heap)

Result:

 

  • Perfect mark sweep GC pattern
  • Heap size consumption on each managed server averaging between 2 - 3 GB
  • Average response time through out the test (Client side timing) 250ms
  • Max Session count 13000 sessions (all anonymous)

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:

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content