Oracle9iAS Web Cache Tuning Oracle Application Server Tips by Burleson Consulting

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.

Cacheability rules

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 10.13).

Figure 10.13: Oracle9iAS Web Cache main screen

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 screen

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 Architecture

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 requesting client.

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 each association:

• 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.