Analysis Technique

Analysis Technique

Bottle Neck Analysis Technique

After having a portal at saturation, by taking a Java thread dump (using a kill -3 commands), one can determine the cause of bottleneck in the system against the portal Java process which is under the test. In a JVM, A thread dump shows the state of all thread. The general process is to search for threads that are blocked by the same reason or that are waiting in the same method of the same class.

In general, search for threads that are blocked or in a waiting list are done by ascertaining through the certain type of classes that are statistically shown up as blocked, and now then proceed to remove that reason and thus remove the bottleneck. The next section discusses some common bottleneck problems. Going into all the problems you could encounter is really the art of WebSphere Portal bottleneck analysis and takes time and experience to master.

If the bottleneck is not the WebSphere Portal JVM itself, detection and resolution techniques are varied and outside the scope of this article.

Logging

Serialization between running threads and significantly degrades portal performance is caused due to Logging using direct writes to SystemOut.log or using a logging class such as log4j causes. In the production of portal systems, log only what is absolutely needed. When using log only errors; log4j; do not log informational messages or warning. Consider using a portal service or a different service running in a separate JVM, If the logging is required for audit purposes.

Before doing performance testing, Turn off all logging and remove all debug code that writes to files.

Capacity Planning

To estimate the total number of WebSphere Portal JVM’s required to satisfy a particular user population with in the pre-determined SLA metrics prior to entering production.

Typical metrics include:

• Page-to-page response times after being already logged in (typically around two seconds)
• Portal login response time (typically around four seconds) 

Process

    The load test process looks very likely to the one for running the test for bottleneck analysis except that there is now a second criterion for stopping the test. One criterion is saturation, as previously defined. The second criterion is failure of any of the SLA metrics.

     If the test reaches saturation before any of the SLA metrics are exceeded and if it has already been determined that there are no bottlenecks that can or will be excised, then you can immediately calculate the number of nodes required.

     If the SLA metrics are exceeded before reaching saturation, then you must analyze the failure to determine the next course of action. If you determine that you do not need to resolve the response time issues, then proceed directly to calculating the number of nodes, as discussed in the next section of this article.