Oracle Application Server 10g Essentials [Electronic resources] نسخه متنی

7.1 OracleAS Web Cache

OracleAS Web Cache is the primary caching mechanism
provided with Oracle Application Server. An OracleAS Web Cache
instance sits in front of one or more
Oracle HTTP Servers, as
described in Chapter 2. The responses to all
requests directed to the Oracle HTTP Server through OracleAS Web
Cache can be cached in OracleAS Web Cache, which means that this
cache can handle any web content transmitted with the standard HTTP
protocol. Thus, OracleAS Web Cache works with Oracle Application
Server as well as with any other HTTP application server.

Web Cache can also act as a load balancer for multiple
instances of Oracle Application Server, and it provides some
high-availability features as well. By caching selected request
responses, OracleAS Web Cache reduces the load on the application
server. The load is reduced because cached content no longer needs to
be regenerated. CPU cycles and other resources are thus freed,
thereby improving performance for those items that
can't be cached.

OracleAS Web Cache was designed to work on low-cost machines. Because
OracleAS Web Cache works as an in-memory cache, its
capabilities are more dependent on addressable, available memory than
they are upon CPU speed or number of CPUs. OracleAS Web Cache was
designed to use two processors. Oracle's own My
Oracle site, for example, uses a pair of two-way Intel machines as
its own OracleAS Web Cache cluster.

7.1.1 Basic Principles

OracleAS Web Cache is a server
accelerator. OracleAS Web Cache instances act as a front end cache
for pages, content fragments, and other objects coming from one or
more application servers. OracleAS Web Cache can also be used with
third-party web servers, such as
BEA's WebLogic or IBM's WebSphere.

In the simplest case, a web server delivers static pages in response
to a client request. In this case, the server retrieves a page from
disk. For many sources of web content, however, the case
isn't nearly so simple. A page may be based on
dynamic content, changing either with time or because of the
characteristics of the user who has made a request. A page may even
be assembled from several sources of content, which can individually
be either static or dynamic.

A database uses a memory cache to hold frequently used data, allowing
for faster retrieval. OracleAS Web Cache does the same thing with web
pages and, more importantly, portions of web pages. This second
capability expands the scope of potential performance improvement.

Many web pages are customized: a simple page contains common elements
as well as portions specific to the user or the situation. For
instance, the home page for an application is largely the same for
all users, but may contain special greetings or messages for a
particular user. OracleAS Web Cache can assemble the page from
different fragments, providing the performance improvement of a
memory cache everywhere content is reused.

Several other components of Oracle Application Server may also use
OracleAS Web Cache to improve performance:

OracleAS Portal

OracleAS Portal comes with a set of predefined
caching and invalidation rules.

OracleAS Discoverer

OracleAS
Discoverer content can be cached by OracleAS Web Cache.

Oracle AS Wireless

OracleAS Wireless content can also be cached by OracleAS Web Cache.
Note, however, that OracleAS Web Cache is used by the OracleAS
Wireless server as a repository for content, rather than as a front
end, which is the role it plays for normal HTTP requests.

eBusiness Suite

Portions of Oracle's eBusiness Suite are also supported by
OracleAS Web Cache.

OracleAS Web Cache also supports a variety of
security configurations including
HTTPS communications between a browser and
itself and between itself and origin servers, as well as redirection
for an OracleAS Single Sign-On server. OracleAS Web Cache
can also communicate with client programs that use

client-side SSL certificates. In this
case, OracleAS Web Cache forwards the certificate information in
special HTTP request headers, which are then used by the Oracle HTTP
Server for authentication.

OracleAS Web Cache can provide scalability and high
availability in several different ways.

OracleAS Web Cache provides rapid response by being able to cache
both static and dynamic content, allowing pages to be returned
directly from OracleAS Web Cache without having to access the
originating application server. This rapid response allows the cache
to provide support for more users.

If a request comes in that can be satisfied directly from OracleAS
Web Cache, there is no need to go to the application server for the
content. In this scenario, OracleAS Web Cache provides availability
even though the application server may be unavailable.

If OracleAS Web Cache can't contact the required web
server (known as the origin
server in this context), the instance returns a
standard apology page. This page can be modified, but it can contain
only static HTML. If you want to include other elements, such as an
image or a company logo, you can designate another HTTP server to
serve up these images and embed the images in your apology page.

