WebLogic Server Performance and Tuning
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.
The following sections provide information on using persistent stores.
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:
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:
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.
For example, configure all SAF agents and JMS servers that run on the same server instance so that they share the same store.
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.
The following section provides information on tuning File Stores:
Direct-Write
synchronous write policy.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.
Cache-Flush
write policy.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. Disabled
.
![]() ![]() |
![]() |
![]() |