Welcome!

Websphere Authors: Jim Kaskade, Pat Romanski, Elizabeth White, Bob Gourley, Gilad Parann-Nissany

Related Topics: Websphere

Websphere: Article

Caching In

Expediting content delivery with the dynamic cache service

The quest for increased application performance is a science in itself. IBM WebSphere Application Server includes a powerful caching technology called the dynamic cache service, which you can employ in your Web applications to dramatically improve performance.

In this article, we'll use the dynamic cache service to increase the performance of a simple Web application. We will then use Apache JMeter, an open source load generator, to load-test our cached application in order to measure the application performance gains achieved by leveraging the dynamic cache service.

As you will see, the potential performance gains realized by using the dynamic cache service can be achieved with minimal effort. No changes to your application code are required, which means there is no impact on application portability.

The dynamic cache service is the name given to a set of services provided by WebSphere Application Server. The types of caching services include servlet and JSP caching, a Java object cache facility, a cache for Web services, and a command cache. In this introductory article our example will focus on the use of the servlet and JSP caching facility.

Enter Stage Left - Our Application to Tweak
Our demonstration application is implemented as a servlet that fetches a large piece of content from a remote HTTP server, then performs some text processing and returns the result to the end user. Our servlet grabs content from the Gutenberg Web site, which hosts downloadable books in ASCII format (www.gutenberg.net). For those unfamiliar with the Gutenberg project, this site hosts downloadable books that have expired copyrights and are therefore freely available.

Our example servlet will perform some text processing on the downloaded book: it will italicize the introductory section in the book's text that describes the Gutenberg project. We will test the performance before and after turning on caching and then compare the results. Once caching is enabled, the book will be downloaded on the first servlet request and presented to the user. Subsequent servlet requests will be served from the cache.

The servlet code (see Listing 1) is simple and straightforward, and uses standard Java packages and classes to read, parse, and transmit the content.

The servlet opens a URL connection to a book on gutenberg.net (see Figure 1) and copies the output to the servlet's output stream. The first section of the book contains the Gutenberg preamble (disclaimers and such), which the servlet puts in italics. Once the servlet reaches the end of the preamble (marked in the text stream with "*END*" at the end of a line), the servlet stops italicizing and switches to a more readable font for books (Times). The servlet also logs how long it took to produce the result, which has the side effect of showing us when the servlet is called (versus served from the cache). This will be handy once we enable caching because the log will show that WebSphere is using the cached result and bypassing the servlet call completely.

You can download an EAR file containing the servlet and test the performance on your own system. The source code for this article can be downloaded from www.sys-con.com/websphere/sourcec.cfm.

To see the effect of using dynamic caching in our application, we'll juxtapose the performance of our application with and without caching enabled. To study our application's performance, we'll leverage Apache JMeter. It is beyond the scope of this article to delve into the details of how to use JMeter, but you can learn more about how to use JMeter at www.devx.com/webdev/Article/17950/0. JMeter allows us to simulate a load of requests against our application server and measure subsequent performance.

We used JMeter v1.9.1 from http://jakarta.apache.org/jmeter. Our test environment consisted of one machine running WebSphere Studio Advanced Edition 5.0.1 with the WebSphere v5.0 Test Environment on a Windows 2000 Pro machine configured with a single AMD 3000+ processor and 1GB of RAM. We ran JMeter on the same machine. Since this example is "I/O-bound," running JMeter on another machine does not significantly affect performance. We used WebSphere Application Server 5.0.1, but other versions will yield similar results.

We configured JMeter with a "Jakarta Users" thread group, using 5 threads and 100 iterations (see Figure 2).

Under the thread group we added an HTTP request to access our servlet. We used port 9080 to access our servlet's Web container directly (see Figure 3). Figure 4 shows the results of our baseline (precache) test.

It's not too surprising that the average servlet response time is almost 15 seconds; it takes time to process and transmit 901K of text. Because each request takes so long (by design), our throughput is a mere 18.7 requests per minute. Our next step is to enable the dynamic cache service and measure the performance improvement.

Enabling the Dynamic Cache Service in WebSphere Application Server
Enable the dynamic cache service in the WebSphere administrative console as follows: open the administrative console, click Servers > Application Servers in the navigation tree, click on your server, and select Dynamic Cache Service under Additional Properties. Select Enable service at server startup in the Startup state field and click OK.

Enable servlet caching as follows: in the administrative console, click Servers > Application Servers in the navigation tree, select your server, and click Web Container. Check the Enable servlet caching checkbox under the Configuration tab. Click Apply or OK.

To complete the configuration changes, click Save on the top menu bar, click the Save button, and then restart the application server.