OracleAS Web Cache can load-balance for multiple application servers,
increasing the scalability of the overall site.

OracleAS Web Cache instances can be
clustered, with each cache instance
providing failover for other cache instances
as well as scalability for the entire OracleAS Web Cache.

The following subsections describe how OracleAS Web Cache handles
incoming requests and the various topologies that can be used for
OracleAS Web Cache and their implications. We also cover the basics
of how OracleAS Web Cache moves content out of the cache with
invalidation; how OracleAS Web Cache handles static, dynamic, and
partial pages; administration of OracleAS Web Cache instances; and
other features of the product.

7.1.2 How It Works

OracleAS Web
Cache sits in front of a web server, as shown in Figure 7-1. The web server here is referred to as an
origin server. The web server could also be a proxy server used to
access content outside the firewall.

Figure 7-1. OracleAS Web Cache fulfilling user requests

When a request comes into an OracleAS Web Cache instance, it
determines whether the request is for a site that uses the instance.
That information is provided by the Host request-field header from
the request, the host portion of the URL, or the
src attribute of the ESI include tag, which is
explained later in this chapter.

ESI stands for Edge Side Includes, an open standard specification for defining web-page components for dynamic page assembly. More information on ESI is available at http://www.esi.org.

If the request is for a document from a site that uses the instance,
OracleAS Web Cache checks to see if the document is in the cache. If
OracleAS Web Cache can satisfy the request, it returns the page to
the user. If it can't satisfy the request, it
requests the object from the application server after appending a
Surrogate-Control
response-header field to the document. The application server returns
the object to OracleAS Web Cache.

If the object is specified as cacheable, by either a caching rule or
an attribute in the returned Surrogate-Control response-header, the
object is cached for future use. For pages that are constructed of
page fragments, using ESI (as described later), OracleAS Web Cache
follows the same procedure for each fragment.

Once the document is available, OracleAS Web Cache returns it to the
user. If the newly retrieved object is marked as being cacheable, the
object is placed in OracleAS Web Cache's cache.

The flow of logic for OracleAS Web Cache requests is shown in Figure 7-2.

Figure 7-2. Logic flow of requests to OracleAS Web Cache

Objects remain in the cache until they are either removed (because of
demand for cache resources) or marked invalid, as described later. If
the total size used by OracleAS Web Cache exceeds a configurable
percentage of the overall memory available for the instance, OracleAS
Web Cache will initiate a garbage-collection routine that will select
content to be removed. You might want to set the maximum size for any
single cached object to avoid using up too much cache memory too
quickly.

OracleAS Web Cache lets you set a maximum size for any cached object.
Any object that exceeds the specified size isn't
cached, regardless of how it is marked or how caching rules apply to
it.

7.1.3 Topologies for OracleAS Web Cache

Earlier, Figure 7-1 showed a simple configuration for an
OracleAS Web Cache instance, with a single OracleAS Web Cache
instance supporting a group of sites. OracleAS Web Cache can be on
the same machine with multiple instances of an application server. In
this configuration, OracleAS Web Cache uses
interprocess communication (IPC) to
assign requests to application server instances.

If, instead, OracleAS Web Cache is on a different machine, it uses
HTTP to communicate with the origin server. In this configuration, a
single OracleAS Web Cache instance can communicate with multiple
origin servers.
OracleAS Web Cache uses a connection pool for each origin server for
faster communication with the server.

OracleAS Web Cache can work in several other topologies to provide
additional features and benefits. Although OracleAS Web Cache is
primarily used for caching content, you can also use it as a load
balancer that supports application server failover. Three common
OracleAS Web Cache
deployment topologies
include:

Use of OracleAS Web Cache to support load balancing and failover for
multiple origin servers

Use of multiple instances of OracleAS Web Cache for load balancing
and failover for OracleAS Web Cache itself

Use of multiple instances of OracleAS Web Cache in a cluster

Another set of topologies, known as
hierarchies,
is used for specific needs, such as geographic distribution of
caching.

7.1.3.1 OracleAS Web Cache and multiple origin servers

The ability to support multiple
application servers is built into OracleAS Web
Cache's architecture. This capability allows
OracleAS Web Cache to load-balance requests across multiple
application servers and to provide automatic failover when an
application server instance fails.

