Skip Headers

Oracle9iAS Web Cache Administration and Deployment Guide
Release 2 (9.0.2)

Part Number A95404-02
Go To Documentation Library
Go To Product List
Solution Area
Go To Table Of Contents
Go To Index

Go to previous page Go to next page

Introduction to Oracle9iAS Web Cache

This chapter describes the performance barriers faced by Web sites and introduces the technology that can provide a complete caching solution.

This chapter contains these topics:

What is the Big Picture for Caching?

The electronic business model creates new performance requirements for Web sites. To carry out e-business successfully, Web sites must protect against poor response time and system outages caused by peak loads. Slow performance translates into lost revenue.

Many high-volume Web sites try to counter this problem by adding more application Web servers to their existing architecture. As more users access these Web sites, more and more application Web servers will have to be added. In short, the manageability costs associated with adding application Web servers often outweigh the benefits.

Static caches and content distribution services can provide some relief. However, these solutions are unable to serve content that is dynamically generated.

Oracle's Solution to Web Site Performance Issues

Faced with these performance challenges, e-businesses need to invest in more cost-effective technologies and services to improve the performance of their sites. Oracle offers Oracle9iAS Web Cache to help e-businesses manage Web site performance issues. Oracle9iAS Web Cache is a content-aware server accelerator, or reverse proxy server, that improves the performance, scalability, and availability of Web sites that run on Oracle9i Application Server (Oracle9iAS) and Oracle9i.

By storing frequently accessed URLs in memory, Oracle9iAS Web Cache eliminates the need to repeatedly process requests for those URLs on the application Web server. Unlike legacy proxies that handle only static documents, Oracle9iAS Web Cache caches both static and dynamically generated content from one or more application Web servers. Because Oracle9iAS Web Cache is able to cache more content than legacy proxies, it provides optimal performance by greatly reducing the load on application Web servers.

Figure 1-1 shows the basic architecture. Oracle9iAS Web Cache sits in front of application Web servers, caching their content, and providing that content to Web browsers that request it. When Web browsers access the Web site, they send HTTP protocol or HTTPS protocol requests to Oracle9iAS Web Cache. Oracle9iAS Web Cache, in turn, acts as a virtual server to the application Web servers. If the requested content has changed, Oracle9iAS Web Cache retrieves the new content from the application Web servers. The application Web servers may retrieve their content from an Oracle database.

Figure 1-1 Oracle9iAS Web Cache Architecture

Text description of owcag022.gif follows
Text description of the illustration owcag022.gif


Oracle9iAS Web Cache is compatible with Oracle HTTP Server or any other HTTP-compliant application Web server.

How Web Caching Works

To Web browsers, Oracle9iAS Web Cache acts as the virtual server for application Web servers. You configure a Load Balancer with the same IP address that is registered for a site's domain name and the application Web servers' host names. This Load Balancer receives requests for Oracle9iAS Web Cache. This configuration enables Web browsers to communicate with Oracle9iAS Web Cache rather than application Web servers when accessing a Web site.

Figure 1-2 shows how Web caching works. Oracle9iAS Web Cache has an IP address of and the application Web server has an IP address of The steps for browser interaction with Oracle9iAS Web Cache follow:

  1. A browser sends a request to a Web site named

    This request in turn generates a request to Domain Name System (DNS) for the IP address of the Web site.

  2. DNS returns the IP address of the Load Balancer for the site, that is,

  3. The browser sends the request for a Web page to the Load Balancer. In turn, the Load Balancer sends the request to Oracle9iAS Web Cache server

  4. If the requested content is in its cache, then Oracle9iAS Web Cache sends the content directly to the browser. This is called a cache hit.


    Dynamic content is generated by the application Web server and then returned to Oracle9iAS Web Cache before being passed to the browser.

  5. If Oracle9iAS Web Cache does not have the requested content or the content is stale or invalid, it hands the request off to application Web server This is called a cache miss.

  6. The application Web server sends the content to Oracle9iAS Web Cache.

  7. Oracle9iAS Web Cache sends the content to the client and makes a copy of the page in cache.


    A page stored in the cache is removed when it becomes invalid or outdated, as described in "Cache Freshness and Performance Assurance".

