8 Simple Caching Rules

Web Caching Your Application for Fast

Response Time

An Oracle Technical White Paper

Supplementary to Oracle OpenWorld Technical Session
December 2004
 8 Simple Caching Rules

Executive Summary .......................................................................................... 3

Introduction ....................................................................................................... 3
Rule 1: Cache All Static Content..................................................................... 3
Rule 2: Monitor Popularity And Content Generation Time....................... 4
Rule 3: Document Size Matters....................................................................... 6
Rule 4: Plan Ahead On Invalidation And Expiration .................................. 6
Rule 5: Use ESI For Partial-Page Caching .................................................... 7
Rule 6: Compression Saves Bandwidth.......................................................... 8
Rule 7: Tune Configuration Parameters......................................................... 8
Rule 8: Use Web Cache For SSL Termination ............................................. 9
Conclusion........................................................................................................ 10

8 Simple Caching Rules – Web Caching Your Application for Fast Response Time Page 2
 8 Simple Caching Rules

EXECUTIVE SUMMARY
With the arrival of Web caching technology, enterprises no longer have to
compromise the sophisticated look-and-feel of a page in exchange for fast page
delivery. In fact, caching has become a basic element in any Web application design
and deployment. Therefore, an understanding of the application structure and
network systems is important to apply caching effectively. As part of Oracle
Application Server, OracleAS Web Cache enables system administrators and
application developers to optimize performance based upon application uniqueness
and system network parameters. In this paper, the eight simple caching rules are the
key principles to achieve the shortest response time at peak traffic load.

INTRODUCTION
Web caching is essential to speeding up any Web applications. By reducing the
frequency of repeatedly generating content, caching operates according to a caching
policy, based upon the application and the parameters of the system networks.
OracleAS Web Cache 10g is the software industry's leading application acceleration
solution that is designed to accommodate any Web applications and system
environments. OracleAS Web Cache leverages state-of-the-art caching and
compression technologies to optimize application performance and more efficiently
utilize low-cost, existing hardware resources. OracleAS Web Cache is application-
aware; it understands the content of HTTP headers. This level of awareness enables
OracleAS Web Cache to cache any applications without major code rewrite.
Furthermore, OracleAS Web Cache offers built-in workload management to ensure
application reliability and to help maintain quality of service under heavy loads.
Expressed in eight simple caching rules, this paper presents the essential ideas on
Web caching.

RULE 1: CACHE ALL STATIC CONTENT

Static content that changes infrequently is most suitable for caching. OracleAS Web
Cache requires no application changes to cache content in formats such as jpeg, gif,
pdf, css, wav or JavaScript, including requests made using the HTTP POST
method. Additionally, OracleAS Web Cache can cache non-200 HTTP responses
generated by the origin servers. This is useful for blocking denial-of-service (DoS)
attacks or caching redirects. Instead of waiting for the origin server to try to process

8 Simple Caching Rules – Web Caching Your Application for Fast Response Time Page 3

OracleAS Web Cache can cache non-200
HTTP responses, including those resulting
from denia-of-Service attacks and
redirects.
an illegitimate request, OracleAS Web Cache serves a pre-set response (typically, an
apology page) so that the request never reaches the origin server.
OracleAS Web Cache supplies a set of default cacheability rules to cache the basic
static content. Users may also customize and turn on or off cacheability rules using
Oracle Enterprise Manager Application Server Control Console or OracleAS Web
Cache Manager.
A cacheability rule of a particular URL expression may be applied on objects
ending with a file extension, matching a path prefix, or matching regular expression
syntax. Multi-version URL caching uses session cookies or URL parameter to
enable OracleAS Web Cache to distinguish pages with the same URL. Because
OracleAS Web Cache understands the content of HTTP headers, it can cache and
serve different content to different categories of end user, handling personalized
pages.
RULE 2: MONITOR POPULARITY AND CONTENT GENERATION TIME
OracleAS Web Cache and Oracle Enterprise Manager Grid Control collect and
maintain application performance data, including runtime statistics and historical
metrics of end users’ response time. The data is useful for system health checks and
tuning OracleAS Web Cache. Both Popularity and Content Generation Time are
pivotal factors in determining whether an object should be cached.
The Popular Requests page displays both cached and non-cached requests in the
order of their popularity, as shown on the following screenshot:
A requested object’s popularity is based on the number of recent requests for an
object. The Popular Requests page serves as a guideline for the following:
• Caching: the most popular objects should be cached if possible
8 Simple Caching Rules – Web Caching Your Application for Fast Response Time Page 4
 • Compression: verify that the most popular objects are being served
