Welcome!

Websphere Authors: Yeshim Deniz, Roger Strukhoff, Liz McMillan, Rajiv V. Joshi, Bruce W. McGaughy

Related Topics: Websphere

Websphere: Article

The Dynamic Caching Services

The Dynamic Caching Services

Server-side caching techniques have long been used to improve Internet performance of Web applications. In general, caching improves response time and reduces system load. Most techniques cache static content, which is data that changes rarely, if at all, such as graphics and text files. While the solutions for caching static content have resulted in excellent performance for some Web applications, they have little or no value in enhancing the performance of Web applications with dynamically generated pages.

For years, IBM Research has developed and refined technologies that enable the caching of dynamic content. These technologies were implemented, deployed, and verified at various high-volume sporting event sites such as the 1998 Winter Olympic Games in Nagano. The success of the sports sites demonstrated the feasibility and significance of caching dynamic content and confirmed the scalability and reliability of the caching technologies. Based on these proven and scalable caching technologies, IBM developed a dynamic content caching solution for Java 2 Enterprise Edition (J2EE) applications running on WebSphere Application Server Version 5.0. In this article we introduce WebSphere dynamic caching services.

WebSphere Application Server (WAS) offers a built-in dynamic caching service for serving dynamic content and caching data. The WebSphere development team often refers to this service simply as dynacache. There is no time-consuming installation and integration work needed to activate dynacache. The cache is enabled/disabled declaratively using simple XML configuration files or using the WAS Administrative User Interface; these methods not only allow caching to be brought up quickly and easily, but also provide great flexibility and control at runtime. Also, you can define your existing caches, such as the caching component of WebSphere Edge Server or IBM HTTP Server, as external caches and use them in conjunction with dynacache.