Figure 1-2 Web Server Acceleration

Text description of owcag002.gif follows
Text description of the illustration owcag002.gif

Benefits of Web Caching

Web caching provides the following benefits for Web sites:

Features of Oracle9iAS Web Cache

The main features of Oracle9iAS Web Cache make it a perfect caching service for e-business Web sites that host online catalogs, news services, and portals. These features include:

Static and Dynamically Generated Content Caching

Caching rules determine which documents Oracle9iAS Web Cache caches. Rules fall into three categories:

Cache Invalidation

Oracle9iAS Web Cache supports invalidation as a mechanism to keep the cache consistent with the content on the application Web servers, origin databases, or other dynamically generated means.

Administrators can invalidate cache content in one of two ways:

Performance Assurance

When a large number of documents have been invalidated, the retrieval of a new documents can result in overburdened application Web servers.

To handle performance issues while maintaining cache consistency, Oracle9iAS Web Cache uses built-in performance assurance heuristics that enable it to assign a queue order to documents. These heuristics determine which documents can be served stale and which documents must be refreshed immediately. Documents with a higher priority are refreshed first. Documents with a lower priority are refreshed at a later time.

The queue order of documents is based on the popularity of documents and the validity of documents assigned during invalidation. If the current load and capacity of the application Web server is not exceeded, then the most popular and least valid documents are refreshed first.

See Also:

"Cache Freshness and Performance Assurance" for further information about performance assurance

Site Support

Oracle9iAS Web Cache caches and assembles dynamic content for one or more Web sites. From the perspective of Oracle9iAS Web Cache, a site can be either a virtual host site or an ESI provider site. Depending on the site category, you can configure Oracle9iAS Web Cache to perform different functions.

This section covers the following topics:

Virtual Host Sites

Virtual host sites are sites hosted by Oracle9iAS Web Cache. In other words, browsers can request cached content from these sites through Oracle9iAS Web Cache. Figure 1-3 shows Oracle9iAS Web Cache caching content for two sites, and An additional mapping of www.* uses *, enabling additional virtual sites that map to host4 and host5 to be added. In addition to caching content, Oracle9iAS Web Cache can also assemble ESI fragments from these sites.

Figure 1-3 Multiple Virtual Host Sites

Text description of owcag037.gif follows
Text description of the illustration owcag037.gif

ESI Provider Sites

ESI provider sites are those sites that Oracle9iAS Web Cache contacts for ESI assembly only. Browsers are not allowed to request content from these sites.

Figure 1-4 shows an ESI provider site configuration. In this configuration, Oracle9iAS Web Cache receives a request for a page with ESI markup tags. Oracle9iAS Web Cache sends the request to the application Web server. The application Web server uses a portal application to create a template page and sends it back to Oracle9iAS Web Cache for assembly. Oracle9iAS Web Cache includes the ESI fragments for the template page directly from the site and another Oracle9iAS Web Cache server, which is caching content for the site.

See Also:

"Content Assembly and Partial Page Caching" for further information about ESI

Figure 1-4 Multiple ESI Provider Sites

Text description of owcag051.gif follows
Text description of the illustration owcag051.gif

Site Definitions and Site-to-Server Mappings

In order for Oracle9iAS Web Cache to recognize a virtual host site or an ESI provider site, administrators need to perform the following:

  1. Specify a site definition:

    • Specify the name of the site

    • Specify the listening port number of the site

    • Specify the aliases for the site

    Many sites are represented by one or more aliases. Oracle9iAS Web Cache is able to recognize and cache requests for a site and its aliases. For example, site may have an alias of By specifying this alias, Oracle9iAS Web Cache caches the same content from either or

  2. Determine if Oracle9iAS Web Cache communicates with application Web servers or proxy servers.

    Oracle9iAS Web Cache uses application Web servers for internal sites and proxy servers for external sites protected by a firewall.

  3. Specify the host name and listening port number of the application Web server or proxy server.

  4. Map the site to the application Web servers or proxy servers.

  5. Create caching rules that apply to the site and global rules that apply to all sites.

    The site-specific caching rules are given a higher priority than the global rules.


    It may not be possible to specify a site definition for all external ESI provider sites. If an ESI request is made to a provider that does not match any application Web server mapping, then Oracle9iAS Web Cache uses Domain Name System (DNS) to resolve the site name. Note that this will not work if there is a firewall between the cache and the ESI provider. In that case, you must provide a proxy server mapping that directs the request to the appropriate proxy.

    Undefined ESI provider sites disable the following Oracle9iAS Web Cache features:

    • Performance assurance heuristics

    • Application Web server and proxy server features, such as surge protection, load balancing, failover, and session binding

