Web Cache Enabling ADF Toystore
At the recent UK Oracle User Group I gave a presentation entitled "Web Cache Enable Your Application in 60 Minutes". Obviously with a title like that I received a 45-minute speaking slot. The objective was to use a minimum of powerpoint and a maximum of product to show how I could take an application and use web cache to accelerate delivery of the application content.
ADF Toystore
Preparing the presentation I first had to find an application, so I picked on
Steve Muench's ADF Toystore. This provides a simple web based toy store. I used this as an example of how to cache enable an application for no better reason than that I could get
the source code from OTN and the application compiled and ran easily.
Out of the Box Cache Enabling
Basic cache enabling of the ADF toystore required writing rules in the web cache to cache the content. By default only pages with a few specific extensions are cached. The list of extensions cached out of the box is
- Web pages:
.html &
.htm
- Images:
.jpg,
.jpeg,
.gif,
.png &
.bmp
- Java Script:
.js
- Cascading Style Sheets:
.css
Unless the above items are being dynamically generated there is little improvement in having web cache manage these items. I put a simple script together to exercise the application - browsing several different categories, drilling down into a few products and ordering an item. Using this script I established a baseline for the performance of ToyStore.
Accessing the application server (OC4J) directly on my laptop I got a baseline of 35 pages/second. I also measured the amount of data transferred across the wire for the duration of the test. The script generated some 4M bytes of data from the server.
I then repeated the test but this time pointed the test engine at the web cache with nothing other than out of the box configuration and rules. This gave me about the same download volume and page serving capability (actually they were 1% down on the container directly).
What to Cache?
So out of the box we don't normally get a massive performance boost so what can we do. First off is to figure out what are the most popular pages. Web Cache will show you the most popular uncached pages. You can then look at those pages to determine if they are cacheable. Doing this in my session we identified the following rules that could be applied :
- Category list rule "
/ADFToyStore/showcategory.do" - product details rule "
/ADFToyStore/showproduct.do" - Home page rule "
/ADFToyStore/home.do"
We made these rules path prefix rules and told the cache to cache any content starting with these prefixes. We used prefix to make it easier for web cache to match, rather than forcing it to use regular expression matching.
Rerunning the test suite saw a dramatic improvement in throughput to 205 pages/second or more than five and a half times the throughput without web cache.
At this point I decided to quit while I was ahead on the caching front and move on to another feature of the web cache.
Compression of Data
Web cache supports compression of data back to the browser. All browsers support this but it is rarely used by web servers because of the expense of compressing the data. For the presentation I turned on compression of responses for all the rules I had created. This yielded a 50% drop in bytes transmitted back to the server per test cycle, returning less than 2M rather than just over 4M of data. The throughput also fell slightly to 184 pages/second.
This could be crucial if you are using low bandwidth links or want to reduce the demands on your external comms infrastructure.
What's the Benefit?
So what is the benefit of using web cache. Well in our example with ADF toy store we reduced the network bandwidth by 50% and increased throughput by more than 400% even with compression turned on.
Put into real terms this means that for a given user volume I can get away with just 20% of the hardware originally needed and half the external network bandwidth. So if I originally needed 10 CPUs and 8Mbit internet link I can now run on 2 CPUs and a 4Mbit internet link. Now there is a return on investment for you!
Health Warning
Because I was doing this as a presentation I didn't have a brilliant test environment. Ideally I would have liked to have had a server for the database, a server for the app server, a server for the web cache and a server for the load generater. What I actually had was my laptop running Powerpoint as well as everything else. However a customer I worked with did have just this sort of set-up and he saw a 67% reduction in database CPU and a 75% reduction in middle-tier CPU when he enabled his caching rules - so this does work in the real world and not just in the Oracle demo world.