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 Performance Analysis Tools

• JDBC Application Tuning

• Managing Session Persistence

• Minimizing Sessions

• Using Execute Queues to Control Thread Usage

 

---

Using Performance Analysis Tools

This section provides a quick reference for using the OptimizeIt and JProbe profilers with WebLogic Server.

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. For a list of common profilers, see Performance Analysis Tools.

Using the JProbe Profiler API

The JProbe Suite is a family of products that provide the capability to detect performance bottlenecks, find and fix memory leaks, perform code coverage, and other metrics.

The JProbe website provides a technical white paper, "Using Sitraka JProbe and BEA WebLogic Server", which describes how developers can analyze code with any of the JProbe Suite tools running inside BEA WebLogic Server.

Using the Optimizeit Profiler

Borland's Optimizeit Performance Profiler is a performance debugging tool for Solaris and Windows. Borland provides detailed J2EE Integration Tutorials for the supported versions of Optimizeit Profiler that work with WebLogic Server.

 

---

JDBC Application Tuning

BEA offers three WebLogic jDrivers for use with the WebLogic Server software:

• Type 2 native JDBC driver for Oracle with distributed transaction capability

  See Installing and Using WebLogic jDriver for Oracle.

• Type 4 JDBC drivers for Informix and Microsoft SQL Server

  See Installing and Using WebLogic jDriver for Informix and Installing and Using WebLogic jDriver for Microsoft SQL Server.

Type-2 drivers use client libraries supplied by a database vendor. Type-4 drivers are pure-Java; they connect to the database server at the wire level without vendor-supplied client libraries.

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 either without parameters or with parameter values converted to their string counterparts and added as appropriate to the string, rather than declaring a long series of setXXX() calls, followed by execute().

 

---

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:

• In-Memory Replication

• JDBC-based 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. In the case of JDBC-based persistence, every session "put" that you use in your code results in a database write of the entire object.

Keep the number of "puts" that you use during your HTTP session to a mininmum.To minimize how often information is persisted during a given session, look at your "puts" and see if you can combine them into a single, large "put," instead.

For more information, see "Using a Database for Persistent Storage (JDBC Persistence)," in Assembling and Configuring Web Applications.

 

---

Minimizing Sessions

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

• Use of sessions involves a scalability trade-off.

• Use sessions sparingly.

  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.

• Keep frequently used values in local variables.

• Put aggregate objects rather than multiple single objects into the session where possible.

See "Setting Up Session Management," in Assembling and Configuring Web Applications.

 

---

Using Execute Queues to Control Thread Usage

You can fine-tune an application's access to execute threads to optimize its performance or limit its CPU utilization by configuring multiple execute queues in WebLogic Server. An execute queue represents a named collection of execute threads that are available to one or more designated servlets, JSPs, EJBs, or RMI objects.

Default WebLogic Server installations are configured with a default execute queue, which is used by all applications running on the server instance. You may want to configure additional queues to:

• Optimize the performance of critical applications. For example, you can assign a single, mission-critical application to a particular execute queue, guaranteeing a fixed number of execute threads. During peak server loads, nonessential applications may compete for threads in the default execute queue, but the mission-critical application has access to the same number of threads at all times.

• Throttle the performance of nonessential applications. If you have an application that can potentially consume large amounts of memory, assigning the application to a dedicated execute queue effectively limits the amount of memory it can consume. Although the application can potentially use all threads available in its assigned execute queue, it cannot affect thread usage in any other queue.

• Remedy deadlocks in thread usage. With certain application designs, deadlocks can occur when all execute threads are currently utilized. For example, consider a servlet that reads messages from a designated JMS queue. If all execute threads in a server are used for processing the servlet requests, then no threads are available to deliver messages from the JMS queue. In this situation, a deadlock condition exists, and no work can progress. Assigning the servlet to a separate execute queue remedies the potential deadlock, because the servlet and JMS queue do not compete for thread resources.

Execute Queue Drawbacks

Although execute queues can provide fine-tuning for application performance, keep in mind that unused threads represent significant wasted resources in a Weblogic Server system. Without careful consideration of thread usage in all execute queues, you may find that available threads in configured execute queues go unused, while applications in other queues sit idle waiting for threads to become available. In such a situation, the division of threads into queues may yield poorer overall performance than having a single, default execute queue.

Be sure to monitor each execute queue to ensure proper thread usage in the system as a whole. See Setting Thread Count for general information about optimizing the number of threads.

Creating Execute Queues

An execute queue is represented in the domain config.xml file as part of the Server element. For example, an execute queue named CriticalAppQueue with 4 execute threads appears in the config.xml file as follows:

...
<Server
  Name="examplesServer"
  ListenPort="7001"
  NativeIOEnabled="true"/>
  <ExecuteQueue Name="default"
    ThreadCount="15"/>
  <ExecuteQueue Name="CriticalAppQueue"
    ThreadCount="4"/>
  ...
</Server>

To configure a new execute queue using the WebLogic Administration Console:

1. Start the Administration Console and click on the name of the server to which you will add the execute queue.

2. Click the Monitoring tab.

3. From the General monitoring tab, click Monitor all Active Queues...

4. Click Configure Execute Queues...

5. Click Configure a New Execute Queue...

6. Enter the name, thread priority, and number of threads for the new queue.

7. Click Create to create the new queue in config.xml.

Assigning Servlets and JSPs to Execute Queues

You can assign a servlet or JSP to a configured execute queue by identifying the execute queue name in the initialization parameters. Initialization parameters appear within the init-param element of the servlet or JSP's deployment descriptor file, web.xml. To assign an execute queue, enter the queue name as the value of the wl-dispatch-policy parameter, as in the example:

<servlet>
      <servlet-name>MainServlet</servlet-name>
      <jsp-file>/myapplication/critical.jsp</jsp-file>
      <init-param>
            <param-name>wl-dispatch-policy</param-name>
            <param-value>CriticalAppQueue</param-value>
      </init-param>
</servlet>

See Initializing a Servlet in Programming WebLogic HTTP Servlets for more information about specifying initialization parameters in web.xml.

Assigning EJBs and RMI Objects to Execute Queues

To assign an RMI object to a configured execute queue, use the -dispatchPolicy option to the rmic compiler. For example:

java weblogic.rmic -dispatchPolicy CriticalAppQueue ...

To assign an EJB object to a configured execute queue, use the -dispatchPolicy option with ejbc. The ejbc compiler passes this option and its argument to rmic when compiling the EJB.