Skip navigation.

WebLogic Server Performance and Tuning

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Using the WebLogic 8.1 Thread Pool Model

If you have been using execute queues to improve performance prior to this release, you may continue to use them after you upgrade your application domains to WebLogic Server 9.0.

Note: BEA recommends migrating from execute queues to using the self-tuning execute queue with work managers. See Using Work Managers to Optimize Scheduled Work in Configuring WebLogic Server Environments.

 


How to Enable the WebLogic 8.1 Thread Pool Model

BEA provides a flag that enables you to disable the self-tuning execute pool and provide backward compatibility for upgraded applications to continue to use user-defined execute queues.

Listing B-1 Using the use81-style-execute-queues Element

.
.
.
<server>
   <name>myserver</name>
   <use81-style-execute-queues>true</use81-style-execute-queues>
.
.
.
</server>
.
.
.

 


Tuning the Default Execute Queue

The value of the ThreadCount attribute of an ExecuteQueue element in the config.xml file equals the number of simultaneous operations that can be performed by applications that use the execute queue. As work enters an instance of WebLogic Server, it is placed in an execute queue. This work is then assigned to a thread that does the work on it. Threads consume resources, so handle this attribute with care—you can degrade performance by increasing the value unnecessarily. WebLogic Server uses different default values for the thread count of the default execute queue depending on the startup mode of the server instance. See Specify a startup mode in Administration Console Online Help.

Table B-1 Default Thread Count for Startup Modes

Server Mode . . .

Default Thread Count . . .

Development

15 threads

Production

25 threads


 

Unless you configure additional execute queues, and assign applications to them, the server instance assigns requests to the default execute queue.

Note: If native performance packs are not being used for your platform, you may need to tune the default number of execute queue threads and the percentage of threads that act as socket readers to achieve optimal performance. For more information, see Allocating Execute Threads to Act as Socket Readers.

Should You Modify the Default Thread Count?

Adding more threads to the default execute queue does not necessarily imply that you can process more work. Even if you add more threads, you are still limited by the power of your processor. You can degrade performance by increasing the value of the ThreadCount attribute unnecessarily. A high execute thread count causes more memory to be used and may increases context switching, which can degrade performance.

The value of the ThreadCount attribute depends very much on the type of work your application does. For example, if your client application is thin and does a lot of its work through remote invocation, that client application will spend more time connected — and thus will require a higher thread count — than a client application that does a lot of client-side processing.

If you do not need to use more than 15 threads (the development default) or 25 threads (the production default) for your work, do not change the value of this attribute. As a general rule, if your application makes database calls that take a long time to return, you will need more execute threads than an application that makes calls that are short and turn over very rapidly. For the latter case, using a smaller number of execute threads could improve performance.

To determine the ideal thread count for an execute queue, monitor the queue's throughput while all applications in the queue are operating at maximum load. Increase the number of threads in the queue and repeat the load test until you reach the optimal throughput for the queue. (At some point, increasing the number of threads will lead to enough context switching that the throughput for the queue begins to decrease.)

Note: The WebLogic Server Administration Console displays the cumulative throughput for all of a server's execute queues. To access this throughput value, follow steps 1-6 in Using Execute Queues to Control Thread Usage.

Table B-2 shows default scenarios for adjusting available threads in relation to the number of CPUs available in the WebLogic Server domain. These scenarios also assume that WebLogic Server is running under maximum load, and that all thread requests are satisfied by using the default execute queue. If you configure additional execute queues and assign applications to specific queues, monitor results on a pool-by-pool basis.

Table B-2 Scenarios for Modifying the Default Thread Count

When...

And you see...

Do This:

Thread Count < number of CPUs

CPUs are under utilized, but there is work that could be done.

Increase the thread count.

Thread Count = number of CPUs

CPUs are under utilized, but there is work that could be done.

Increase the thread count.

Thread Count > number of CPUs (by a moderate number of threads)

CPUs have high utilization, with a moderate amount of context switching.

Tune the moderate number of threads and compare performance results.

Thread Count > number of CPUs (by a large number of threads)

Too much context switching.

Reduce the number of threads.

 


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 user-defined 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 tasks 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:

Be sure to monitor each execute queue to ensure proper thread usage in the system as a whole. See Should You Modify the Default 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.

To configure a new execute queue using the Administration Console:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
  2. In the left pane of the console, expand Environment > Servers.
  3. On the Summary of Servers page, select the server instance for which you will configure an execute queue.
  4. Select the Configuration > Queues tab and click New.
  5. Name the execute queue and click OK.
  6. On the User-Defined Execute Queues page, select the execute queue you just created.
  7. On the execute queue Configuration tab, modify the following attributes or accept the system defaults:
  1. Click Save.
  2. To activate these changes, in the Change Center of the Administration Console, click Activate Changes. Not all changes take effect immediately—some require a restart.
  3. You must reboot the server to use the new thread detection behavior values.

Modifying the Thread Count

To modify the default execute queue thread count using the Administration Console:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
  2. In the left pane of the console, expand Environment > Servers.
  3. On the Summary of Servers page, select the server instance for which you will configure thread detection behavior.
  4. On the Configuration > Queues tab, select the execute queue for which you will modify the default thread count.
  5. Note: You can only modify the default execute queue for the server or a user-defined execute queue.

  6. Locate the Thread Count value and increase or decrease it, as appropriate.
  7. Click Save.
  8. To activate these changes, in the Change Center of the Administration Console, click Activate Changes. Not all changes take effect immediately—some require a restart.
  9. You must reboot the server to use the new thread detection behavior values.

