|
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.
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.
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 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.
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.
Configuring how WebLogic Server manages sessions is a key part of tuning your application for best performance. Consider the following:
Use sessions only for state that cannot realistically be kept on the client or if URL rewriting support is required. Keep simple bits of state, such as a user's name, directly in cookies. You might also write a wrapper class to do the getting and setting of these cookies, in order to simplify the work of servlet developers working on the same project.
For more information, see "Setting Up Session Management," in the WebLogic Server Administration Guide.
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|