This article introduces the presentation-level caching features of dynacache. These features are:

  • Servlet/JSP result cache: Nonintrusive, effortless, and ready to cache any existing whole page or fragment generated by a servlet or JSP.
  • Command cache: Used to cache dynamic data before it is transformed into a presentable format (i.e., HTML).
  • Replication support: Enables cache sharing and replication among multiple servers and tiers.
  • Invalidation support: Includes rules-based, time-based, group-based, and programmatic cache invalidation techniques to ensure the freshness, consistency, and accuracy of the content.
  • Edge of network caching support: Extends the WAS caches into network-based caches, through the implementation of external cache control and distributed-fragment caching and assembly support.
  • Tools: Assist in configuring the cache and monitoring runtime.

    Caching Dynamic Content
    The key issues for caching dynamic content involve determining what should be cached, where caching should take place, and how to invalidate cached data.

    What Should Be Cached?
    Content or data that is changing and that at the same time must be stable over a long enough time for meaningful reuse to occur is a candidate for dynamic content caching . If access is frequent, such as with pricing information of a popular stock, then even a short period of stability may be of enough benefit to warrant the caching of dynamic content.

    All dynamic Web pages consist of smaller and simpler page fragments. Some fragments are static (such as headers and footers), while others are dynamic (such as fragments containing stock quotes or sports scores). Breaking a page into fragments or components makes effective caching possible for any page, even a highly dynamic page. The goal of creating fragments or components is to maximize fragment reusability and cache utilization.

    For example, Figure 1 shows that a page can be broken down into fragments based on reusability and cacheability. Some fragments - headers, footers, and navigation bars, for example - are reusable by all users who visit this site. Other fragments, such as watch lists and news, are not typically cacheable at the presentation level because of the personalized content being displayed. While some presentation fragments may not be reusable across a large set of users, the raw data contained within may very well be cacheable.

    Caching can involve a final formatted whole page (such as HTML or XML), a final formatted fragment, or a piece of unformatted raw data. Each, in its own way, contributes to the ultimate benefit of caching dynamic content. Dynacache offers features that enable dynamic content to be cached at various granularities, namely whole pages, fragments, and raw data.

    Where Should Caching Take Place?
    Theoretically, caching of dynamic content should take place as close to the user as possible. In reality, other factors such as security and user-specific data may influence the choice for the best place to cache dynamic content.

    Web application design can play an important role in determining where dynamic data is cached. One example is personalized pages. Although personalized, these pages may contain user-specific, nonuser-specific, locale-sensitive, secure, or nonsecurity-sensitive dynamic data. To maximize the benefit of caching dynamic content, these types of data should be fragmented as finely as possible so they can be cached independently at different locations. For example, the nonuser-specific, nonsecurity-sensitive fragments or components are generally useful to many users, and thus can be cached in a more public space and closer to users. The security-sensitive data should be cached behind the enterprise firewall.

    In a multitier e-business environment, dynacache can be activated at the business logic and/or presentation layer. It can also control external caches on servers, such as IBM WebSphere Edge Server and IBM HTTP Server. When external caching is enabled, the cache matches pages with their universal resource identifiers (URIs) and exports matching pages to the external cache. The contents can then be served from the external cache instead of the application server, which saves resources and improves performance. Additionally, dynacache's replication and invalidation support extends the cost-effectiveness of caching dynamic content by enabling cache sharing and cache replication in an environment containing multiple tiers and servers. Finally, WAS's edge of network caching support expands the application caches into the network.

    How Are Caches Invalidated?
    The biggest challenge when caching dynamic content is to guarantee the freshness, consistency, and accuracy of the content. This requires efficient and comprehensive mechanisms for identifying and updating pages/fragments/data that are no longer valid, a process called invalidation.

    Dynacache provides invalidation techniques that are rules-based, time-based, group-based, and programmatic. It can also invalidate the remote caches that were configured as its external caches. Dynacache uses a facility called the Data Replication Service, which is a JMS-based facility, to replicate cached data and propagate invalidate events within a WebSphere cluster.

    Dynamic Cache Service Architecture
    Figure 2 illustrates the architecture of dynacache. Dynacache operates within WebSphere's JVM to provide generalized Java object caching for use by various consumers. In order to minimize memory consumption, the caching service utilizes a modified LRU (least recently used) eviction policy for cached entries. As a service, dynacache can be configured, tuned, and monitored through WebSphere's systems management interfaces.

    In its simplest form, dynacache can be thought of as a highly functional Hashtable. One of its primary purposes is to store (put) and retrieve (get) Java objects from memory. As the various caching entry-points interact with the object store, dynacache manages the entries by controlling growth by running replacement or eviction algorithms. Entries in the cache are managed by a policy based on the class of entry (e.g., servlet/JSP, EJB, command, etc.). The policy is expressed as an XML file called cachespec.xml. The policy defines both global and class-specific characteristics of the cache. For example, cache size, replication policy, and disk offload configurations are globally defined for an instance of dynacache. However, much of the policy data is class specific, describing the rules by which Cache IDs are generated. Cache policies can be written to control servlet/JSP, command bean, and Web services response caching.

    Dynacache provides a disk overflow capability, known as Hash Table on Disk (HTOD), that is an optimized file store for serialized Java objects. The HTOD takes the form of a single logical disk file (which can expand to multiple physical 1GB files). Leveraging dynacache and HTOD allows for robust and centralized memory management and provides the potential to leverage networked file systems via NAS (network attached storage) and SANs (storage area networks) for high availability.

    To support caching done outside of the J2EE application space, the caching service can cooperate with external caches through its external cache adapter to actively trigger invalidations of cached Web content to registered adapters, which include the WebSphere HTTP Plugin, IBM HTTP Server, and its FRCA (Fast Response Cache Accelerator) cache, and the WebSphere Edge Server now shipped as part of WebSphere Application Server Network Deployment.

    Servlet/JSP Result Cache
    The servlet/JSP result cache intercepts calls to a servlet's service method, and checks whether the invocation can be served from a cache. If the servlet cannot be served from cache, it is invoked to generate the output that will be cached. The resulting cache entry contains the output; the side effects of the invocation, for example, calls to other servlets or JSP files; and the metadata about the entry, including timeout and entry priority information

    Servlet/JSP result cache caching can be based on:

    • Request parameters and attributes
    • The URI used to invoke the servlet or JSP
    • Session information
    • Other options, including cookies
    Figure 3 shows a sample dynamic Web page, MyTrade.JSP, which is composed of six included JSPs. Using servlet/JSP result caching, either the whole page generated by MyTrade.JSP or individual included JSP fragments can be independently cached within dynacache.

    Alternatively, the cache entries generated by the servlet/JSP result cache can be pushed to external caches, such as the cache component of WebSphere Edge Server or IBM HTTP Server. For J2EE applications that have high read/write ratios, the servlet/JSP result cache creates an opportunity for significant gains in server response time, throughput, and scalability. Moreover, since the servlet/JSP result cache is nonintrusive and is enabled declaratively, currently deployed and running servlets/JSPs can be configured to take advantage of dynamic content caching without changing any code.

    The Command Cache
    The command cache is used to cache dynamic data that requires back-end data retrieval, such as back-end database JDBC calls. The command cache forms a good synergy with the servlet/JSP result cache because in some cases even caching the most granular, final-formatted fragment is not sufficient. For example, a personalized page may contain a stock watch-list fragment (see Figure 4). This fragment consists of two sets of information: the watch list, which is highly personalized, and the corresponding stock symbol pricing information, which is generalized information and usable by many users.

    Suppose the stock list is the customer's stock portfolio, which is highly sensitive and is stored at the back-end server. In this case it is not effective to cache the final formatted fragment. Since the stock quotes are highly volatile, this fragment will be regenerated repeatedly. The net result is that every time this fragment is reconstructed, it is necessary to retrieve the stock list from the source. A better approach is to use the command cache to cache the stock list and avoid fetching the list continually from the back-end database.

    To use the command cache, user applications need to write to the WebSphere Command Framework API. The WebSphere Command Framework is based on the Command Design Pattern widely used in Java programming paradigms. Typically, these applications use "setters" to set the command's input states, one or more "execute" methods, and "getters" to retrieve the results. The results can be either formatted or raw data.

    The command cache intercepts the "execute" method call of a command written for the command cache and checks whether the command object can be served from the cache. If the command object does not exist in the cache, the logic in the execute method is performed and the resulting object is cached.

    The caching behavior of the command cache is defined declaratively with the XML cache policy file, which describes whether and how a command should be cached. The command cache can be used at the presentation and/or business logic layer in multitier environments.

    The command cache is easy to use. For existing applications that follow a Model-View-Control (MVC) design pattern, the command cache can be implemented with minimal impact to existing code.

    Replication Support
    Replication support further extends the value of caching in an e-business application. With this support, caches can be shared (central cache) or replicated (local cache) among servers. Replication can be enabled and configured declaratively with XML cache policy files. Cache policy also defines the cache entries or groups that should be shared or replicated.

    Replication support uses a built-in high-performance standards-based JMS messaging system as its underlying engine for data replication.

    Figure 5 shows an example of three servers configured to have their local caches replicated with each other. The messaging broker can be the built-in JMS broker belonging to one of the three servers. In this case, the broker is the built-in JMS broker at server one. A request for data (1) hits server one (or any of the three servers). If the requested data is not in the cache, the data is fetched from the back-end server (2). Resulting data from the back-end server (3) is cached at server one and then returned to the requester (4). When the cache of server one detects the cache update request, it publishes a message (a) regarding the change to the messaging broker. Whatever change occurred at server one is automatically replicated to server two (b) and server three (c).

    Invalidation Support
    The difference between caching static and dynamic content is the requirement for proactive and effective invalidation mechanisms, such as event-based invalidation, to ensure the freshness of content. Time-based invalidation alone is no longer adequate for dynamic cache invalidation.

    Dynacache provides rules-based, time-based, and group-based invalidation techniques. The WebSphere Application Server Enterprise Edition, version 5, offers access to programmatic cache and invalidation techniques. Invalidation policies can be defined with XML cache policy files. Invalidation policies allow triggering events to invalidate cache entries without the need to write explicit code. More complex invalidation scenarios may require code that invokes the invalidation API.

    The responsibility for synchronizing the dynamic cache of external caches with the application server is shared by both systems. For example, a public Web page dynamically created and cached at the application server using the servlet/JSP result cache can be exported by the application server and cached by the edge server's Caching Proxy. The Caching Proxy can then serve the application's execution results repeatedly to many different users until notified that the page is invalid. Content in the Caching Proxy's servlet response cache is valid until the proxy server removes an entry because the cache is congested, the default timeout set by the Caching Proxy's configuration file expires, or the Caching Proxy receives an invalidate message directing it to purge the content from its cache. Invalidate messages originate at the application server that owns the content and are propagated to each configured Caching Proxy.

    Edge of Network Caching Support
    External Cache

    Dynacache can use IBM HTTP Server's high-speed cache, referred to as the Fast Response Cache Accelerator, as its external cache, to cache whole pages and fragments.

    The Edge Components of WebSphere Application Server Network Deployment v5.0 can also be configured as the application server's external cache for whole-page caching. In such cases, dynacache can be enabled to match pages with their universal resource identifiers (URIs) and export matching pages to the external cache. The contents can then be served from the external cache instead of the application server to significantly save resources and improve performance.

    Figure 6 shows an example of exporting a dynamically cached page from the application server to the cache component of the edge server. More information about caching dynamic content at the edge of the network can be found in the white paper, "WebSphere Edge Services Architecture Guide to Edge Applications" (www-3.ibm.com/software/webservers/ edgeserver/doc/Guide_to_Edge_Apps_2.pdf).

    With dynacache's external cache control, distributed-fragment caching, and assembly support, dynamic content can be exported, cached, and assembled at the most optimal location, closer to the end user. More important, the WebSphere Application Server can maintain control of the external cache through its invalidation support to ensure the freshness of cached content. As a result, WebSphere Application Server is equipped to create and serve highly dynamic Web pages without jeopardizing page performance and user experiences.

    In Table 1, you can see which caching technique and cache distribution technique are most useful for each type of Web content.

    Tools
    WebSphere Application Server provides a variety of graphical user interface tools to help configure and monitor the dynamic content cache.

    Application Assembly Tool
    The Application Assembly Tool (AAT) is used to package application code components into the needed modules, which comply with the J2EE specification for deployment onto the application server. AAT can also be used to configure the cache policy associated with the application for caching.

    Cache Monitor Servlet
    The Cache Monitor Servlet is provided as an installable Enterprise Archive file that can be installed and used for monitoring cache statistics.

    Conclusion
    As more e-business sites seek to retain customers by serving personalized content, they face potential server-side bottlenecks, slow response time, and increasing infrastructure costs. The dynacache service employed by WebSphere can solve these critical challenges. Caching dynamic content that requires back-end requests or CPU-intensive computations can reduce server-side bottlenecks and maximize system resources, thus boosting performance and reducing infrastructure cost.

    Dynacache users can benefit from using the available comprehensive functions to cache their dynamic content. The servlet/JSP result cache and the command cache make possible the caching of dynamic content at various levels of granularity for the highest possible number of cache hits. The replication and invalidation support facilitates caches to be shared, replicated, and synchronized in multitier or multiserver environments. The edge of network caching support, with its external caches and fragment support, generates a virtual extension of application server caches into the network.

    Using dynacache can improve throughput and performance. As expected, improvements vary depending on how dynamic the data is, how well the pages are designed (fragmented) for maximum cache hits, and how costly it is to fetch and construct the content. Nevertheless, considerable benefits can be realized. Furthermore, the success of the IBM sports sites confirms the scalability and reliability of these underlying technologies in a truly high-volume environment.

  • More Stories By Gennaro Cuomo

    Gennaro (Jerry) Cuomo is a distinguished engineer at IBM. He has been a core member of the WebSphere development and architecture team since its inception in 1998. Jerry is CTO of the WebSphere Technology Institute, which is responsible for pursuing the next generation of WebSphere technologies.

    Comments (1) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    wesnur 11/25/09 05:10:00 AM EST

    Hi Catherine , Gennaro

    I have read your article thoroughly; it is in deed very informative one. There is no second thought that Dynamic Caching is the ultimate solution of the issues like Scalability, Reliability and Performance. But you haven’t talked about the topologies which can be used for dynamic caching. I wanted to request if you could please read this article and give you opinion about the topologies as well Benefits of using NCache Dynamic Clustering Capabilities.