To further understand the mappings, reconsider Figure 1-3. Web sites and can have site aliases of and, respectively. The site to application Web server mappings are as follows:

How Oracle9iAS Web Cache Locates Application Web Severs or Proxy Servers

When Oracle9iAS Web Cache receives a browser request for a document, it determines the destination site using one of the following elements:

Oracle9iAS Web Cache then looks up the configured site settings and mappings to determine if the site is supported, and the application Web servers or proxy servers and caching rules for the site. If there are no site settings and mappings for external ESI provider sites, Oracle9iAS Web Cache uses Domain Name System (DNS) to resolve the site name.

If the request does not include host information, then Oracle9iAS Web Cache sends the request to the default site. A default site is established for the Oracle HTTP Server when Oracle9i Application Web Server is installed. You can specify another site to be the default site.

See Also:

Cache Hierarchies

For high availability and performance, many Internet businesses mirror their Web sites in strategic geographical locations. You can deploy Oracle9iAS Web Caches in a cache hierarchy so that an Oracle9iAS Web Cache server caches content from another Oracle9iAS Web Cache to a local market. Caches serving local markets shortens response time to these markets and reduces bandwidth and rack space costs for the content provider.

Oracle9iAS Web Cache provides supports two kinds of cache hierarchies:

A distributed cache hierarchy centralizes the management of application logic and data to the central cache and provides remote assembly and delivery of content. Compared with full-scale mirroring and database replication, a distributed cache hierarchy provides a more cost-effective model of distributed computing.

The remote cache is configured with the central cache as its application Web server. When the remote cache requests content from the central cache to serve a request, the remote cache identifies itself as an Oracle9iAS Web Cache to the central cache during a transparent registration process. Once registration is complete, the central cache establishes a hierarchical relationship with the remote cache. Registration also enables invalidation messages to be propagated from the central cache to the remote cache.

Figure 1-5 depicts a distributed cache hierarchy. A central cache resides in the United States office and a remote cache resides in the Japan. While the central cache in United States caches content from an application Web server, the remote cache in Japan caches content from the central cache.

Figure 1-5 Distributed Cache Hierarchy

Text description of owcag059.gif follows
Text description of the illustration owcag059.gif

In an ESI cache hierarchy, the subscriber cache is configured with the provider caches as its application Web servers. When the subscriber cache requests content from the provider caches for ESI assembly, the subscriber cache identifies itself as an Oracle9iAS Web Cache to the provider caches during a transparent registration process. Once registration is complete, the provider caches establish a hierarchical relationship with the subscriber cache. Registration also enables invalidation messages to be propagated from the provider caches to the subscriber cache.

Figure 1-6 depicts an ESI cache hierarchy. A subscriber cache performs ESI assembly. Provider caches locally cache ESI fragments for ESI provider sites and During ESI page assembly, the subscriber cache contacts the provider caches for the ESI fragments. By caching the ESI fragments locally on the provider caches, fragments are cached both by the provider and subscriber caches. This provides for quick page assembly.

Figure 1-6 ESI Cache Hierarchy

Text description of owcag057.gif follows
Text description of the illustration owcag057.gif

See Also:

Cache Clusters

To increase the availability and scalability of your Web site, you can configure multiple instances of Oracle9iAS Web Cache to run as members of a cache cluster. A cache cluster is a loosely coupled collection of cooperating Oracle9iAS Web Cache cache instances working together to provide a single logical cache.

