When caching is enabled for servlets and JSP Web components, EAServer checks for a cached response before calling the Web component. For servlets and JSPs that are called often, caching improves performance by skipping the processing required to produce the response. EAServer supports three mechanisms for response caching:
Dynamic page caching Responses are cached in a hash table, using a multi-part key. By default, the key includes the request path, but you can configure additional key parameters such as request or session attributes. “Dynamic page caching” describes how to configure this mechanism.
Servlet Java cache This mechanism caches servlet and JSP responses in core memory. It offers the best performance, but has stricter requirements on what can be cached. For example, you cannot cache servlets that return different content based on request or session parameters. “Using the servlet Java cache” describes how to configure this mechanism.
Partial page caching Partial page caching allows you to cache parts of a response. This mechanism is useful when pages contain volatile content, such as calculation results, but otherwise have static content such as headers and footers. The response cannot be cached effectively using other mechanisms because of the volatile content, but partial page caching allows you to cache only the static parts of a response. Partial page caching is supported by a tag library for use in JSPs, and a public API for use in servlets. “Using partial page caching” describes how to use this mechanism.
Not all Web components should be cached. Caching the output of seldom-called Web components can sometimes reduce performance. If the cache is full, the rarely accessed output can bump more frequently accessed data out of the cache. On the other hand, if a servlet takes a long time to execute, you may still benefit from caching a servlet that it is not called as frequently as others, as long as there is sufficient space to cache the servlet. When the cache is too full to add or refresh a response, EAServer removes enough entries to make room, removing entries in least-recently-used order.
There is some overhead required to create and remove cache entries. If a Web component runs quickly, you may get better results with caching disabled, thus avoiding the overhead of maintaining additional cache entries and reserving more memory for the caching of other Web components.
To decide which Web components should be cached, review your request log patterns and Java profiling data (or timing trace data) to answer the following questions:
How often is the Web component invoked?
How long does it usually take?
How often can requests use the cached data? If not always, can you define a key based on request and session parameters to allow the correct response to be cached and reused? Does a timeout suffice to satisfy the requirements for accurate data?
Based on these answers, you can determine which Web components are appropriate to cache and estimate the time that can be saved by caching them. For example, if you specify a timeout of 1 minute, the response takes 5 seconds to process, and the matching request occurs 4 times per minute, you can eliminate up to 15 seconds of processing time per minute (based on the fact that there are 3 cache hits per minute before the matching entry times out and must be recalculated).
To enable caching, you must define EAServer Web components for JSPs as well as servlets. Although a JSP can run when it is not installed as a Web component, you cannot enable caching unless you have defined a Web component that is mapped to the JSP. For example, to create and map a Web component for a JSP defined in myJSP.jsp:
Create a JSP Web component called “myJSP”.
Set the file property to “myJSP.jsp”.
Create a Web application servlet mapping where servlet = “myJSP” and URL Pattern = “/myJSP.jsp”.
For more information, see “Creating and configuring JSPs in EAServer” in Chapter 24, “Creating JavaServer Pages,” in the EAServer Programmer’s Guide.
