BEA Logo BEA WebLogic Server Release 6.1

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

   BEA WebLogic Server Performance and Tuning:   Previous topic   |   Next topic   |   Contents   |  Index

 

Tuning WebLogic Server Applications

 

WebLogic Server only performs as well as the applications running on it. It is important to determine the bottlenecks that impede performance, as described in the following sections:

Using a Profiler to Reveal Hot Spots

A profiler is a performance analysis tool that allows you to reveal hot spots in the application that result in either high CPU utilization or high contention for shared resources. See Performance Analysis Tools for a list of common profilers.

JDBC Application Tuning

See "Performance Tuning Your JDBC Application," in Programming WebLogic JDBC.

JDBC Optimization for Type-4 MS SQL Driver

When using the type-4 MS SQL driver, it may be much faster to create and execute an SQL statement without parameters, or with parameter values converted to their string counterparts and added as appropriate to the string, rather than to do a long series of setXXX() calls, followed by execute().

Setting Transaction Isolation Level

Data accessibility is controlled through the transaction isolation level mechanism. Transaction isolation level determines the degree to which multiple interleaved transactions are prevented from interfering with each other in a multi-user database system. Transaction isolation is achieved through use of locking protocols that guide the reading and writing of transaction data. This transaction data is written to the disk in a process called "serialization." Lower isolation levels give you better database concurrency at the cost of less transaction isolation.

For more information, see the description of the isolation-level element of the weblogic-ejb-jar.xml file, in Programming WebLogic Enterprise JavaBeans.

Refer to your database documentation for more information on the implications and support for different isolation levels.

Managing Session Persistence

Optimize your application so that it does as little work as possible when handling session persistence. In WebLogic Server, the following options are available for session persistence:

For additional details, see "Configuring Session Persistence," in the WebLogic Server Administration Guide

In-Memory Replication

In-memory replication is up to ten times faster than JDBC-based persistence for session state. Use in-memory replication, if possible.

For more information, see "Understanding HTTP Session State Replication," in Using WebLogic Server Clusters.

See also "In-Memory Replication for Stateful Session EJBs," in Programming WebLogic Enterprise JavaBeans.

JDBC-based Persistence

If you are using JDBC-based persistence, optimize your code so that it has as high a granularity for session state persistence as possible. This means that you want to reduce the number of "puts" that you use during your HTTP session. In the case of JDBC-based persistence, every session "put" that you do results in a database write. You want to minimize how often information is persisted during a given session. Look at your "puts" and see if you can combine them into one large put instead.

For more information, see "Using a Database for Persistent Storage," in the WebLogic Server Administration Guide.

Minimizing Sessions

Configuring how WebLogic Server manages sessions is a key part of tuning your application for best performance. Consider the following:

For more information, see "Setting Up Session Management," in the WebLogic Server Administration Guide.