Dynamic caching with Trade and WebSphere
The dynamic cache service improves performance by caching the output of servlets, commands, and Java™ Server Pages (JSP) files.
By caching the response from servlets, Web services, JSPs, and WebSphere® Application Server commands, the application server does not have to perform the same computations and backend queries multiple times.
The WebSphere Application Server consolidates several caching activities, including servlets, Web services, and WebSphere commands into one service called the dynamic cache. These caching activities work together to improve application performance and share many configuration parameters, which are set in an application server's dynamic cache service.
The dynamic cache works within an application server Java Virtual Machine (JVM) by intercepting calls to cacheable objects. For example, calls through a servlet's service() method or a command's execute() method. The dynamic cache then either stores the object's output to the dynamic cache, or serves the object's content from the dynamic cache. J2EE applications are likely to have high read/write ratios and can tolerate a small degree of latency.
To make the data current, the dynamic cache can create an opportunity for significant gains in server response time, throughput, and scalability. However, the possible use of dynamic caching technology should be reviewed with application developers and owners. This is so that they will design and program to ensure that data validity is maintained, should WebSphere data caching be activated.
A cache hit is generally served in a fraction of the time of a non-cached request. Significant performance gains are generally achieved with Trade when dynamic caching technology is used.
- The size of the cache, which is expressed as the maximum number of entries that the cache can hold. This value is set using the WebSphere Application Server administration console under . The actual caching service mode is set by each application individually.
- The priority, disk cache setting, and Domain Replication Services (DRS).
WebSphere Application Server V6.0 provides two interfaces, DistributedObjectCache and Distributed Map. These applications are used by J2EE applications to cache and share Java objects by storing a reference to the object in the cache. These interfaces expand on the command bean and servlet fragment caching capabilities already provided in previous versions of WebSphere Application Server. By default, the caching capabilities within Trade are disabled. However, the caching type can be modified to use either the Distributed Map interface or the command bean caching (Command caching) interface.
- No cache
- No caching is used.
- Command caching
- This caching feature was added to WebSphere Application Server V5.0 for storing command beans in the dynamic cache service. Support for this feature was added in Trade 3 and carried over to Trade 6.
- Distributed Map
- This feature is new in WebSphere Application Server V6.0, providing a general API for storing objects in the dynamic cache service.
For the measurements taken in this study, all three caching modes (No cache, Command Caching, and Distributed Map caching) were used. See web.xml in web.xml setup examples for the section of the web.xml file to modify in order to use dynamic caching.
Dynamic caching requires that the application supply a cachspec.xml file (found in directory /opt/IBM/WebSphere/AppServer/profiles/default/installedApps/<WebSphere node>/trade.ear/tradeWeb.war/WEB-INF) that defines the caching policies for the application. File cachespec.xml (see web.xml setup examples) contains the file that was used for all measurements in these tests.
The cachespec.xml file specifies the caching behavior for command caching and servlet caching.
For Distributed Map caching, the application uses the Distributed Map API to control caching behavior.