Cache clusters provide failure detection and failover of caches, increasing the availability of your Web site. If a cache fails, other members of the cache cluster detect the failure and take over ownership of the cached content of the failed cluster member.

By distributing the Web site's content across multiple Web caches, more content can be cached and more client connections can be supported, expanding the capacity of your Web site.

See Also:

Application Web Server and Proxy Server Features

Oracle9iAS Web Cache provides the following features for the application Web server and proxy server it supports:

Where applicable, the term origin server is used in place of application Web server or proxy server to simplify the concepts presented in this section.

Surge Protection

Oracle9iAS Web Cache passes requests for non-cacheable or stale documents to the origin servers. To prevent an overload of requests on the origin servers, Oracle9iAS Web Cache has a surge protection feature that enables you to set a limit on the number of concurrent requests that the origin servers can handle. When the limit is reached, subsequent requests are queued to wait up to a maximum amount of time. If the maximum wait time is exceeded, Oracle9iAS Web Cache rejects the request and serves a site busy apology page to the Web browser that initiated the request.

Load Balancing

Most Web sites are served by multiple origin servers running on multiple computers that share the load of HTTP and HTTPS requests. All requests that Oracle9iAS Web Cache cannot serve are passed to the origin servers. Oracle9iAS Web Cache balances the load among origin servers by determining the percentage of the available capacity, the weighted availability capacity of each origin server. Oracle9iAS Web Cache sends a request to the origin server with the highest weighted available capacity. The weighted available capacity is determined by the following formula:

(Capacity - Load) / Capacity


If the weighted available capacity is equal for multiple origin servers, then Oracle9iAS Web Cache sends requests to the origin servers in round-robin fashion. With round-robin, the first origin server in the list of configured servers receives the request, then the second origin server receives the second request.

If the weighted available capacity is not equal, Oracle9iAS Web Cache sends the request to the origin server with the highest weighted available capacity.

To configure load balancing, set the capacity of each origin server.

Figure 1-7 shows two sites, and is supported by application Web servers company1-host and company2-host with capacities of 50 each. is supported by application Web servers server1-host, server2-host, and server3-host with capacities of 150, 50, and 50, respectively.

Figure 1-7 Load Balancing

Text description of owcag035.gif follows
Text description of the illustration owcag035.gif

Assuming all application Web servers have an initial load of 0, the requests to and will be distributed in the following manner:

Backend Failover

After a specified number of continuous request failures, Oracle9iAS Web Cache considers an origin server as failed. When an origin server fails, Oracle9iAS Web Cache automatically distributes the load over the remaining origin servers based on the available load. Oracle9iAS Web Cache polls the failed origin server for its current up/down status until it is back online. When the failed server returns to operation, Oracle9iAS Web Cache will include its weighted available capacity to load balance requests.

The failover feature is shown in Figure 1-8. An outage of server3-host, which had a capacity of 50, results in 75 percent of requests being distributed to server1-host and 25 percent request being distributed to server2-host.

Figure 1-8 Failover

Text description of owcag036.gif follows
Text description of the illustration owcag036.gif

Session Binding

Oracle9iAS Web Cache supports Web sites that use a session ID or session cookie to bind user sessions to a given origin server in order to maintain state for a period of time. To utilize the session binding feature, the origin server itself must maintain state, that is, it must be stateful. Web sites bind user sessions by including session data in the HTTP header or body it sends to Web browsers in such a way that the browser is forced to include it with its next request. This data is transferred either with parameters embedded in the URL or cookies, which are text strings stored on the client.

Figure 1-9 shows how Oracle9iAS Web Cache supports documents that use session binding:

  1. When a request first comes in, Oracle9iAS Web Cache uses load balancing to determine to which origin server the request is forwarded. In this example, application Web server is selected.

  2. If the requested document requires session binding, the origin server sends the session information back to the browser through Oracle9iAS Web Cache in the form of a cookie or an embedded URL parameter.

  3. Oracle9iAS Web Cache sends subsequent requests for the session to the origin server that established the session, bypassing load balancing. In this example, application Web server handles the subsequent requests.

To configure session binding, specify a session definition that specifies the name of session cookie or embedded URL parameter.