Sometimes, a web site is supported by more than one application
server. In this situation, a single OracleAS Web Cache instance can
manage requests for pages from as many as 100 application servers,
and load-balance among them.

OracleAS Web Cache automatically sends requests to the origin server
with the most available resources. The quantity of available
resources for a particular origin server is determined by the
workload and capacity for the server. The workload is based on the
number of active connections to the origin server. An OracleAS Web
Cache administrator establishes the maximum number of connections for
each origin server. The available resources are determined by
subtracting the workload from the capacity. If all origin servers
have an equal capacity, OracleAS Web Cache uses a Round-Robin method
to assign new connections.

If a connection request or a configurable number of read/write
requests to an origin server fails, OracleAS Web Cache considers the
server unavailable. For an unavailable server, existing requests for
documents return errors, but subsequent requests to the server are
failed-over to another origin server. The capacity of the failed
server is assigned to the failover server. Once the failed server
responds to a request to a designated URL on the server, the server
is considered available, and capacity for the server is reassigned to
it.

The operations we've described so far make sense for
stateless requests; one origin server is as good as any other. But
what about stateful requests that depend upon earlier interactions
with the failed origin server? Stateful transactions require
server affinity

to emulate persistent connections to a server, such as for use with a
shopping cart.

You can configure OracleAS Web Cache to perform stateful
load
balancing using session
binding. Session binding requires that the
origin server use cookies and session IDs to indicate server affinity
for a particular request. This is done automatically by Oracle
Application Server. Server affinity ensures that a stateful request
will consistently return to the server that is maintaining its state.

If a request requires a connection to a particular origin server, but that server is already handling maximum capacity, the session binding for that request is disabled, and an error message is returned to the user.

7.1.3.2 Multiple instances of OracleAS Web Cache

Multiple instances of OracleAS Web
Cache can be used together, either in a cluster or in a failover
configuration. In both configurations, you can use a
hardware load balancer in front of
OracleAS Web Cache instances, as shown in Figure 7-3. In addition, in both configurations, the load
balancer recognizes a single logical OracleAS Web Cache and balances
requests across the instances.

Figure 7-3. Multiple instances of OracleAS Web Cache

OracleAS Web Cache can be configured to automatically restart an
instance if a failure has been detected. If you have installed
OracleAS Web Cache as part of a complete Oracle Application Server
installation, the Oracle Process Manager and Notification Server
monitors the health of an OracleAS Web Cache instance and performs
the restart when necessary. If you have installed OracleAS Web Cache
as a standalone product, a watchdog process restarts the instance.
This process can be disabled if desired.

You can configure a hardware load balancer to send only HTTP or HTTPS
requests to an instance of OracleAS Web Cache. For example, you might
designate an OracleAS Web Cache instance to receive only HTTPS
requests if you are going to use some type of SSL accelerator
hardware only on that machine.

You can use an L7 switch to route requests to OracleAS Web Cache or
an origin server via the Application Layer (Layer 7) of the OSI
model. This configuration might make sense if there are certain types
of content that you don't want to cachefor
example, protected or transactional contentso you would want
to completely bypass the OracleAS Web Cache servers.

7.1.3.3 Clustering

Multiple instances of OracleAS Web Cache can also be combined into a
cache cluster

. A cache
cluster uses the same basic hardware configuration used for
unclustered, multiple instances of OracleAS Web Cache, but it offers
some additional functionality as well.

A cache cluster is a group of cache instances that look like a single
cache. A cache cluster still requires the use of a hardware or
software load balancer, as described earlier. All the instances in
the cluster use the same common configuration information, such as
site definitions and caching rules, and receive the same invalidation
messages.

In a cluster configuration, OracleAS Web Cache instances can
periodically ping each other to determine whether they are still
alive, or can wait for either a connection request failure or a
designated number of read and write request failures to demonstrate
that an instance is no longer alive.

You can dynamically add OracleAS Web Cache instances to an
established cache cluster, although you do have to restart the
cluster for the new member to be included. Each member of the cluster
is assigned a relative capacity, and document ownership is
distributed among the instances based on their relative capacity.

Requests are handled as follows for a cache cluster:

If a request comes into a cache instance for a document it owns, it
works just like a single cache instance.

