Tuning the WebLogic Persistent Store 8-3
– Transactions in which only one resource participates are lightweight
one-phase transactions. Conversely, transactions in which multiple stores participate become 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 stores no longer scale.
8.3 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 Oracle WebLogic Server Administration Console Help and Using
the WebLogic Persistent Store in Configuring Server Environments for Oracle WebLogic Server.
8.4 Tuning File Stores
The following section provides information on tuning File Stores:
■
Section 8.4.1, Basic Tuning Information
■
Section 8.4.2, Tuning a File Store Direct-Write-With-Cache Policy
■
Section 8.4.3, Tuning the File Store Direct-Write Policy
■
Section 8.4.4, Tuning the File Store Block Size
8.4.1 Basic Tuning Information
The following section provides general 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.
■
For custom and default file stores, tune the Synchronous Write Policy.
– There are three transactionally safe synchronous write policies:
Direct-Write-With-Cache , Direct-Write, and Cache-Flush.
Direct-Write-With-Cache is generally the best performer of these
policies, Cache-Flush is generally the least performant, and Direct-Write is the default. Unlike other policies, Direct-Write-With-Cache creates
cache files in addition to primary files.
– The Disabled synchronous write policy is transactionally unsafe. The
Disabled write-policy 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.
– See Guidelines for Configuring a Synchronous Write Policy in Configuring
Server Environments for Oracle WebLogic Server.
8-4 Performance and Tuning for Oracle WebLogic Server
■
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 Disabled.
■
Depending on the synchronous write policy, custom and default stores have a variety of additional tunable attributes that may improve performance. These
include CacheDirectory, MaxWindowBufferSize, IOBufferSize, BlockSize
, InitialSize, and MaxFileSize. For more information see the JMSFileStoreMBean in the Oracle WebLogic Server MBean Reference.
■
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. To ensure transactionally safe write-back caches, they must be
protected against power outages, host machine failure, and operating system failure. Typically, such protection is provided by a battery-backed write-back
cache.
8.4.2 Tuning a File Store Direct-Write-With-Cache Policy
