Oracle9iAS Web Cache Tuning
Oracle Application Server Tips by Burleson
The Oracle Web Cache is one of the most
important areas of Oracle9iAS tuning because of its important role
in reducing cross-layer traffic. Because the Web Cache can
keep HTML pages in RAM, the Oracle9iAS administrator can define
sophisticated rules to govern the amount of RAM storage, the
cacheability rules, and control Web Cache invalidations.
Oracle-sponsored studies have shown the a beefy Web Cache can reduce
load on the back-end database by as much as 95%, reducing repetitive
queries for common information. Most Oracle9iAS installation
use inexpensive hardware (Intel-based servers), and add more servers
as system load increases.
Oracle provides detailed instructions for
the configuration of the Web Cache parameters and components, but
the overall tuning is relatively simple, involving adding new Web
Cache servers, and adjusting the size of the data buffers,
cacheability rules and parameters for each Web Cache instance.
The Oracle9iAS Web cache allows you to
specify cacheability rules for both static and dynamic page content.
It also allows the Oracle9iAS administrator to specify multi-version
HTML, where the same page format is used, but with slightly
different text content. You can also specify personalization
rules whereby standard HTML pages are cached, but dynamically
modified to include custom messages, depending upon the user ID of
the invoking URL.
For web content that is segmented into
included components (e.g. header, footer, table of contents)
sections,, the Oracle9iAS Web Cache allows you to specify
cacheability rules for each page component. This is similar to
the MS-FrontPage concept of ?include pages?, whereby pages are
dynamically assembled at invocation by including separate HTML
files. This allows for highly dynamic content and the
effective re-user of components. For example, if you need to
change your web page header, you can change the HTML and the
Oracle9iAS Web Cache will invalidate the old copy, immediately
reloading it into the Web Cache and quickly including the new
content in all outgoing requests.
Monitoring the Web Cache
The main screen for the Oracle9iAS Web Cache
allows you to start and stop the Cache (often required for parameter
changes), and displays summary statistics on Web Cache usage (Figure
Figure 10.13: Oracle9iAS Web Cache main
From this screen you can click the
?activity? link under the performance heading and see detailed Web
Cache details (Figure 10.14).
Figure 10.14: Oracle9iAS Web Cache main
This screen gives us important information
about the effectiveness of the Web Cache.
Requests ? This shows the current,
average and max transaction per second, and this provides a great
high-level gauge of the throughput of the Web Cache. The
backlog section is especially important, as any value here usually
indicate that the Web Cache is overwhelmed with requests and
another Web Cache server should be started.
Errors ? This summarized the
network, site busy and particle-page errors for the Web Cache.
Many Oracle9iAS administrator write automated alerts to notify
them about excessive number of errors.
Misses ? This section shows
cacheable and noon-cacheable misses along with the number of
refreshes for the Web Cache. Remember, and incoming HTTP request
will be a ?hit? if the components exist in the Web Cache, a ?miss?
if the contents must be loaded from the database, and ?refreshed?
if the dynamic HTML content has changed.
Compression ? The compression
sections show the total amount of RAM saved by compression and
provides a great gauge of the effectiveness of the Web Cache.
The Oracle9iAS Web Cache allows you to
define the Web Cache to service multiple HTTP servers, providing
both load balancing and failover. Please see the later section
on Web Cache load balancing for complete details on load balancing.
The Web Cache tuning is generally performed by adding data buffers
to the cache and adjusting the Web cache parameters using the
Oracle9iAS OEM Web Cache manager.
Oracle OHS and Web Cache
The Oracle WebServer and OHS work together
to allow the Oracle9iAS administrator to implement Web-based
interactive applications that works closely with the Oracle
database. At first glance, the architecture of Web cache and
OHS may seem confusing. Since the Oracle OHS is a very
powerful product, there is a plethora of ways that Web Cache and OHS
can be configured and implemented.
The Web Cache resides in front of the OHS
server and is the first point of entry for incoming requests.
Each Web Cache can be made to automatically load-balance with up to
100 Oracle HTTP servers (Figure 10.15). The HTTP requests are
then passed to the Oracle HTTP servers, where OHS may access the
Oracle database back-end. On the outgoing side, the OHS server
communicates outgoing HTML to the Web Cache.
Figure 10.15: The Oracle9iAS Web Cache
At the top-level the OHS listener runs at
the web server level (sometimes on a separate server) and polls its
port for incoming HTTP requests. As each is received, the OHS
directs the request to through the layers, where Oracle9iAS extracts
the required information from the HTTP request, creates and executes
an Oracle database query, prepares an outgoing HTML or XML document,
and passed the result set back to OHS for transmission to the
At the top-end we see the Oracle9iAS Web
Cache and its? association with the Oracle HTTP Server (OHS).
The OHS components is generally configured first, and is assigned a
specific port. Next we configure the Web Cache and assign it
to a port and configure it to communicate with the OHS on port 81.
The Oracle9iAS Web Cache us used to speed
the delivery of static and dynamic web pages to users over the
internet. By employing RAM storage, the Web Cache is able to
keep important web page data instantly available. In the
real-world, the Web Cache stores images (gif?s and jpg?s) that are
embedded into the outgoing page immediately before transmission.
In a sense, the Web Cache is analogous to
the Oracle databases? data buffer cache because they both serve to
store frequently-referenced information. However, unlike the
data buffer cache, the Web Cache only stores information about its
current transactions. Hence it must be in constant
communication with OHS to create and destroy cached objects as
transactions are processes.
Also the Oracle9iAS Web Cache has built-in
compression technology to make the most effective use of RAM
storage, and includes Apache extensions that allow you to perform
load balancing between the OHS servers.
The Web Cache content is usually images
(gif, jpg) that are included inside the HTML content (via the IMG
tag). Initially, these images may be stored inside the Oracle
database using the BFILE OR BLOB datatypes, but once fetched from
Oracle they will remain cached for subsequent invocations.
This initial latency is why many Oracle9iAS users report that the
initial loads of their pages are far slower than subsequent
transactions. It is important to note that these cached images
are shared between instances of the OHS. In other words, once
an OHS has loaded the page header and footer images, they remain in
the cache where they can be used by transactions inside other OHS
instances. This sharing of the Web Cache is a very important
tuning area for the Oracle9iAS administrator.
The most important of these tasks is the
association between the Web Cache and the OHS. Of course, the
Oracle9iAS administrator may change these configurations based on
current processing needs. The association between Web Cache and OHS
instances can have a dramatic effect on your performance and you
should pay careful attention to the Web Cache monitoring statistics
and make appropriate adjustments. There are pros and cons to
Many OHS instances per Web Cache ?
This is the typical configuration for small and medium-sized
systems. The benefits of sharing a Web Cache is the sharing
of common items (e.g. page header jpegs), while the downside is
the lack of control over the RAM allocations for a specific OHS
and introducing a single point of failure. Small and medium sized
shops will run all of the Web Cache instances and the Web Cache on
a single server.
One Web Cache per OHS ? This
isolates the Web Cache to the specific OHS. The positive are
more granular management of the RAM cache, and the downside is the
non-sharing of Web Cache between OHS instances. Many large
Oracle9iAS sites give each OHS has its own Web Cache, both on a
separate server from the other OHS instances.
As we recall from Chapter 1, the Oracle9iAS
Web Cache performs automatic load balancing between the active OHS
servers. However, the Oracle9iAS administrator can keep a
?pool? of servers in standby mode with Web Cache and OHS installed
on them. Depending on need, you can add them into the
Oracle9iAS architecture as an OHS server or a Web cache server.
This is an excerpt from "Oracle
10g Application Server Administration Handbook" by Don Burleson
and John Garmany.