Using the dynamic cache service to improve performance
Caching the output of servlets, commands, and JavaServer Pages (JSP) improves application performance. 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 that are set in the dynamic cache service of an application server. You can use the dynamic cache to improve the performance of servlet and JSP files by serving requests from an in-memory cache. Cache entries contain servlet output, the results of a servlet after it runs, and metadata.
The dynamic cache service works within an application server Java virtual machine (JVM), intercepting calls to cacheable objects. For example, it intercepts calls through a servlet service method or a command execute method, and either stores the output of the object to the cache or serves the content of the object from the dynamic cache.
The dynamic cache service is enabled by default. You can configure the default cache instance in the administrative console.
Configure the type of caching that you are using:
Configuring servlet caching.
Configuring portlet fragment caching.
Configuring Edge Side Include caching.
Configuring command caching.
Caching Web services.
Configuring the JAX-RPC Web services client cache.
Monitor the results of your configuration using the dynamic cache monitor.
Dynamic caching refers to the methods employed by WebSphere Application Server either to provide fragment caching or to reuse components within the application server engine. Fragment caching means that only some portions of a page are cached.
Dynamic caching is enabled at the application server container services level. Cacheable objects are defined inside the
cachespec.xml file, located inside the Web module
WEB-INF or enterprise bean
cachespec.xml file enables you to configure caching at a servlet/JSP level. The caching options
cachespec.xml file must include sufficient details to allow the dynamic cache service to build a unique
cache-key. This cache-key is used to uniquely identify each object. This might be achieved by specifying request parameters,
cookies, and so on. The
cachespec.xml also file allows you to define cache invalidation rules and policies.
Note: Pay special attention to the servlet caching configuration, because you create unexpected results by returning a cached servlet fragment that is stale.
Another dynamic caching option available is Edge Side Include (ESI) caching. ESI caching is an in-memory caching solution implemented through the Web server plug-in, WebSphere proxy server, or the DMZ secure proxy server. If dynamic caching is enabled at the servlet Web container level, the plug-in uses ESI caching.
An additional header is added to the HTTP request by the caching facility, called the
header. The application server returns a
Surrogate-Control header in the response. Then, depending on the rules
specified for servlet caching, you can cache responses for JSP and servlets.
With replication, data is generated one time and copied or replicated to other servers in the cluster, saving time and resources. Caching in a cluster has additional concerns. In particular, the same data can be required and generated in multiple places. Also, the permission the resources need to generate the cached data can be restricted, preventing access to the data.
Cache replication deals with these concerns by generating the data one time and copying it to the other servers in the cluster. It also aids in cache consistency. Cache entries that are not needed are removed or replaced.
The data replication configuration can exist as part of the Web container dynamic cache configuration
accessible through the administrative console, or on a per cache entry basis through the
cachespec.xml file. With the
cachespec.xml file, you can configure cache
replication at the Web container level, but disable it for a specific cache entry.
Cache replication can take on three forms:
PUSH - Send out new entries, both ID and data, and updates to those entries.
PULL - Requests data from other servers in the cluster when that data is not locally present. This mode of replication is not recommended.
PUSH/PULL - Sends out IDs for new entries, then, only requests from other servers in the cluster entries for IDs previously broadcast. The dynamic cache always sends out cache entry invalidations.
You can override the global sharing policy by specifying a specific sharing policy in the cache policy. For example, if your global policy is to use PUSH only, you can change the sharing policy of a specific cache entry by making this change to your cache policy:
<cache-entry> <sharing-policy>not-shared</sharing-policy> <class>servlet</class> <name>/app</name> <cache-id> <component id="action" type="parameter"> <value>portfolio</value> <required>true</required> </component> <component id="JSESSIONID" type="cookie"> <required>true</required> </component> <property name="EdgeCacheable">true</property> </cache-id> </cache-entry>