1 Top Tuning Recommendations for WebLogic Server

Tuning Oracle WebLogic Server and your WebLogic Server application is a complex and iterative process. To get you started, Oracle recommends various tuning techniques to optimize your application's performance. These tuning techniques are applicable to nearly all WebLogic applications.

• Tune Pool Sizes

• Use the Prepared Statement Cache

• Use Logging Last Resource Optimization

• Tune Connection Backlog Buffering

• Use Optimistic or Read-only Concurrency

• Use Local Interfaces

• Use eager-relationship-caching

• Tune HTTP Sessions

• Tune Messaging Applications

• Tune Pool Sizes
  Provide pool sizes (such as pools for JDBC connections, Stateless Session EJBs, and MDBs) that maximize concurrency for the expected thread utilization.
• Use the Prepared Statement Cache
  The prepared statement cache keeps compiled SQL statements in memory, thus avoiding a round-trip to the database when the same statement is used later.
• Use Logging Last Resource Optimization
  When using transactional database applications, consider using the JDBC data source Logging Last Resource (LLR) transaction policy instead of XA.
• Tune Connection Backlog Buffering
  You can tune the number of connection requests that a WebLogic Server instance accepts before refusing additional requests. This tunable applies primarily for Web applications.
• Use Optimistic or Read-only Concurrency
  Use optimistic concurrency with cache-between-transactions or read-only concurrency with query-caching for CMP EJBs to leverage the Entity Bean cache provided by the EJB container.
• Use Local Interfaces
  Use local-interfaces or use call-by-reference semantics to avoid the overhead of serialization when one EJB calls another or an EJB is called by a servlet/JSP in the same application.
• Use eager-relationship-caching
  Use eager-relationship-caching to allow the EJB container to load related beans using a single SQL statement.
• Tune HTTP Sessions
  Optimize your application so that it does as little work as possible when handling HTTP session persistence and sessions. Also, design a session management strategy that suits your environment and application.
• Tune Messaging Applications
  Oracle provides messaging users a rich set of performance tunables. In general, you should always configure quotas and paging.

Tune Pool Sizes

Provide pool sizes (such as pools for JDBC connections, Stateless Session EJBs, and MDBs) that maximize concurrency for the expected thread utilization.

For WebLogic Server releases 9.0 and higher—A server instance uses a self-tuned thread-pool. The best way to determine the appropriate pool size is to monitor the pool's current size, shrink counts, grow counts, and wait counts. See Thread Management. Tuning MDBs are a special case, please see Tuning Message-Driven Beans.

Use the Prepared Statement Cache

The prepared statement cache keeps compiled SQL statements in memory, thus avoiding a round-trip to the database when the same statement is used later.

See Tuning Data Sources.

Use Logging Last Resource Optimization

When using transactional database applications, consider using the JDBC data source Logging Last Resource (LLR) transaction policy instead of XA.

The LLR optimization can significantly improve transaction performance by safely eliminating some of the 2PC XA overhead for database processing, especially for two-phase commit database insert, update, and delete operations. See Tuning Data Sources.

Tune Connection Backlog Buffering

You can tune the number of connection requests that a WebLogic Server instance accepts before refusing additional requests. This tunable applies primarily for Web applications.

See Tuning Connection Backlog Buffering.

Use Optimistic or Read-only Concurrency

Use optimistic concurrency with cache-between-transactions or read-only concurrency with query-caching for CMP EJBs to leverage the Entity Bean cache provided by the EJB container.

• Optimistic-concurrency with cache-between-transactions work best with read-mostly beans. Using verify-reads in combination with these provides high data consistency guarantees with the performance gain of caching. See Tuning WebLogic Server EJBs.

• Query-caching is a WebLogic Server 9.0 feature that allows the EJB container to cache results for arbitrary non-primary-key finders defined on read-only EJBs. All of these parameters can be set in the application/module deployment descriptors. See Concurrency Strategy.

Use Local Interfaces

Use local-interfaces or use call-by-reference semantics to avoid the overhead of serialization when one EJB calls another or an EJB is called by a servlet/JSP in the same application.

Note the following:

Note:

• In release prior to WebLogic Server 8.1, call-by-reference is turned on by default. For releases of WebLogic Server 8.1 and later, call-by-reference is turned off by default. Older applications migrating to WebLogic Server 8.1 and later that do not explicitly turn on call-by-reference may experience a drop in performance.

• This optimization does not apply to calls across different applications.

Use eager-relationship-caching

Use eager-relationship-caching to allow the EJB container to load related beans using a single SQL statement.

It improves performance by reducing the number of database calls to load related beans in transactions when a bean and it's related beans are expected to be used in that transaction. See Tuning WebLogic Server EJBs.

Tune HTTP Sessions

Optimize your application so that it does as little work as possible when handling HTTP session persistence and sessions. Also, design a session management strategy that suits your environment and application.

See Session Management.

Tune Messaging Applications

Oracle provides messaging users a rich set of performance tunables. In general, you should always configure quotas and paging.

See:

• Tuning the WebLogic Persistent Store

• Tuning WebLogic JMS

• Tuning WebLogic JMS Store-and-Forward

• Tuning WebLogic Message Bridge