If a request comes into a cache instance for a document that is owned
by another instance, the cache instance passes the request off to the
owning instance.

If a cache instance doesn't respond to a request for
a document in a specified length of time, the requesting instance
assumes that the other instance has failed. When this occurs, the
documents owned by the failed instance are redistributed to the
remaining instances according to their designated capacity.

In the last case, the other instances of the OracleAS Web Cache
cluster periodically ping a specified URL for the failed server so
that they will recognize when the instance rejoins the cluster. When
an instance rejoins the cluster, document ownership is again
redistributed according to the new relative capacities of the
available instances. Keep in mind that while document ownership is
redistributed, document content isn't. The new
instance will retrieve a document that it now owns once the document
is requested.

Although each document is owned by a single cache instance, the
content may be needed by other instances. Once the content is
requested and returned to another instance, the requesting server
caches the content itself, so future requests to that server
won't require a redirection. In this way, the same
popular content may be contained in multiple cache instances.

The upshot of this design is that the most popular objects in an
OracleAS Web Cache cluster are most resilient to the failure of an
individual OracleAS Web Cache instance because popular objects
typically reside in more than one instance and don't
have to be refreshed if one instance fails.

Some operating systemsfor example, some flavors of Windows
2000 and Windows 2003include the ability to load-balance
requests across nodes in an operating system-defined cluster. In such
a configuration, the operating system also recognizes node failure
and uses automatic IP takeover in the event of a failure.

A cache cluster offers a number of benefits not provided by
unclustered, multiple instances of OracleAS Web Cache, including:

Increased scalability

Multiple instances of OracleAS Web Cache can be combined for greater
caching capability, but without increasing the number of content
requests to the origin server.

Improved maintenance

Maintenance is easier because all members of a cache cluster share
the same configuration, and one member typically receives a single
invalidation message. In addition, you can add members to, or remove
members from, a cache cluster without having to worry how it will
affect management overhead.

7.1.3.4 Hierarchies

You can use hierarchies
of OracleAS Web Cache in two basic
configurations:

Remote Cache Deployment

One configuration of OracleAS Web Cache implements enterprise content
delivery networks with Remote Cache Deployment. In this
configuration, OracleAS Web Cache can provide better response time by
caching frequently used content closer to the eventual user of the
data, such as in a remote location or LAN segment, as shown in Figure 7-4.

Figure 7-4. Using OracleAS Web Cache as Remote Cache Deployment

Edge Side Includes

A second type of hierarchy uses instances of OracleAS Web Cache on
ESI
providers (described later) and an instance of OracleAS Web Cache on
a subscriber machine, which assembles the ESI fragments into a web
page. This type of hierarchy is especially appropriate for an
OracleAS Portal deployment, in which complete pages are assembled
from different sources. OracleAS Portal is described in detail in
Chapter 13.

When you configure a cache hierarchy, the origin servers for the
upstream caches, such as the ESI subscriber machine, are the
downstream instances of OracleAS Web Cache. If you
can't specify a site definition for an ESI provider
machine, and there is a firewall between the subscriber instance and
the unknown ESI provider, you must configure a proxy server because
OracleAS Web Cache uses DNS to locate undefined ESI
providers.

7.1.4 Types of Caching

Three different types of information can be
cached in OracleAS Web Cache: static HTML pages, dynamic HTML pages,
and page fragments.

7.1.4.1 Static page caching

For static pages, the use of OracleAS Web
Cache is straightforward. If a document is cacheable, it is placed in
the cache until it becomes invalid, either through receipt of an
invalidation message or after a request for the document comes in and
the caching rules indicate that it has expired.

Static pages are swapped out of OracleAS Web Cache if the cache
becomes full, and the garbage-collection process selects the page as
a candidate for removal, as described earlier.

7.1.4.2 Dynamic page caching

Dynamic pages are pages that can have different
content for different situations or different users. These pages can
be generated using a variety of scripting and programming languages
and modules. Examples include JSPs, Active Server Pages (ASPs),

PL/SQL Server Pages (PSPs), Java
servlets, and CGI calls.

Sometimes these dynamic pages are completely unique. In these cases,
OracleAS Web Cache would have to potentially cache each individual
page. Frequently, though, pages are very similar, with only some
different areas. In some scenarios, described in the following
subsections, OracleAS Web Cache can substitute dynamic values or to
recognize when a page can be reused for multiple users.