compressed
• Cacheability rule ordering: cacheability rules which match more popular
objects should be listed before less frequently used rules

The Performance page includes a breakdown of client requests, categorized by

cache hit (objects served directly from the cache) or cache miss (objects that
OracleAS Web Cache has to request from the origin server). The higher the cache
hit percentage, the better. Miss requests are further divided into cacheable misses
and non-cacheable misses. Cacheable misses are miss requests where the object is
deemed cacheable and is stored in OracleAS Web Cache for subsequent requests
for the same object.
For cache misses, a high percentage of non-cacheable miss indicates that there may
URL redirects are some of the most
be other possible cacheable objects. Create new cacheability rules for those popular
popular pages and are often cacheable.
objects as indicated in the Popular Requests page. On the other hand, a high
cacheable miss percentage may be caused by a number of reasons, including short
expiration time, frequent invalidations or a lack of demand for already cached
objects. In this case, check the expiration and invalidation policies. More details on
this subject are covered in Rule 4.
Using OracleAS Web Cache and Oracle Enterprise Manager Grid Control, system
administrators can measure how quickly the responses are reaching to the end
users. A sample analysis output is shown in the following screenshot:

From the time the users enter the Web site until they exit, End User Performance
Monitoring identifies the URLs the users have visited and reports the response
times measured from the end users’ perspectives.

8 Simple Caching Rules – Web Caching Your Application for Fast Response Time Page 5
RULE 3: DOCUMENT SIZE MATTERS
As explained in Rule 1 and Rule 2, always cache objects that are popular, rarely
change or are resource-intensive to generate. How do large objects fit into this
case?
While large objects may be expensive to generate, the key criteria for whether or
not to cache them is the objects’ popularity. OracleAS Web Cache automatically
“ages out” objects that are rarely requested and those have been in the cache for a
long period of time1. By the same token, when the cache approaches its maximum
cache size, garbage collection removes less popular or old objects. Storing large
objects demands more memory and thus increases the probability of garbage
collection during which OracleAS Web Cache cannot put any objects into the
cache. As a result, frequent garbage collection can seriously hamper the efficiency
of OracleAS Web Cache.
Unless a large object is very popular (relative to other objects that are potentially
cacheable), the expense of consuming extra memory in OracleAS Web Cache may
outweigh the benefit of caching it. Should you need to cache large objects, make
sure that the computer on which OracleAS Web Cache is running has sufficient
memory. To limit the size of objects that can be cached, set a maximum object size.

RULE 4: PLAN AHEAD ON INVALIDATION AND EXPIRATION

Invalidation and expiration are two key mechanisms for marking cached objects as
not useable. Using them carefully and wisely enhances the efficiency of OracleAS
Web Cache and ultimately the overall performance of the Web application.
Expiration is the maximum time that OracleAS Web Cache is allowed to serve a
given object. Expiration is useful for objects whose changes are predictable (for
example, updated every night at midnight) or for objects that change frequently.
The expiration granularity is in seconds, so even frequently changing, yet popular,
objects can be cached for a short period of time. For example, if there are 100
requests per minute for a given object, the object can be set to expire after 60
seconds. This would still allow OracleAS Web Cache to serve 99% of the requests
for this object from the cache.
When an object expires, OracleAS Web Cache uses the “If-Modified-Since” header
to refresh the object. The origin server can respond with a “Not Modifed”
response, from which OracleAS Web Cache re-validates the object in its cache with
a new expiration time.
Expiration policies are set when the object is inserted into OracleAS Web Cache
through one of the following ways:

1 Age, popularity and size are all relative concepts in Web caching. An object that is

“old’ may mean that it has been in the cache for 10 minutes compared to another
object that has been in the cache for 1 minute.

