WebLogic Server Performance and Tuning

Tuning the WebLogic Persistent Store

The following sections explain how to tune the persistent store, which provides a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence.

Overview of Persistent Stores

The following sections provide information on using persistent stores.

Using the Default Persistent Store

Each server instance, including the administration server, has a default persistent store that requires no configuration. The default store is a file-based store that maintains its data in a group of files in a server instance's data\store\default directory. A directory for the default store is automatically created if one does not already exist. This default store is available to subsystems that do not require explicit selection of a particular store and function best by using the system's default storage mechanism. For example, a JMS Server with no persistent store configured will use the default store for its Managed Server and will support persistent messaging. See:

Using the WebLogic Persistent Store in Configuring WebLogic Server Environments.
Modify the Default Store Settings in Administration Console Online Help.

Using Custom File Stores and JDBC Stores

In addition to using the default file store, you can also configure a file store or JDBC store to suit your specific needs. A custom file store, like the default file store, maintains its data in a group of files in a directory. However, you may want to create a custom file store so that the file store's data is persisted to a particular storage device. When configuring a file store directory, the directory must be accessible to the server instance on which the file store is located.

A JDBC store can be configured when a relational database is used for storage. A JDBC store enables you to store persistent messages in a standard JDBC-capable database, which is accessed through a designated JDBC data source. The data is stored in the JDBC store's database table, which has a logical name of WLStore. It is up to the database administrator to configure the database for high availability and performance. See:

When to Use a Custom Persistent Store in Configuring WebLogic Server Environments.
Comparing File Stores and JDBC Stores in Configuring WebLogic Server Environments.
Creating a Custom (User-Defined) File Store in Configuring WebLogic Server Environments.
Creating a JDBC Store in Configuring WebLogic Server Environments.

Using JMS Paging Stores

Each JMS server implicitly creates a file based paging store. When the WebLogic Server JVM runs low on memory, this store is used to page non-persistent messages as well as JDBC store persistent messages. Depending on the application, paging stores may generate heavy disk activity.

Note: File store persistent messages do not page using a paging store, such messages page directly into and out of their respective file stores.

JMS paging stores usually require no tuning. You can optionally change the directory location and the thresholds setting at which paging begins. See Paging Out Messages To Free Up Memory on page 12-6.

Best Practices When Using Persistent Stores

For subsystems that share the same server instance, share one store between multiple subsystems rather than using a store per subsystem. Sharing a store is more efficient for the following reasons:

A single store batches concurrent requests into single I/Os which reduces overall disk usage.
Transactions in which only one resource participates are lightweight one-phase transactions. Conversely, transactions in which multiple stores participate become are heavier weight two-phase transactions.

For example, configure all SAF agents and JMS servers that run on the same server instance so that they share the same store.

Add a new store only when the old store(s) no longer scale.

Tuning JDBC Stores

The location of the JDBC store DDL that is used to initialize empty stores is now configurable. This simplifies the use of custom DDL for database table creation, which is sometimes used for database specific performance tuning. For information, see Create JDBC stores in Administration Console Online Help and Using the WebLogic Persistent Store in Configuring WebLogic Server Environments.

Tuning File Stores

The following section provides information on tuning File Stores:

For basic (non-RAID) disk hardware, consider dedicating one disk per file store. A store can operate up to four to five times faster if it does not have to compete with any other store on the disk. Remember to consider the existence of the default file store in addition to each configured store and a JMS paging store for each JMS server.
Use Direct-Write synchronous write policy.

For releases of WebLogic Server 9.0 and higher, Direct-Write is the default write policy. In most applications Direct-Write provides better performance than the Cache-Flush write policy.

Note: The Direct-Write write-policy (default) can be unsafe on Microsoft Windows. As with other vendors that use a direct write policy, MS-Windows system administrators must ensure that the Windows disk configuration doesn't cache direct-writes in memory instead of flushing them to disk. See getSynchronousWritePolicy.

File stores in releases prior to WebLogic Server 9.0 default to the Cache-Flush write policy.

-The Disabled write-policy option can dramatically improve performance, especially at low client loads. However, it is unsafe because writes become asynchronous and data can be lost in the event of Operating System or power failure.
When performing head-to-head vendor comparisons, make sure all the write policies for the persistent store are equivalent. Some non-WebLogic vendors default to the equivalent of the Disabled.
If disk performance continues to be a bottleneck, consider purchasing disk or RAID controller hardware that has a built-in "write-back cache". These caches significantly improve performance by temporarily storing persistent data in volatile memory. Use a battery backed write-back caches to provide protection from power outages, host machine failure, and operating system failure.