Top Tuning Recommendations for WebLogic Server
- Tune Pool Sizes
- Use the Prepared Statement Cache
- Use Logging Last Resource Optimization
- Tune Connection Backlog Buffering
- Tune the Chunk Size
- Use Optimistic or Read-only Concurrency
- Use Local Interfaces
- Use eager-relationship-caching
- Tune HTTP Sessions
- Tune Messaging Applications
Tune Pool Sizes
- 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.
- For releases prior to WebLogic Server 9.0
In general, the number of connections should equal the number of threads that are expected to be required to process the requests handled by the pool. The most effective way to ensure the right pool size is to monitor it and make sure it does not shrink and grow.
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. 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.
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.
Tune the Chunk Size
A chunk is a unit of memory that the WebLogic Server network layer, both on the client and server side, uses to read data from and write data to sockets. A server instance maintains a pool of these chunks. For applications that handle large amounts of data per request, increasing the value on both the client and server sides can boost performance.
Use Optimistic or Read-only Concurrency
Use optimistic concurrency with cache-between-transactions or read-only concurrency with query-caching for CMP EJBs wherever possible. Both of these two options 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.
- 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.
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:
- In release prior to WebLogic Server 8.1, call-by-reference is turned on by default. For releases of WebLogic Server 8.1 and higher, call-by-reference is turned off by default. Older applications migrating to WebLogic Server 8.1 and higher 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 wherever possible. This feature allows 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.
Tune HTTP Sessions
Optimize your application so that it does as little work as possible when handling session persistence and sessions. You should 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. See:
- Tuning the WebLogic Persistent Store
- Tuning WebLogic JMS
- Tuning WebLogic JMS Store-and-Forward
- Tuning WebLogic Message Bridge