8 Simple Caching Rules – Web Caching Your Application for Fast Response Time Page 6

OracleAS Web Cache supplies some
sample scripts and APIs for Java, Perl, C,
and PL/SQL for programmatic invalidation.
• Expiration Rule: an expiration policy is explicitly embedded a given
cacheability rule
• Standard HTTP headers: OracleAS Web Cache uses the Expires or Cache-
Control header information provided in the response from the origin
server
• Surrogate-Control header: an OracleAS Web Cache specific directive, the
surrogate-control header generated by the origin server specifies the
expiration policy for the given object
Used jointly with expiration or by itself, invalidation provides a higher level of
control and is useful for infrequent changes or for objects that must be up-to-date
at all times. Invalidation is performed by sending an XML message to OracleAS
Web Cache. The invalidation message may be generated programmatically by an
application or manually through the administrative console. The message contains
a list of expressions for matching objects in the cache. It can also contain “keys”
for marking a group of objects unusable. These keys are part of the origin server’s
response.
RULE 5: USE ESI FOR PARTIAL-PAGE CACHING
Web pages with sections of the page that get updated at a different rate from other
sections, while not desirable for full page caching, are good candidates for partial-
page caching. Since the page fragments are intended for reuse, the best way to
approach partial-page caching is through a standard development methodology.
This belief gives birth to Edge Side Includes (ESI)-an open standard for fragment
caching and assembly. An extension of ESI in Java (or JESI in abbreviation) is part
of JSR 128.
ESI development is based on the concept of a template and page fragments. Each
template and page fragment has its own caching policy, as expressed as in the
surrogate-control element within an ESI tag. The fragment can be set to expire or
be invalidated programmatically. Oracle Application Server Web Cache Administrator’s
Guide and JSP Tag Libraries and Utilities References detail how to use ESI tags and JESI
tags.
Two ways that applications can adopt ESI are Include (<esi:include>) and
Inline (<esi:inline>):
• In the Include approach, the template and the page fragments are
physically separate. Within the template, the ESI include tag defines a
reference to the fragments by specifying the name of the fragments.
OracleAS Web Cache assembles the entire page by inserting the fragments
into the template at the point of delivery. A fragment referenced by an ESI
include tag must always be independently fetchable by HTTP/HTTPS.
The request URL is the same as the fragment name.
8 Simple Caching Rules – Web Caching Your Application for Fast Response Time Page 7
 • The Inline approach defines the template and the page fragments logically.
The Inline approach is intended for existing applications that are generated
as one whole page. Because the page fragments may not be independently
fetchable, OracleAS Web Cache requests the entire page should the cache
need any of these fragments or templates. The ESI inline tag is inserted
into the page with the fragment name to demarcate the fragment.
OracleAS Web Cache recognizes ESI inline tags and stores the enclosed
portions as separate fragments and the original page as a page template
without the enclosed fragments. Fragments are shared if their names are
identical.
The difference between <esi:include> and <esi:inline> is that the
Inline approach expects the whole page to be loaded the first time. If the
fragments are defined to be fetcheable, then only the fragments are refreshed
subsequently. The big advantage of using <esi:inline> is that the application
will still run even without an ESI processor.

RULE 6: COMPRESSION SAVES BANDWIDTH

Compression is particularly useful in environments wherea network bandwidth is
narrow. Most browsers today support gzip encoding. Upon detection of the gzip
header, OracleAS Web Cache compresses the document before it serves it.
OracleAS Web Cache stores the document in compressed form to save memory.
OracleAS Web Cache serves a compressed document streamed, meaning it starts to
deliver the document as OracleAS Web Cache compresses the document. From
the end user’s perspective, the content appears on the browser earlier instead of
waiting for the arrival of the entire document.
Oracle eBusiness Suite 11i10 leverages OracleAS Web Cache’s compression
technology to reduce page size for wireless delivery. A page that is typically 50-60 K
is drastically reduced to 5 K.

RULE 7: TUNE CONFIGURATION PARAMETERS

