Oracle9iAS Portal Developer Kit
Understanding how Oracle9iAS Portal uses Web Cache

Oracle9iAS Web Cache is the industry’s leading HTTP/HTTPS dynamic content caching solution and it is available in Oracle9i Application Server Release 2 (Oracle9iAS).

This article describes the key features of Web Cache and explains how Oracle9iAS Portal makes use of this functionality.

Oracle9iAS Web Cache

Web Cache (included with Oracle9iAS Enterprise Edition) is closely integrated with Oracle Portal. Unlike legacy cache servers which only handle static data, Web Cache combines caching, compression and assembly technologies to accelerate the delivery of both static and dynamically generated Portal content. Web Cache also provides back-end Web server load balancing, failover and surge protection features which together provide great improvements to Portal scalability, performance and availability. With Web Cache, Portal can serve rich content faster, to more users, using fewer computing resources than ever before.

In Oracle9iAS Release 2, Portal functions as a Web Cache origin server to take advantage Web Cache features.

Key Features of Web Cache

- Caches dynamically generated, session-specific page and portlet content:

Web Cache understands the content of HTTP headers (including cookies) which allows it to cache the personalized content that is uniquely maintained and generated for each Oracle Portal user.

- Fine-grained cache control:

Administrator-defined caching rules allow caching and routing decisions based on HTTP header information, including cookies. Oracle Portal has several pre-defined caching rules that ensure optimal use of Web Cache capabilities. Web Cache controls can be set from within Oracle Portal and can also be specified by providers through the Portal Developer Kit (PDK).

- Invalidation-based caching:

Cache invalidation can be based on an expiry period, or an invalidation message sent by an application when content needs to be refreshed. Oracle Portal automatically sets the correct caching policy for every object managed in the Portal Repository, and ensures that invalidation messages are sent to Web Cache when content is modified or security privileges are altered.

- Layer 7 load balancing and failover detection:

Web Cache can be used to balance the load between multiple Portal middle-tier servers and/or providers in a cluster. Cache misses are directed to the most available, highest-performing middle-tier server or provider in a server farm. Cookies can be used to maintain persistent, or "sticky", connections to a specific server, when necessary to preserve state.

- Performance assurance and surge protection:

Web Cache offers patent-pending techniques to guarantee site performance and scalability, even when Web server loads surpass capacity levels. A surge protection mechanism detects system overload conditions, providing a crucial buffer against traffic spikes and denial-of-service attacks.

In future releases, Oracle Portal will also take advantage of the partial-page caching and content assembly features of Web Cache. Partial page caching is a feature which enables Web Cache to cache constituents of a page separately. This enables separate caching of fragments of customized content and more shareable page templates. When a page is requested, Web Cache fetches the page templates and page fragments and assembles them into a single page, acting as a page assembler as well.

Oracle9iAS Portal and Web Cache

Architecture

Oracle Portal is front-ended by Web Cache in the Oracle9iAS Release 2. This architecture ensures that all requests to Portal pass through the Web Cache and that various page components are cached. Figure 1 illustrates the request flow for a page through Web Cache (the details of the architecture is beyond the scope of this article).

Figure 1: Oracle9iAS Portal Architecture

Web Cache Deployment Architecture

When Oracle Portal is installed, a Web Cache instance is automatically created with predefined caching rules and cache configuration settings. Oracle Portal sites can choose between these deployment options:

- Co-located:

Web Cache runs on the same physical server as the Oracle Portal middle-tier. This configuration is appropriate for small, low-volume sites where scalability of the middle-tier is not a concern.

- Dedicated:

Web Cache is deployed on a dedicated server that sits in front of one or more Oracle Portal middle-tier servers. Dedicated deployments are usually preferable to CO-located, as there is no risk of resource contention with other server processes. Web Cache performs excellently on commodity hardware, so a dedicated deployment need not be a costly one in terms of hardware expenditure.

For very high-volume sites, and to avoid a single point of failure, two or more nodes running Web Cache may be deployed behind a third-party network load-balancing device.

For more information, please refer to the Web Cache documentation on OTN.

Web Cache Settings in Oracle Portal

Oracle Portal allows Portal administrators to set various Portal-specific Web Cache configuration properties on the Global Settings page, as shown in Figure 2 below.

Figure 2: Web Cache Settings in Oracle Portal

This table describes these settings:

Enable Web Cache for Caching Portal Content | Select this checkbox to use the Web Cache for caching Portal content for pages and portlets. Deselect the checkbox if you do not want Portal to use the Web Cache for caching purposes. Deselect the checkbox for debugging purposes only, since it can severely degrade Portal's performance.
Clear the Entire Cache in the Web Cache | Select this checkbox to clear all of the Portal's cache content from the Web Cache. Use this option sparingly since it could impact Portal performance until the cache gets repopulated.
Clear the Cache in the Web Cache for User | Select the username to clear all of the Portal's cache content from the Web Cache for one particular user. Use this option sparingly since it could impact Portal performance until the cache gets repopulated.
Maximum Expiry Time | Enter a new value for the Maximum Expiry time. The default value is 1440 minutes (24 hours). All objects that use invalidation-based caching are cached in the Web Cache for the Maximum Expiry time. The cache contents expire after the Maximum Expiry time even if they are not invalidated during that period. Note: If you choose a small value, this could lead to cache misses more frequently because of the cache expiring often. However, choosing a large value might lead to stale content if content providers do not proactively issue invalidation messages.

Revision History:

January 17, 2002.