Tuning Execute Queues for Overflow Conditions

You can configure WebLogic Server to detect and optionally address potential overflow conditions in the default execute queue or any user-defined execute queue. WebLogic Server considers a queue to have a possible overflow condition when its current size reaches a user-defined percentage of its maximum size. When this threshold is reached, the server changes its health state to "warning" and can optionally allocate additional threads to perform the outstanding work in the queue, thereby reducing the queue length.

To automatically detect and address overflow conditions in a queue, you can configure the following items:

To tune an execute queue using the WebLogic Server Administration Console:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
  2. In the left pane of the console, expand Environment > Servers.
  3. On the Summary of Servers page, select the server instance for which you will configure overflow conditions behavior.
  4. Select the Configuration > Queues tab, select the execute queue for which you will configure overflow conditions behavior.
  5. Specify how the server instance should detect an overflow condition for the selected queue by modifying the following attributes:
  1. To specify how this server should address an overflow condition for the selected queue, modify the following attribute:
  1. To fine-tune the variable thread count of this execute queue, modify the following attributes:
  1. Click Save.
  2. To activate these changes, in the Change Center of the Administration Console, click Activate Changes. Not all changes take effect immediately—some require a restart.
  3. You must reboot the server to use the new thread detection behavior values.

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 Creating and Configuring Servlets in Developing Web Applications, Servlets, and JSPs for WebLogic Server for more information about specifying initialization parameters in web.xml.

Assigning EJBs and RMI Objects to Execute Queues

To assign an EJB object to a configured execute queue, use the new dispatch-policy element in weblogic-ejb-jar.xml. For more information, see the weblogic-ejb-jar.xml Deployment Descriptor.

While you can also set the dispatch policy through the appc compiler -dispatchPolicy flag, BEA strongly recommends you use the deployment descriptor element instead. This way, if the EJB is recompiled, during deployment for example, the setting will not be lost.

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 ...

 


Monitoring Execute Threads

To use the Administration Console to monitor the status of execute threads:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
  2. In the left pane of the console, expand Environment > Servers.
  3. On the Summary of Servers page, select the server instance for which you will configure thread detection behavior.
  4. Select the Monitoring > Threads tab.
  5. A table of the execute queues available on this server instance is displayed.
  6. Select an execute queue for which you would like to view thread information.
  7. A table of execute threads for the selected execute queue is displayed.

 


Allocating Execute Threads to Act as Socket Readers

For best performance, BEA recommends that you use the native socket reader implementation, rather than the pure-Java implementation, on machines that host WebLogic Server instances (see Thread Management on page 6-3). However, if you must use the pure-Java socket reader implementation for host machines, you can still improve the performance of socket communication by configuring the proper number of execute threads to act as socket reader threads for each server instance.

The ThreadPoolPercentSocketReaders attribute sets the maximum percentage of execute threads that are set to read messages from a socket. The optimal value for this attribute is application-specific. The default value is 33, and the valid range is 1-99.

Allocating execute threads to act as socket reader threads increases the speed and the ability of the server to accept client requests. It is essential to balance the number of execute threads that are devoted to reading messages from a socket and those threads that perform the actual execution of tasks in the server.

Setting the Number of Socket Reader Threads For a Server Instance

To use the Administration Console to set the maximum percentage of execute threads that read messages from a socket:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
  2. In the left pane of the console, expand Environment > Servers.
  3. On the Summary of Servers page, select the server instance for which you will configure thread detection behavior.
  4. Select the Configuration > Tuning tab.
  5. Specify the percentage of Java reader threads in the Socket Readers field. The number of Java socket readers is computed as a percentage of the number of total execute threads (as shown in the Thread Count field for the Execute Queue).
  6. Click Save.
  7. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

Setting the Number of Socket Reader Threads on Client Machines

On client machines, you can configure the number of available socket reader threads in the JVM that runs the client. Specify the socket readers by defining the following parameters in the java command line for the client:

-Dweblogic.ThreadPoolSize=value
-Dweblogic.ThreadPoolPercentSocketReaders=value

 


Tuning the Stuck Thread Detection Behavior

WebLogic Server automatically detects when a thread in an execute queue becomes "stuck." Because a stuck thread cannot complete its current work or accept new work, the server logs a message each time it diagnoses a stuck thread.

WebLogic Server diagnoses a thread as stuck if it is continually working (not idle) for a set period of time. You can tune a server's thread detection behavior by changing the length of time before a thread is diagnosed as stuck, and by changing the frequency with which the server checks for stuck threads. Although you can change the criteria WebLogic Server uses to determine whether a thread is stuck, you cannot change the default behavior of setting the "warning" and "critical" health states when all threads in a particular execute queue become stuck. For more information, see Understanding WebLogic Logging Services in Configuring Log Files and Filtering Log Messages.

To configure stuck thread detection behavior:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
  2. In the left pane of the console, expand Environment > Servers.
  3. On the Summary of Servers page, select the server instance for which you will configure thread detection behavior.
  4. On the Configuration > Tuning tab, update as necessary:
  1. Click Save.
  2. To activate these changes, in the Change Center of the Administration Console, click Activate Changes. Not all changes take effect immediately—some require a restart.
  3. You must reboot the server to use the new thread detection behavior values.

 

Skip navigation bar  Back to Top Previous Next