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 Sessions
• Using Execute Queues to Control Thread Usage

 

---

Using Performance Analysis Tools

This section is a quick reference for using the OptimizeIt^TM and JProbe^TM 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

The JProbe Profiler with Memory Debugger from Sitraka is a family of products that provide the capability to detect performance bottlenecks, perform code coverage and other metrics.

Sitraka provides the following Application Server Integration Portals for JProbe, which list the WebLogic Server releases certified to work with JProbe 3.0 and 4.0, and provide detailed instructions on how to integrate JProbe with WebLogic Server.

• JProbe 3.0.x Integration Portal for J2EE.
• JProbe 4.0 Integration Portal for J2EE.

Using the OptimizeIt Profiler

The OptimizeIt Profiler from Borland is aperformance debugging tool for Solaris and Windows platforms.

Borland provides detailed J2EE Integration Tutorials for the supported versions of OptimizeIt Profiler that work with WebLogic Server.

 

---

JDBC Application Tuning

Most performance gains or losses in a database application are determined by how the application is designed. The number and location of clients, size and structure of DBMS tables and indexes, and the number and types of queries all affect application performance.

For more information on optimizing your applications for JDBC, 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().

For more information, see "Configuring and Using WebLogic jDriver for Microsoft SQL Server"

 

---

Managing Sessions

Optimize your application so that it does as little work as possible when handling session persistence and sessions.

Managing Session Persistence

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

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" operation 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 minimum.To minimize how often information is persisted during a given session, examine your "puts" and, if possible, combine them into a single, large "put".

For more information, see:

• "Configuring Session Persistence" in Assembling and Configuring Web Applications
• "HTTP Session State Replication" in Using WebLogic Sever Clusters.
• "In-Memory Replication for Stateful Session EJBs" in Programming WebLogic EJB.
• "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 "get" and "set" 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 (and thereby optimize or throttle its performance) by using multiple execute queues in WebLogic Server. However, keep in mind that unused threads represent significant wasted resources in a Weblogic Server system. 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 multiple queues may yield poorer overall performance than having a single, default execute queue.

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. For an application that can potentially consume large amounts of memory, assigning it 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 deadlocked 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 to process the servlet requests, then no threads are available to deliver messages from the JMS queue. A deadlock condition exists, and no work can progress. Assigning the servlet to a separate execute queue avoids potential deadlocks, because the servlet and JMS queue do not compete for thread resources.

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 represents a named collection of execute threads that are available to one or more designated servlets, JSPs, EJBs, or RMI objects. 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 four 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 Administration Console:

1. Start the Administration Server if it is not already running.
2. Access the Administration Console for the domain.
3. Click the Servers node in the left pane to display the servers configured in your domain.
4. Click the name of the server instance where you will add the execute queue.
5. Select the Monitoring —> General tab.
6. Click the Monitor All Active Queues text link to display the execute queues that the selected server uses.
7. Click the Configure Execute Queue text link to display the execute queues that you can modify.
8. Click the Configure a New Execute Queue link.
9. On the Execute Queue Configuration tab modify the following attributes or accept the system defaults:
   • Queue Length: Always leave the Queue Length at the default value of 65536 entries. The Queue Length specifies the maximum number of simultaneous requests that the server can hold in the queue. The default of 65536 requests represents a very large number of requests; outstanding requests in the queue should rarely, if ever reach this maximum value.

   If the maximum Queue Length is reached, WebLogic Server automatically doubles the size of the queue to account for the additional work. Note, however, that exceeding 65536 requests in the queue indicates a problem with the threads in the queue, rather than the length of the queue itself; check for stuck threads or an insufficient thread count in the execute queue.

   • Queue Length Threshold Percent: Enter the percentage (from 1-99) of the Queue Length size that can be reached before the server indicates an overflow condition for the queue. All actual queue length sizes below the threshold percentage are considered normal; sizes above the threshold percentage indicate an overflow. When an overflow condition is reached, WebLogic Server logs an error message and increases the number of threads in the queue by the value of the Threads Increase attribute to help reduce the workload.

   By default, the Queue Length Threshold Percent value is 90 percent. In most situations, you should leave the value at or near 90 percent, to account for any potential condition where additional threads may be needed to handle an unexpected spike in work requests. Keep in mind that Queue Length Threshold Percent must not be used as an automatic tuning parameter—the threshold should never trigger an increase in thread count under normal operating conditions.

   • Thread Count: Specify the number of threads assigned to this queue. If you do not need to use more than 15 threads (the default) for your work, do not change the value of this attribute. (For more information, see Should You Modify the Default Thread Count?.)
   • Threads Increase: Enter the number of threads WebLogic Server should add to this execute queue when it detects an overflow condition. If you specify zero threads (the default), the server changes its health state to "warning" in response to an overflow condition in the thread, but it does not allocate additional threads to reduce the workload.

   Note that if WebLogic Server increases the number of threads in response to an overflow condition, the additional threads remain in the execute queue until the server is rebooted. In general, you should monitor the error log to determine the cause of overflow conditions, and reconfigure the thread count as necessary to prevent similar conditions in the future. Do not use the combination of Threads Increase and Queue Length Threshold Percent as an automatic tuning tool; doing so generally results in the execute queue allocating more threads than necessary and suffering from poor performance due to context switching.

   • Threads Minimum: Specify the minimum number of threads that WebLogic Server should maintain in this execute queue to prevent unnecessary overflow conditions. By default, the Threads Minimum is set to 5.
   • Threads Maximum: Specify the maximum number of threads that this execute queue can have; this value prevents WebLogic Server from creating an overly high thread count in the queue in response to continual overflow conditions. By default, the Threads Maximum is set to 400.
   • Thread Priority: Specify the priority of the threads associated with this queue. By default, the Thread Priority is set to 5.
10. Click Create to create the new execute queue.
11. Reboot the server to use the new settings.

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's 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 the appc utility. appc passes this option and its argument to rmic when compiling the EJB.