In other scenarios, developers can combine some static objects with
dynamic objects by caching portions of an overall page.

7.1.4.2.1 Multiple versions for a single URL

Some web sites create different versions of the
same page for different sets of users. These sites
either use a cookie
with an identifying value or encode the value in the
URL.

If a cookie is used, the value for the cookie is passed back from the
origin server in the Set-Cookie response header, which is stored with
the document. When a subsequent request comes in with a value in the
corresponding Cookie request header, OracleAS Web Cache returns the
appropriate page. OracleAS Web Cache can also use values in
request-header fields to determine which version of a page to return.

If appropriate, you can configure OracleAS Web Cache to ignore embedded URL parameters when determining which page to return. This approach avoids the requirement to cache every version of a web page with distinct URL embedded information, such as a session ID. You can also configure OracleAS Web Cache to ignore POST body parameters, as discussed in the next section.

You can use multiversion caching to support
different cached pages for different types or groups of browsers.
This technique allows you to build in flexible pages for different
browsers while still taking advantage of OracleAS Web Cache.

7.1.4.2.2 Personalization in a page

You can specify
personalization information in a
web page with special OracleAS Web Cache HTML tags. When OracleAS Web
Cache receives a request for the page, the specified information is
retrieved from a cookie, from a URL embedded parameter, or from POST
body parameters.

When you specify the attribute that will be used for personalization,
you can also specify whether to return the page for requests that are
missing the attribute, or what to use in place of the attribute for
pages missing a value.

7.1.4.2.3 Session-encoded URLs

Some web pages use

session-specific information in internal
hyperlinks. You can also configure OracleAS Web Cache to substitute
session values in hyperlinks that use session-encoded URLs. As with
personalization attributes, you can specify how OracleAS Web Cache
should handle a request with missing session information.

7.1.4.3 Partial page caching

As

mentioned earlier, some pages combine
static objects, such as a page
template and logos, with dynamic objects. These pages use
ESI tags to indicate where the
dynamic objects are located on the page and where to get their
content.

ESI tags were originally introduced by Oracle and Akamai, and are on the standards track for the World Wide Web Consortium (W3C).

OracleAS Web Cache can work with both include fragments, which are always
fetched, and inline fragments, which are identified with a
unique name and can be reused by multiple pages without refetching.

OracleAS Web Cache can cache page fragments independently, with each
fragment having its own validation rules. This method allows OracleAS
Web Cache to cache individual fragments, which can be used in many
different pages. Each fragment has its own set of validation rules;
these rules can use the same information and logic as a rule for an
entire page. This separation means that an individual fragment
doesn't have to be re-fetched every time a page
requiring the fragment is requested.

For instance, you can have the template and logos for a page cached
indefinitely, the news for the day cached for several hours, and
stock prices not cached at all. By separating all these fragments
into separate ESI fragments, OracleAS Web Cache can intelligently
refresh the fragments as appropriate. ESI tags can use XML
stylesheets to transform content into HTML.

When you configure the origin servers that OracleAS Web Cache will
access, you can specify that the site is an ESI provider only, which prevents
browsers from accessing the site directly. You don't
have to configure all sites that are ESI providers. However, failing
to configure an ESI provider site disables OracleAS Web
Cache's capacity heuristics capability, as we
discuss in the next section. If there is a firewall between an ESI
provider and a OracleAS Web Cache subscriber cache, as described in
Section 7.1.3.4,
you must configure a proxy server to contact the ESI provider.

For ESI use in JSPs, a
set of Java ESI tags, known as JESI
tags, can implement ESI fragments more productively. JESI
tags will automatically create the surrogate control headers that are
used by ESI fragments to determine caching characteristics. By using
JESI tags with JSPs, you can use JSP expressions for more flexible
implementation of caching rules.

7.1.5 Cache Invalidation

Caching is, of course, nothing new in
the world of computing. Databases have long used caches to improve
performance. In a database cache, the database uses the concept of
least-recently-used (LRU) to swap out blocks of data when the cache
becomes full.

In Oracle Application Server, OracleAS Web Cache performs the same
type of operation when it becomes full, but there are also other
options for removing content from an OracleAS Web Cache instance.
Some content stored in OracleAS Web Cache changes frequently, while
some rarely changes at all. To handle this breadth of
"freshness," OracleAS Web Cache
lets you specify when content becomes invalid, which marks it as
ready to be discarded from the cache.