See Also:

"Binding a Session to an Origin Server" for configuration details


If an origin server is busy, then Oracle9iAS Web Cache disables session binding to that origin server.

Figure 1-9 Session Binding

Text description of owcag005.gif follows
Text description of the illustration owcag005.gif

Security Features

Oracle9iAS Web Cache provides the following security-related features:

Restricted Administration

Oracle9iAS Web Cache restricts administration with the following features:

Secure Sockets Layer (SSL) Support

The Secure Sockets Layer (SSL) protocol, developed by Netscape Corporation, is an industry-accepted standard for network transport layer security. SSL provides authentication, encryption, and data integrity, in a public key infrastructure (PKI). By supporting SSL, Oracle9iAS Web Cache is able to cache pages for HTTPS requests. As shown in Figure 1-10, you can configure Oracle9iAS Web Cache to receive HTTPS browser requests and send HTTPS requests to the origin servers.

Figure 1-10 SSL for Secure Connections

Text description of owcag027.gif follows
Text description of the illustration owcag027.gif

When sending requests to origin servers, note that HTTPS traffic can be processor intensive. If Oracle9iAS Web Cache needs to have traffic travel over the open Internet, then configure Oracle9iAS Web Cache to send HTTPS requests to the origin servers. If traffic only travels through a LAN in a data center, then the traffic can be sent with HTTP so as to reduce the load on the origin servers.


HTTPS support has the following limitations in this release:

  • Oracle9iAS Web Cache does not provide authentication or access control

  • Oracle9iAS Web Cache does not support client-side certification

SSL interacts with the following entities:

Certificate Authority

A certificate authority (CA) is a trusted third party that certifies the identity of third parties and other entities, such as users, databases, administrators, clients, and servers. The certificate authority verifies the party identity and grants a certificate, signing it with its private key. The Oracle9iAS Web Cache certificate must be signed by a CA.

Different CAs may have different identification requirements when issuing certificates. One may require the presentation of a user's driver's license, while another may require notarization of the certificate request form, or fingerprints of the requesting party.

The CA publishes its own certificate, which includes its public key. Each network entity has a list of certificates of the CAs it trusts. Before communicating with another entity, a given entity uses this list to verify that the signature on the other entity's certificate is from a known, trusted CA.

Network entities can obtain their certificates from the same or different CAs. By default, Oracle Advanced Security automatically installs trusted certificates from VeriSign, RSA, Entrust, and GTE CyberTrust when you install a new wallet


A certificate is created when a party's public key is signed by a trusted CA. A certificate ensures that a party's identification information is correct, and that the public key actually belongs to that party.

A certificate contains the party's name, public key, and an expiration date--as well as a serial number and certificate chain information. It can also contain information about the privileges associated with the certificate.

When a network entity receives a certificate, it verifies that it is a trusted certificate--one issued and signed by a trusted certificate authority. A certificate remains valid until it expires or is terminated.


A wallet is a transparent database used to manage authentication data such as keys, certificates, and trusted certificates needed by SSL. A wallet has an X.509 version 3 certificate, private key, and list of trusted certificates.

Security administrators use the Oracle Wallet Manager to manage security credentials on the Oracle9iAS Web Cache server. Wallet owners use it to manage security credentials on clients. Specifically, Oracle Wallet Manager is used to do the following:

To support HTTPS for Oracle9iAS Web Cache, create a wallet on the Oracle9iAS Web Cache server for each supported site. When creating listening ports for Oracle9iAS Web Cache, specify the location of the wallet. One wallet can be shared among all the listening ports, or a separate wallet can be created for each port.

See Also:

How SSL Works

To describe how SSL works in an HTTPS connection, the word client is used to describe either a browser or Oracle9iAS Web Cache, and the word server is used to describe either Oracle9iAS Web Cache or an origin server.

The authentication process between the client and server consists of the steps that follow:

  1. The client initiates a connection to the server by using HTTPS.

  2. SSL performs the handshake between the client and the server.

At the commencement of an HTTPS network connection between the client and server, an SSL handshake is performed. An SSL handshake includes the following actions:


You can select to have Oracle9iAS Web Cache compress both cacheable and non-cacheable documents upon insertion into the cache for browsers. Because compressed documents are smaller in size, they are delivered faster to browsers with fewer round-trips, reducing overall latency. On average, Oracle9iAS Web Cache is able to compress text files by a factor of 4. For example, 300 KB files are compressed down to 75 KB.

Compatibility with Oracle9iAS Components

Table 1-1 describes Oracle9iAS Web Cache compatibility with other Oracle9iAS components.

Table 1-1  Oracle9iAS Web Cache Compatibility with Oracle9iAS Components
Oracle9iAS Component Description

Oracle9iAS Clickstream Intelligence

Oracle9iAS Discoverer access logs import easily into Oracle9iAS Clickstream Intelligence, which provides a rich set of data warehousing and clickstream analysis functionality.

See Also: "Configuring Access Logs" and Oracle9iAS Clickstream Intelligence Administrator's Guide

Oracle9iAS Discoverer

Starting with Oracle9i Application Server release 2, Oracle9iAS Discoverer has been closely integrated with Oracle9iAS Web Cache to improve Discoverer Viewer's overall scalability, performance, and availability. Oracle9iAS Web Cache ships with a number of predefined caching rules for this purpose, and Oracle9iAS Discoverer uses ESI Surrogate-Control headers to govern cacheability of other non-configured responses. Because of this integration, the load on mid-tier and database servers in Oracle9iAS Discoverer deployments is reduced, more Discoverer Viewer users are able to access the system concurrently, and those users experience significantly better response times for workbook operations and common business intelligence queries.

See Also: Oracle9iAS Discoverer Configuration Guide

Oracle9iAS Forms Services

Oracle9iAS Web Cache does not currently work applications that use Oracle9iAS Forms Services.

Oracle9iAS Portal

Oracle9iAS Web Cache has been closely integrated with Oracle9iAS Portal to improve Portal's overall scalability, performance and availability. Oracle9iAS Portal ships with a number of pre-defined caching and invalidation policies that ensure optimal use of Oracle9iAS Web Cache. Oracle9iAS Web Cache controls have been built into the Oracle9iAS Portal administrative user interface and can also be specified by content providers through the Portlet Developer Kit (PDK).

See Also: Oracle9iAS Portal online help and Oracle9iAS Portal Configuration Guide

Oracle9iAS Reports Services

Oracle9iAS Web Cache cannot be used to accelerate Oracle9iAS Reports Services in this release.

Oracle9iAS Single Sign-On

Applications that use Oracle9iAS Single Sign-On can take advantage of Oracle9iAS Wireless. Both Oracle9iAS Web Cache and mod_SSO, a feature of Oracle HTTP Server, have been configured out of the box to ensure that single sign-on authentication requests are tunneled transparently through Oracle9iAS Web Cache. No additional configuration is required on the customer side.

See Also: Oracle9iAS Single Sign-On Administrator's Guide

Oracle9iAS Wireless

Oracle9iAS Wireless is integrated with Oracle9iAS Web Cache to improve page rendering performance and scalability. It should be noted that Oracle9iAS Web Cache does not understand WAP and is not used by Oracle9iAS Wireless in the traditional sense in that the cache does not "front-end" the wireless server. Instead, the cache is used as a repository for post-transformed content; the wireless runtime determines what content needs to be inserted into the cache and when to expire content in the cache. Oracle9iAS Wireless, in this case, acts as a device adaptation cache rather than a reverse-proxy cache. Since markup content is cached using Oracle9iAS Wireless, the performance and scalability benefits are due to two factors--reduced device adaptation costs and significantly reduced adapter invocation costs. The savings in terms of device adaptation costs stem form the fact that content that can be shared across users and sessions is essentially transformed only once (for each logical device) from its Mobile XML format. Secondly, since the content is not generated every time by an adapter, the total adapter invocation cost is significantly educed for a site that has a large subset of cacheable pages.

See Also: Oracle9iAS Wireless Getting Started and System Guide

Go to previous page Go to next page
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Go To Product List
Solution Area
Go To Table Of Contents
Go To Index