Configuring Our Servlet to Use Dynamic Cache
To specify the cache settings for our servlet, we created a cachespec.xml file (see Listing 2), located in the WEB-INF subdirectory of our WAR file. Let's take some time to discuss some of the cache settings in this file.

  • sharing-policy: We set this to shared-pull, which means that the cached data will be shared across nodes in a clustered environment, and that each node will have to pull (request) the data from other nodes. The other options are not-shared, shared-push, shared-pull, and a hybrid mode called shared-push-pull. These options are described in detail in the WebSphere Application Server InfoCenter.
  • name: This is the URI of the servlet to cache; it can be relative to the Web application context root, as is ours.
  • cache-id: This section describes how WebSphere should build the unique identifiers' cache entries. The components of the cache ID serve as rules that the cache manager uses to build a key value. For servlets, there are nine types of components that you can use to build a cache ID construction rule, giving you rich control over what content in your application is cached. In our example, we used components consisting of any parameters passed in on the servlet request, the URI path, plus a header field called "host" in the request. At least one of these components must be non-empty, otherwise the dynamic cache service will simply not cache the data for that request.
  • timeout: By specifying a time-to-live value of 0, we specify that we want our cache entry to live indefinitely. Specifying a positive number would define the number of seconds we want the cache entry to exist in our cache.

    We have only scratched the surface of the configuration parameters you can set for a cacheable object. For example, you can opt to persist cache entries to disk in case of overflows or the housing server being stopped. Refer to the WebSphere Information Center (www-306.ibm.com/software/webservers/appserv/infocenter.html) to find out more information about which parameters can be used to achieve the desired caching effect you'd like to associate with a specific cacheable object. These design considerations are of course specific to your enterprise application's business requirements.

    The WebSphere Application Server continually monitors the cachspec.xml file for changes, so the changes will take place immediately when you save the file. You therefore don't need to restart your enterprise application or application server when you want to make adjustments to your caching strategy.

    The Performance Gain with the Dynamic Caching Service Enabled
    Once we saved our cachespec.xml file in the WEB-INF directory, WebSphere Application Server noticed the new file, and wrote the following line to System.out:

    [2/2/04 17:09:50:812 CST] 435b6a5a ConfigManager I DYNA0047I: Successfully loaded
    cache configuration file k:\wsad\workspace5\Dynamic Cache Example\Web
    Content\WEB-INF/cachespec.xml.

    Then we reran our JMeter test. Figure 5 shows the results.

    We started with a throughput of 18.7 transactions per minute, and with cachspec.xml in place we were able to achieve quite a bit more: 568 transactions per minute. The average time to serve a request went from 14.9 seconds down to a speedy 0.416 seconds. The dramatic improvement demonstrates the power of using WebSphere's dynamic caching service.

    Our test servlet was deliberately constructed to demonstrate a dramatic effect, but most Web applications that do any processing or back-end calls will benefit substantially from using the dynamic cache service. It's important to point out that we didn't need to make any changes to our servlet code. We simply created a cachespec.xml file in our WEB-INF directory and witnessed an immediate performance improvement.

    WebSphere Application Server 5.0 ships with a Cache Monitor application (see Figure 6) that allows you to use a Web browser to view reports on cache statistics, and also allows you do things like view the cache IDs of objects in the cache.

    The Cache Monitor is located in the <WAS_ROOT>/installableApps directory (CacheMonitor.ear) and is easy to install and use. After you have installed the Cache Monitor enterprise application, open the URL: http://<your_server>:<your_port>/cachemonitor. You can use the Reset Statistics and Clear Cache buttons to clean out the cache and get ready for another load test after you tweak the caching policy settings in your cachespec.xml file. This saves time, since you won't have to restart the application server between load tests.

    Conclusion
    Java servlets and JavaServer Pages are typically used to present dynamic content to a Web site visitor. WebSphere Application Server's dynamic cache service can be used to serve requests for content from an in-memory cache. Servlet output is stored in memory, expediting delivery to the end user.

    In this article, you used the dynamic cache service offerings on a Web application and witnessed the added performance benefits using Apache JMeter. The process of enabling WebSphere Application Server's dynamic cache service and modifying your Web application to use dynamic caching is rather simple. Leveraging these highly configurable caching options should be a major consideration for organizations trying to squeeze the most performance out of their application servers. You can learn more about the dynamic cache service in the WebSphere Information Center.

    Resource:

  • Using the dynamic cache service to improve performance: Click Here !

    Acknowledgment
    The authors would like to thank Lisa Tomita for her review of this article.

  • More Stories By Kulvir Singh Bhogal

    Kulvir Singh Bhogal works as an IBM Software Services for WebSphere consultant, devising and implementing WebSphere-centric solutions at customer sites across the nation. He has over fifty patents pending in a myriad of technology areas. He can be reached at kbhogal@us.ibm.com

    More Stories By Brad Bouldin

    Brad Bouldin works as an IBM Portal specialist assisting customers with planning, architecting, and implementing e-business solutions.

    Comments (2) 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
    Carlos Melvin 04/14/04 05:24:26 PM EDT

    I have been reading a little on dynamic cache service. I have yet to see any reference to a system other than Windows. Does this work on an AIX platform?

    Pierre Comtois 03/31/04 02:06:01 PM EST

    How would the cache work/react when using the same JSP as a template for dynamic data recovered from a DB. An application we implemented with older version of WAS involved using about 10 template JSPs and populated over 10000 different "pages" on-demand, a "page" being a template with simply different content. Each "page"''s content was retrieved by the servlet and command classes based on keys present on the URL.

    Thx ...