Validation is the
process of verifying whether an object in OracleAS Web Cache is still
valid.
Invalidation is the process used to flag an
object as no longer being available. Invalidating an object
doesn't necessarily remove it from the cache. Once
an object is put into OracleAS Web Cache, it remains valid until it
is marked as invalid.

There are basically two types of invalidation:

Predictable

This type of invalidation can be
indicated with an expiration time, either in elapsed time or at a
specific time.

Unpredictable

This type of invalidation occurs in
response to some other event. Unpredictable invalidation can be
implemented with a message, as described later.

There are two ways to indicate that an object is invalid:

Policies

These are evaluated each time a request is made for an
object.

Messages

These are sent to OracleAS Web Cache, either manually or
programmatically.

If an object in OracleAS Web Cache is marked as invalid, the next
request for the object causes OracleAS Web Cache to fetch a fresh
version of the object from the origin server.

Just as you assign validation rules to objects and groups of objects, you can mark objects as noncacheable, which means that they are never placed in OracleAS Web Cache.

These techniques are used for the OracleAS Web Cache instance itself
to invalidate content. OracleAS Web Cache can use

HTTP
validators, included in the browser request, to
ensure that delivery of cached documents is appropriate. OracleAS Web
Cache compares the If-Modified-Since value with the value in the
Last-Modified response-header field of the cached document, or
compares the If-None-Match validator with the ETag response-header
field of the cached document.

OracleAS Web Cache has its own set of caching rules (described
later), but it can also accept caching directives, either in the
Surrogate-Control response-header field in the object returned from
the origin server, or in the HTTP Cache-Control header. If there is a
rule in more than one of these areas, the Surrogate-Control rule
overrides OracleAS Web Cache rules, which override the HTTP
Cache-Control header. If a Surrogate-Control response-header rule is
used, additional properties in the OracleAS Web Cache rule, such as
compression, can be merged with the rule.

If you are using a hierarchy of caches, the top cache instance in the
hierarchy receives the invalidation message and then propagates it to
the other downstream caches. If you are using cache instances in a
cluster, you can choose either to have a cluster member act as an
invalidation coordinator (which propagates invalidation messages) or
to send invalidation messages to all members of the cluster.

Invalid objects are removed from OracleAS Web Cache by a
garbage-collection process. This process
runs when the OracleAS Web Cache instance runs out of space. The
garbage-collection process uses a heuristic algorithm to determine
which objects to remove, which takes into consideration the
popularity of an object (how long it has been since the object was
requested), whether an object is invalid, and other considerations.
An object is marked as invalid, based on rules and messages, but it
isn't discarded from the cache until a
garbage-collection process is initiated by the load on the OracleAS
Web Cache instance.

7.1.5.1 Cacheability/invalidation rules

You describe
the objects that an OracleAS
Web Cache instance should cache by
specifying caching rules. A caching rule contains four properties:

Selector

Specifies the pages to which a rule applies. The
selector contains a URL expression, which
could be based on a URL prefix, a file extension type, or a regular
expression (for more extensive logical selection). It can also be
based on a URL or POST body parameter, or on a POST body expression.

Caching policy

Indicates
whether the selected URL should be
cached. You can also indicate whether the URL has an expiration
policy or whether it should be compressed. An expiration policy uses
a time-based indicator, which can work on the amount of time an
object is in the cache, on the amount of time since an object was
last requested, or on information in the HTTP Expires or
Cache-Control response fields.

Cache key policy

Defines what information OracleAS Web Cache uses
to create a unique ID for an object. This ID is used to retrieve the
object from the cache for subsequent requests. This information can
include the site name, the URL of the object, the POST body
expressions, the cookie names and values, and the HTTP request header
name and values.

Priority

Defines the order of use of the caching rules. If
some objects aren't cacheable, this property
specifies their rules first to avoid excess overhead.

OracleAS Web Cache comes with some default caching rules, such as one
used with OracleAS Wireless. If you don't specify
any caching rules, content isn't cached. Even if
content isn't cached, OracleAS Web Cache can still
be used as a load balancer to multiple origin servers.