The effectiveness of Web caching is dependent on the hardware on which it runs,
the network and the operating system. Network architecture also plays a role in the
cache’s performance and availability. OracleAS Web Cache is designed to work
with these dependencies.
The Oracle Application Server 10g Performance Guide provides extensive explanation on
tuning OracleAS Web Cache, system, network and origin server settings. Here is
just a sampling of some of the recommendations:
• Dual CPU: OracleAS Web Cache is a threaded application optimized for
dual CPU systems.
• Network speed: OracleAS Web Cache is generally network bound, not
CPU bound. Use the fastest network available and multiple NIC’s to
divide the traffic, if possible.

8 Simple Caching Rules – Web Caching Your Application for Fast Response Time Page 8

Keeping the system and architecture setup
in mind is important in effective use of
Web caching.
• Keep-Alive: HTTP Keep-Alive allows TCP connections to be re-used for
multiple requests. Keep-Alive should be enabled for both HTTP client to
OracleAS Web Cache and for OracleAS Web Cache to origin server
communication. OracleAS Web Cache uses connection pooling to its
origin server and re-uses the origin server connections whenever possible.
To enhance availability, cache capacity and performance, you can cluster OracleAS
Web Cache instances into a single logical cache for improved scalability, availability
and capacity of the cache tier. Clustering has automatic content provisioning,
partitioning the content space for increased cache capacity and replicating popular
content for performance and high availability. No specialized hardware is required,
although a fast network for intra-cache communication is desirable. Clustering
OracleAS Web Caches running on different operating systems is supported. For
example, a Web Cache running on Microsoft Windows can be clustered with one
running on GNU/Linux.
There are also management benefits to clustering OracleAS Web Cache. All caches
in the cluster can be managed, controlled and monitored from any node in the
cluster. Invalidation messages may also be sent to any node in the cluster. The
cluster automatically propagates the invalidation message to all members of the
cluster, keeping the entire cluster consistent.
RULE 8: USE WEB CACHE FOR SSL TERMINATION
OracleAS Web Cache offers SSL acceleration by offloading the SSL
encryption/decryption processing from the application server tier to the Web
caching tier. OracleAS Web Cache supports the following SSL related capabilities:
• Multi-site hosting: OracleAS Web Cache is capable of listening on multiple
ports, each of which can be configured to use a different SSL server
certificate
• SSL client certificate support: OracleAS Web Cache can be configured to
require SSL client certificates for one or more SSL-enabled listening ports.
OracleAS Web Cache forwards the client certificate information to its
origin server. The origin server can then provide this information to
applications for authentication purposes.
• SSL hardware accelerator support: OracleAS Web Cache can use SSL
processing hardware such as nCipher’s nFast SSL accelerator cards.
• SSL encryption to each tier: For high security environments requiring that
traffic between all tiers be encrypted, OracleAS Web Cache supports SSL
communication between it and its origin servers. Additionally, OracleAS
Web Cache’s operations ports, used for administration, monitoring, and
invalidation may also be configured to use SSL.
More information can be found in the “OracleAS Web Cache Security” chapter of
the Oracle Application Server Web Cache Administrator's Guide.
8 Simple Caching Rules – Web Caching Your Application for Fast Response Time Page 9
CONCLUSION
OracleAS Web Cache offers the industry’s most versatile and robust application
acceleration solution. Not only is it application aware, it also cooperates with
network systems to deliver any Web site in the shortest amount of time possible
with minimum downtime. From caching, partial-page caching to content
consistency, and from compression, SSL acceleration to system tuning, all of these
areas affect the overall effectiveness of OracleAS Web Cache. In eight simple rules,
this paper has outlined how to help Web caching your application for fast response
time!

8 Simple Caching Rules – Web Caching Your Application for Fast Response Time Page 10
8 Simple Caching Rules
December 2004
Author: Christine Chan, Patrick Fry
Contributing Authors:

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com

Copyright © 2003, Oracle. All rights reserved.

This document is provided for information purposes only
and the contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to
any other warranties or conditions, whether expressed orally
or implied in law, including implied warranties and conditions of
merchantability or fitness for a particular purpose. We specifically
disclaim any liability with respect to this document and no
contractual obligations are formed either directly or indirectly
by this document. This document may not be reproduced or
transmitted in any form or by any means, electronic or mechanical,
for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.