Tuning Oracle Coherence*Web Applications

The following is the fourth of five posts which will list the best practices and performance suggestions for tuning one’s Oracle Coherence environment.  This is a general guide that will evolve as new product features are added to Oracle Coherence.

Oracle Coherence*Web

Oracle Coherence*Web is an HTTP session management module and a drop-in replacement for application server container session management. It basically “wraps” existing web applications, no runtime byte code manipulation is done and any requests to use sessions (from servlets, JSPs, filters, etc) are intercepted by Oracle Coherence*Web wrappers.  For more details you can look at:

Coherence*Web Session Management Module
Coherence*Web and WebLogic Server
Coherence*Web and Other Application Server Containers

 

High-Level Steps to enable Oracle Coherence*Web

• Run the inspector on the existing WAR/EAR file (This generates a coherence-web.xml configuration file. This file wraps all servlets, filters, etc with Coherence implementations. It also contains configuration settings for Coherence*Web)

• Inspect and (if any changes are required) modify the coherence-web.xml file

• Run the installer process on the existing WAR/EAR which generates a new WAR/EAR and backs up the original WAR/EAR.

• You now deploy the new WAR/EAR to the Application Server Container

• The complete steps for the Oracle WebLogic Server are listed here.

 

Troubleshooting Oracle Coherence*Web

• Obtain a baseline for the application without Coherence to properly determine how sessions are being used and replicated. This will make it easier to compare with Coherence and further troubleshoot.
• Network throughput can be an issue as well. Run a datagram test to determine how much one can push between machines. This will help tune the network between the web application tier and the data grid. Review the first post in this series and specifically in the networking section.
• The session model will be a factor in the performance; the split session model is default and will keep small session attributes in the near cache while large ones will be accessed from the grid. If the application regularly uses lots of large attributes, another model may be more appropriate. Review the Session Models at this link.
• Review their cache configuration file. From a web application caching perspective, Coherence*Web in a web-app really gets a big benefit from a near caching scheme, where objects of a size less than 1K are kept in the local JVM, avoiding the network hop and marshalling/deserialization.
• If one is deploying multiple web applications, sometimes it's desirable to share session attributes and sometimes it is not. There is configuration for scoping link on this page.
• For sizing it depends on the web-application and how the web-application uses the session to determine the proper size of the grid. Some testing with some average test cases should be used to arrive at a metric such as “1 user takes X MB in the grid”.