7.1.5.2 Invalidation messages

To invalidate
an object by a message, an
OracleAS Web Cache instance must receive an HTTP POST message from
one of two accountsthe administrator account or the
invalidator account. Both accounts are set up at installation time
and can be modified with Web Cache Manager. These messages must be
received on the invalidation listening port, which is also configured
at runtime.

The message contains information presented in
XML that identifies the page to
be invalidated. There are two types of XML descriptions:

Basic

Lists the identifying URL

Advanced

Uses pattern and range matching to identify a number of different
pages

Invalidation messages can be sent in a variety of ways, including:

Via Telnet

From OracleAS Web Cache Manager

Via application logic

From database triggers using Oracle's UTL_TCP
built-in package

With scripting languages

OracleAS Web Cache ships with an API for invalidation messages for
Java and PL/SQL. An invalidation message sent by OracleAS Web Cache
Manager can include a removal time, which must be later than the
invalidation time. This time is used for performance assurance
heuristics, discussed in the next section.

If you use ESIs, you can invalidate fragments,
based on the retrieval of another inline fragment. For instance, if
one inline fragment is invalid, you may want to indicate that the
other fragments associated with the document are also invalid.

OracleAS Web Cache sends an HTTP response for all invalidation
requests. This response contains a status code indicating the outcome
of the request. The application that sent the request can use this
information in its own logic.

7.1.5.3 Performance assurance heuristics

Objects in OracleAS Web Cache


can be marked as invalid, as
explained earlier, but a large number of objects can become invalid
at any one time. For example, a bulk application of changes to
material used in an online catalog may invalidate all the pages in
the catalog. How does OracleAS Web Cache avoid impacting performance
when it saturates the origin server with requests for new versions?

The answer is that OracleAS Web Cache uses something called
performance assurance
heuristics
. These heuristics are used to create a
queue for refresh requests. If the
capacity of the origin application server is exceeded, OracleAS Web
Cache uses this queue to keep the number of requests to a more
reasonable level. Requests are prioritized in the queue based on two
factors:

Levels of invalidation defined for the object

Popularity of the object

The concept of levels of invalidation is based on the
concept of removal
time. You can specify a removal time for an
object, which indicates how long an invalid object can stay in the
cache before it is removed. The greater the time since an object has
been invalidated, the staler it is. There may be multiple levels of
staleness.

For example, a web page may contain the following:

A logo, which is static

A news feed, which should be updated on a regular basis

An account balance, which must always be up to date

If OracleAS Web Cache determines that refresh requests are
overwhelming the origin server, it can assemble the page with a stale
version of the news feed item, but not the account balance. The only
real consequence of this decision for the user is that it provides
slightly older news content, while providing better performance for
all users.

If objects are equally stale, OracleAS Web Cache uses
popularity ratings
to remove the least-requested object. In this way, OracleAS Web Cache
can smooth out the performance it delivers, regardless of the number
of objects that are invalid at any one time. In addition, you can use
this feature to help address issues associated with surges of
traffic. By designating some content as acceptable for stale
delivery, you allow OracleAS Web Cache to automatically throttle back
its requests as demand grows.

7.1.6 Compression

OracleAS
Web
Cache uses the standard GZIP compression algorithm to reduce
the size of pages returned to the browser (assuming
that the requesting browser supports this type of compression). On
average, OracleAS Web Cache compression can reduce the size of
compressed documents by 75%. A compressed document may contain both
cached and noncached elements, or may be a complete page that has not
been cached. OracleAS Web Cache itself stores content in a compressed
format to save caching space.

If the HTTP header for a request indicates that a
browser can expand
compressed content, OracleAS Web Cache compresses the content before
returning it, reducing bandwidth requirements and potentially
improving response time. Most browsers have supported the GZIP
algorithm since 1997. However, OracleAS Web Cache caches both
compressed and uncompressed version of objects, and returns whichever
is appropriate.

You indicate whether you want content to be compressed by supplying
the appropriate information in the cacheability
rules you specify
to select the content. Because these rules allow the use of regular
expressions for evaluating cacheability, you can use the same
flexible expressions to determine whether content is to be
compressed. If the origin server has already compressed content,
OracleAS Web Cache recognizes this in the response header and does no
further compression.

If you are using a hierarchy of caches, you should
configure the OracleAS Web Cache closest to the origin server to
compress content, and configure the downstream OracleAS Web Cache
instances so that they don't compress. This approach
delivers the compressed content early on in the flow of the response,
and consequently, the transmission benefits over the greatest
distance.

7.1.7 Administration

There
are three ways to start an OracleAS

Web Cache instance:

Through the command line, using the OPMN Server

Through OracleAS Web Cache Manager

Through Application Server Control

Of the three,
OracleAS Web Cache Manager (shown in
Figure 7-5) is the tool most often used to manage
OracleAS Web Cache instances. This tool is the interface to the
management process for OracleAS Web Cache, which in turn must be
running to use the Manager.

Figure 7-5. Sample OracleAS Web Cache Manager page

You can use OracleAS Web Cache Manager to start and stop OracleAS Web
Cache instances, administer invalidation or rollover log files,
monitor performance and activity, and configure OracleAS Web Cache
instances. You can also use the OracleAS Web Cache Manager to
associate specific caching rules with URLs or sets of URLs. In
addition, you can create and view caching rules with this tool, as
well as edit some of the attributes of the rules, such as expiration
policies, compression, and the content of HTTP request headers.

Most changes specified through OracleAS Web Cache Manager
aren't applied until an OracleAS Web Cache instance
is restarted. However, some of the changes do take effect as soon as
the changes are saved. Such changes include setting levels of detail
for the event logs, changing the buffering for event logs and access
logs, enabling and disabling the inclusion of diagnostic information
in the HTML response body, and setting routing to origin servers.

OracleAS Web Cache Manager tracks whether other members of a cache
cluster have a different configuration and allows you to bring those
members' configuration into conformance. Once you
have matched the configurations, you can restart all instances of a
cluster with a single button push. You can also choose to stagger the
restart of the instance to reduce the impact on operations.

7.1.7.1 Monitoring OracleAS Web Cache

OracleAS
Web
Cache Manager can display a list
of the most popular documents, based on the number of requests and
the most recently received requests. This list can be limited to
either cached documents or noncached documents. You can also get a
listing of all documents in the cache at the present time, but this
list is saved to a file.

To highlight potential performance improvements, OracleAS Web Cache
Manager can give you a list of the most popular documents that return
cache misses, which provides the information you need to adjust
caching rules to reduce the number of misses.

OracleAS Web Cache uses an event log to record events and errors.
Events include cache hits, cache misses, and invalidations. Events
can be recorded with details of the request that triggered the
events, such as the IP address of the browser that made the request
and details about the site and URL of the request.

Event log files are periodically rolled over, with the old log file
stored. Rollover intervals can be configured to once a week, once a
day, hourly, or never. Starting with Oracle Application Server
10g, you can set the level of detail in the
OracleAS Web Cache log.

OracleAS Web Cache Manager displays information about the overall
health and operations of an OracleAS Web Cache instance. The
information includes health and utilization statistics for the
instance, error and invalidation statistics, requests for each origin
server supported by the instance, and information about fresh and
stale documents that have been served from the cache.

For troubleshooting purposes, OracleAS Web Cache includes diagnostic
information in the HTTP Server response-header fields by default. If
you choose to do so, you can have this information added to the
response body.

7.1.7.2 OracleAS Web Cache and performance monitoring

In

addition to the event log mentioned
in the previous section, OracleAS Web Cache also keeps an access log,
which tracks information about HTTP requests sent to it. OracleAS Web
Cache can be configured to use its access log to determine user
response times for HTTP requests because the access log includes
information about the elapsed time from a request to its response.

The access log can be analyzed through OracleAS Web Cache Manager and
can be output into either an HTML file or a comma-separated file for
import into a spreadsheet or database. The access log can also be
used more fully by Oracle Enterprise Manager
10g's Application Service Level
Management feature, which ships with Grid Control, a web-based tool
described in Chapter 3. ASLM helps
administrators to understand the actual performance their end users
are receiving by tracking the time it takes for a response to an
end-user request to be returned to the user. The OracleAS Web Cache
access logs are used to track timefrom the time a request
comes into OracleAS Web Cache until the time the response is returned
to the user. ASLM can't be used without these access
logs, so OracleAS Web Cache contributes substantially to the overall
management capabilities of Oracle Enterprise Manager 10g.