2 Caching Concepts

Invalidation

You use invalidation for frequently changing content. With invalidation, OracleAS Web Cache marks objects as invalid. When objects are marked as invalid and a client requests them, they are removed and then refreshed with new content from the origin servers. You can choose to remove and refresh invalid objects immediately, or base the removal and refresh on the current load of the origin servers.

Expiration

With expiration, OracleAS Web Cache marks objects as invalid after a certain amount of time in the cache. Expirations are useful if you can accurately predict when content will change on an origin server or database. To prevent objects from remaining in the cache indefinitely, Oracle recommends creating expiration policies for all cached objects.

HTTP Cache Validation

OracleAS Web Cache uses HTTP/1.1 validation models to determine how to best serve a response to clients. Validation works by the comparing two validators, one in the request header and the other in the cached object's response header, to determine if they represent the same or different entities. Specifically, OracleAS Web Cache uses the If-Modified-Since and If-None-Match for cache hits.

Performance Assurance Heuristics

One could logically assume that widespread cache invalidation or expiration would negatively impact performance of the origin servers, resulting in the generation of HTTP 503 Server Unavailable errors to clients. For this reason, OracleAS Web Cache intelligently serves some of the objects stale until the origin servers have the capacity to refresh them.

OracleAS Web Cache provides minimal trade-off between performance and consistency through performance assurance heuristics that determine which objects can be served stale. These heuristics are based on a number of factors including:

• Validity

  Validity is based on the expiration time, invalidation time, and removal time of an object.

• Popularity

  Popularity is determined by:

  • The number of times the object has been requested since insertion into the cache

  • The number of recent requests for the object

• Total available capacity of origin servers

  The total available capacity is determined by the following formula:

  Total Capacity - Total Load
  
  

  In the formula:

  • Total Capacity is the accumulated maximum number of concurrent connections of all origin servers

  • Total Load is the total number of connections currently used by all the origin servers

Together, these factors provide OracleAS Web Cache with a logical queue of content to update from the origin servers.

Multiple Versions of the Same Object

Some pages have multiple versions, enabling categorization. Figure 2-1 shows the same object, https://oraclestore.oracle.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=293017&section=11538, with different prices for customers and internal Oracle employees. While customers pass a cookie name and value of ec-400-id-acctcat=WALKIN, employees pass a cookie name and value of ec-400-id-acctcat=INTERNAL.

Figure 2-1 Multiple-Version Object

Description of "Figure 2-1 Multiple-Version Object"

You can configure OracleAS Web Cache to recognize and cache multiple-version pages by using the:

• Values of the cookie for the page

• HTTP request headers for the page

For those objects that use a cookie (sometimes referred to as a category cookie), configure caching rules that specify the cookie name and whether to cache versions of the object that do not use the cookie.

When a client sends an initial request for a multiple-version object, OracleAS Web Cache passes the request to the origin server. In its response, the origin server includes a Set-Cookie response-header with the category cookie and its value:

Set-Cookie:cookie=value

Upon receiving the Set-Cookie response-header field, the client stores the cookie in memory. With its next request to the same origin server, the client includes the Cookie request-header field with the category cookie name and value that was received in the last response:

Cookie:cookie=value

OracleAS Web Cache evaluates whether the cookie and its value set in the Set-Cookie response-header matches the cookie and its value set in the Cookie request-header. If the cookie and value match, then the response is cached. If cookie and its value do not match, then the response is not cached. After versions of the object are cached, OracleAS Web Cache uses the value of the cookie in the client's request to serve the appropriate version of the object to the client browser.

Table 2-1 shows four different versions of same URL, http://www.dot.com/page1.htm. The URL uses a cookie named user_type, which supports client requests that contain cookie values of Customer, Internal, and Promotional. You can configure OracleAS Web Cache to recognize the user_type cookie, enabling OracleAS Web Cache to cache three different objects. In addition, you can configure OracleAS Web Cache to cache a fourth object for those requests that do not use a cookie.

For those objects that have different versions based on HTTP request headers, configure caching rules that specify the HTTP request header. HTTP request headers enable clients to pass additional information about the request and about themselves. OracleAS Web Cache uses the header to serve the appropriate version of the URL to clients.

OracleAS Web Cache supports all valid HTTP request headers. Table 2-2 lists the HTTP request-header fields supported by the Application Server Control Console and OracleAS Web Cache Manager interfaces, as described in "Configuring Caching Rules and Rule Association". You can specify other HTTP request-header fields with the Surrogate-Control response-header field, as described in "Configuring Expiration Policies".

Personalized Attributes

Many Web pages use a personalized attribute for personalized greetings like "Hello, Name," icons, addresses, or shopping cart snippets, on an otherwise generic page. You can mark the personalized attribute information with OracleAS Web Cache HTML tags <!-- WEBCACHETAG--> and <!-- WEBCACHEEND-->.

OracleAS Web Cache processes these tags and caches the instructions for substituting values for personalized attributes based on the information contained within a cookie, embedded URL parameter, or POST body parameter.

This functionality enables OracleAS Web Cache to use the same page for multiple users. Because only one page needs to be cached, only one origin server request is required to initially populate the cache with the page. The initial request sets the personalized attribute cookie or parameter. All subsequent requests for the page that pass the cookie or parameter are served from the cache.

Figure 2-2 shows two users, Jane Doe and John Doe, accessing the same page, https://oraclestore.oracle.com/OA_HTML/ibeCZzpHome.jsp?a=b. This page contains a personalized greeting suited to the user.

Figure 2-2 Page with a Personalized Attribute

Description of "Figure 2-2 Page with a Personalized Attribute"

The personalized greeting Jane Doe uses the following HTML code:

<B>
<!-- WEBCACHETAG="person01"-->
Jane Doe
<!-- WEBCACHEEND-->
</B>

The personalized greeting John Doe uses the following HTML code:

<B>
<!-- WEBCACHETAG="person01"-->
John Doe
<!-- WEBCACHEEND-->
</B>

person01 represents the personalized attribute definition assigned to the person_name cookie that Jane and John pass to OracleAS Web Cache. Jane passes a cookie name/value pair of person_name=Jane+Doe, and John Doe passes a cookie name/value pair of person_name=John+Doe. When OracleAS Web Cache receives the cookie information from Jane and John, it maps the person_name cookie to the person01 personalized attribute definition and substitutes the cookie value.

If the page supported embedded URL parameters, then the URL would contain the person_name parameter. For example, the page for Jane Doe could be https://oraclestore.oracle.com/OA_HTML/ibeCZzpHome.jsp?a=b&person_name=Jane+Doe, and the page for John Doe could be https://oraclestore.oracle.com/OA_HTML/ibeCZzpHome.jsp?a=b&person_name=John+Doe. You could configure OracleAS Web Cache with a personalized attribute definition of person_name01 to map to the person_name embedded URL parameter. OracleAS Web Cache would then use the value of the embedded parameter to substitute the appropriate name.

If the page supported POST body parameters, then the POST body for https://oraclestore.oracle.com/OA_HTML/ibeCZzpHome.jsp would contain the following code for Jane Doe and John Doe:

person_name=Jane+Doe
&cart_items=0
&a=b

person_name=John+Doe
&cart_items=0
&a=b

To substitute personalized attribute values:

1. Configure a personalized attribute definition with the personalized attribute cookie, embedded URL parameter, or POST body parameter.

2. Configure a caching rule with the option Session-Encoded URL enabled. Only requests matching the caching rule will perform the substitution.

If a request does not contain the value of the cookie or parameter, OracleAS Web Cache substitutes the personalized attribute with a default string.

Session Information

Some Web sites keep track of user sessions by assigning each user a unique session ID. When a client first accesses a Web site that uses session IDs, the origin server includes a Set-Cookie response-header in the response with the session cookie and value in order to establish a session.

Alternatively, origin servers can track a session with the client by including the session value in an embedded URL or POST body parameter. With its next request to the same origin server, the client includes the embedded URL or POST body parameter. Because of the embedded URL or POST body parameter, the origin server determines that the client already has a session.

Using session information in a cookie, embedded URL parameter, or POST body parameter, you can configure OracleAS Web Cache for the following purposes:

• Excluding the Value of Embedded URL or POST Body Parameters

• Substituting Session Information in Session-Encoded URLs

• Controlling How Session Requests Are Served by the Cache

https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103&session_ID=33436
 

https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103&session_ID=33437

section=1013
&session_ID=3346

section=1013
&session_ID=3347

Substituting Session Information in Session-Encoded URLs

The section "Excluding the Value of Embedded URL or POST Body Parameters" describes how you can ignore the value of embedded URL or POST body parameters for objects with identical content for all sessions. However, in some cases, the HTML content of objects is programmed with hyperlink tags, such as <A HREF=...>, that contain embedded session information to distinguish users. These links are called session-encoded URLs. The use of session-encoded URLs results in responses that vary slightly from session to session.

You can configure OracleAS Web Cache to substitute sessions within HTML hyperlink tags with the session values obtained from a session cookie, embedded URL parameter, or POST body parameter. By configuring session value substitution in combination with ignoring the value of embedded URL parameters, you can configure OracleAS Web Cache to cache one object for multiple sessions, even if the session parameter values in session-encoded URLs vary.

Note: OracleAS Web Cache does not cache the Set-Cookie response header field.

Continuing with the example from "Excluding the Value of Embedded URL or POST Body Parameters", assume that Jane Doe and John Doe are again assigned an embedded URL parameters of session_ID=33436 and session_ID=33437 by the origin server. The page shown in Figure 2-3 has several <A HREF=...> links that include the session_ID parameter. The Master Index link under the Oracle Database Standard Edition heading for Jane Doe uses the following HTML code:

<A HREF="http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10166&session_ID=334326">Master Index</A>

The same link for John Doe uses the following HTML code:

<A HREF="http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10166&session_ID=334327">Master Index</A>

By using the value of the session_ID embedded URL parameter, OracleAS Web Cache substitutes the correct session information for Jane Doe and John Doe.

Figure 2-3 Session-Encoded URLs

Description of "Figure 2-3 Session-Encoded URLs"

After the cache is populated with a page that contains session-encoded URLs, other requests for the page are served from the cache, regardless of whether the request has a session cookie, embedded URL parameter, or POST body parameter. If the request does not contain a session cookie or embedded URL parameter, OracleAS Web Cache substitutes the session information in the session-encoded URLs with a configurable default string.

To substitute session values in session-encoded URLs:

1. Configure a session definition with the session cookie, embedded URL parameter, or POST body parameter. You can use the same session definition used for ignoring a URL parameter. When creating the session definition, configure the default string.

2. Configure a caching rule with Session-Encoded URL enabled. Only requests matching the caching rule will perform the substitution.

See Also: "Configuring Support for Session-Encoded URLs"

Page Assembly Components

The basic structure that an application developer uses to create content for partial-page caching is a template page containing fragments. As depicted in Figure 2-4, the template consists of common elements, such as a logo, navigation bars, framework, and other "look and feel" elements of the page. The fragments represent dynamic subsections of the page.

Figure 2-4 Template Page

Description of "Figure 2-4 Template Page"

The template page is associated with the URL that end users request. To include the fragments, the template page is configured with ESI markup tags that instruct OracleAS Web Cache to fetch and include the HTML fragments. The fragments themselves are HTML files containing discrete text or other objects.

Each included fragment is a separate object with its own caching policy. Content providers may want to cache the template for several days, but only cache a particular fragment, such as an advertisement or stock quote, for a matter of seconds or minutes. Other fragments (such as a user's bank account total) may be declared non-cacheable.

Table 2-3 provides a summary of the main ESI tags.

Example 2-1 shows the ESI markup language for the template page shown in Figure 2-4.

<HTML>
<HEAD>
<TITLE>
Company.com
</TITLE>
</HEAD>
<BODY>
...
<!-- The following <esi:comment> tags are removed if this page is processed by an ESI processor. -->

<!--esi

 <esi:comment text="This is the HTML source when ESI is enabled." />

 <esi:comment text="Start: The quick link section. You cannot use the standard
 HTML comments because the end of that comment tag would disrupt the HTML comment
tag with 'esi' following the two '-'." />

 <esi:comment text="The URI query string parameter 'sessionID' is used to carry
session identifiers, The session ID is encoded in all links." />

 <esi:comment text="'Profile' refers to environment variables stored in
 GetProfile.jsp. GetProfile.jsp enables access to 'PersonalInterest.' 'zipcode,'
 'tickers,' and 'address' environment variables." />

 <esi:environment src="/GetProfile.jsp?sessionID=$(QUERY_STRING{sessionID})"
name="Profile" />

<esi:vars>
   <A HREF="/shopping.jsp?sessionID=$(QUERY_STRING{sessionID})">
     <IMG SRC="/img/shopping.gif">
   </A>
   <A HREF="/news.jsp?sessionID=$(QUERY_STRING{sessionID})">
     <IMG SRC="/img/news.gif">
   </A>
   <A HREF="/sports.jsp?sessionID=$(QUERY_STRING{sessionID})">
     <IMG SRC="/img/sports.gif">
   </A>
   <A HREF="/fun.jsp?sessionID=$(QUERY_STRING{sessionID})">
     <img src="/img/fun.gif">
  </A>
  <A HREF="/about.jsp?sessionID=$(QUERY_STRING{sessionID})">
     <iMG SRC="/img/about.gif">
   </A>
 </esi:vars>

 <esi:comment text="End: The quick link section" />
...
 <H3>Local Weather</H3>
 <esi:include src="/weather.jsp?sessionID=$(QUERY_STRING{sessionID})&zipcode=$(Profile{zipcode})" />
...

 <H3>Stock Quotes</H3>
 <esi:try>
   <esi:attempt>
     <esi:include src="/CompanyStock.jsp?sessionID=$(QUERY_ STRING{sessionID})&tickers=$(Profiles{tickers})" />
   </esi:attempt>
   <esi:except>
     The company stock quote is temporarily unavailable.
   </esi:except>
 </esi:try>
...
 <H3>What's New at Company</H3>
 <!-- This section is a static file that does not carry session information -->
 <esi:include src="/whatisnew.html" />

...

 <H3>Today's News</h3>
 <esi:choose>

   <esi:when test="$(Profile{PersonalInterests}) == 'Sports'">
     <H4>Sport News</H4>
     <esi:include src="/SportNews.jsp?sessionID=$(QUERY_STRING{sessionID})" />
   </esi:when>

   <esi:when test="$(Profile{PersonalInterests}) == 'Career'">
     <H4>Financial News</H4>
     <esi:include src="/FinancialNews.jsp?sessionID=$(QUERY_STRING{sessionID})" />
   </esi:when>

   <esi:otherwise>
     <H4>General News</H4>
     <esi:include src="/DefaultNews.jsp?sessionID=$(QUERY_STRING{sessionID})" />
   </esi:otherwise>

 </esi:choose>

...

-->

<!-- This is the HTML source when ESI is disabled. -->
<esi:remove>
Alternative HTML source that does not use ESI goes here. This tag enables you 
to disable ESI on the fly without redeveloping or redeploying a different version
 of the page. 
</esi:remove>
...
</BODY>
</HTML>

Example 2-2 shows the XML response of GetProfile.jsp, which provides access to profile environment variables.

<?xml version=1.0?>
<esi:environment esiversion="ORAESI/9.0.4">
  <PersonalInterests>Sports</PersonalInterests>
  <zipcode>94065</zipcode>
  <tickers>ORCL,YHOO</tickers>
  <address>500 Oracle Parkway, Redwood Shores, CA 94065</address>
</esi:environment>

Fragmentation with the Inline and Include Tags

The <esi:inline> and <esi:include> tags enable applications to adopt ESI page fragmentation and assembly. The following sections describe the tags and explain when the tags are appropriate to use.

• Using Inline for Non-Fetchable Fragmentation

• Using Inline for Fetchable Fragmentation

• Using Include for Fragmentation

• Selecting the Fragmentation Mechanism for Your Application

<HTML>
...
<esi:inline name="/news101">
<TABLE>
...
</TABLE>
</esi:inline>
...
</HTML>

<HTML>
...
<esi:inline name="/news101" fetchable="yes">
<TABLE>
...
</TABLE>
</esi:inline>
...
</HTML>

Referer Request-Header Field

When OracleAS Web Cache receives a client request for a template page with a Referer request-header field, it forwards the request with the Referer request header to the origin server. In turn, the origin server returns fragments to OracleAS Web Cache with the URL of the template as the value for the Referer header. This functionality associates the fragment request with the template request.

Cookie Management for Template Pages and Fragments

Session cookie establishment for ESI templates and fragments works much the same way as typical OracleAS Web Cache objects with the following additional features:

• Cookie request-header field inheritance

  When a client requests an ESI template page that includes fragments, requests for fragment pages are generated in OracleAS Web Cache. A fragment request inherits the Cookie request-header field from the template request if the value of the Host request-header field matches the value of Host request-header field in the template request.

• Set-Cookie response-header field accumulation

  When assembly of fragments is complete, OracleAS Web Cache includes a Set-Cookie response-header field in the response with the cookie information from the template. For those fragments with a Host request-header field that matches the Host request-header field in the template, OracleAS Web Cache also accumulates the Set-Cookie response-header fields with that of the template. For those fragments with a Host request-header field that does not match the Host request-header field in the template, OracleAS Web Cache does not accumulate the Set-Cookie response-header field with that of the template and other matching fragments.

  
  

  See Also: "Session Information" for an overview of Cookie and Set-Cookie behavior "Variable Expressions" for a description of how you can use the HTTP_COOKIE variable in ESI markup

  
  

ESI Features

ESI can be used with HTML, XML, JSP, ASP, and any Web programming technology. The ESI language includes the following features:

• Inclusion

  An ESI processor assembles HTTP or HTTPS fragments of dynamic content, retrieved from the network, into aggregate pages to output to the user. Each fragment can have its own caching rules.

• Support of variables

  ESI supports the use of variables based on HTTP request attributes, as well as custom variables from included HTML fragments. Variables can be used by ESI statements during processing or can be output directly into the processed markup.

• Conditional processing

  ESI allows use of Boolean comparisons for conditional logic in determining how pages are processed.

• Error handling and alternative processing

  Some ESI tags support specification of a default resource or an alternative resource, such as an alternate Web page, if the primary resource cannot be found. Further, it provides an explicit exception-handling statement block.

• Character set conversion

  ESI fragments in different character sets are converted to one character set. This way, all partial pages are assembled in a fixed character set. Character set conversion works in the following manner:

  1. OracleAS Web Cache receives a request for a template page.

  2. OracleAS Web Cache fetches the fragments, and converts all of the fragments to the template's character set. The default character set is ISO-8859-1.

  OracleAS Web Cache does not perform character set conversion for non-ESI pages.

• XML conversion to HTML

  OracleAS Web Cache uses XSL Transformations (XSLT) to transform XML fragments into HTML.

ESI for Java (JESI)

OC4J provides the JESI tag library as a convenient interface to ESI tags and functionality. Developers have the option of using ESI tags directly in any Web application, but JESI tags provide additional convenience in a JSP environment.

Because ESI and JESI are open standards, you can use the JESI tag library in any standard JSP environment as long as an ESI processor, such as OracleAS Web Cache, is available.

Even though JSP developers can always use ESI, JESI provides an even easier way for JSP developers to express the modularity of pages and the cacheability of those modules, without requiring developers to learn a new syntax.

Oracle JDeveloper Support for ESI and JESI

Oracle JDeveloper provides the ESI Servlet Filter extension, which enables developers to create JSPs with ESI or JESI tags, and test them within the development environment. ESI and JESI are caching standards for developing high-performance J2EE applications. Without the extension, JSPs developed with ESI or JESI will not be rendered properly when previewed in Oracle JDeveloper.

Surrogate-Capability Request-Header Field

For each requested object from the cache, OracleAS Web Cache appends a Surrogate-Capability request-header field to an object's HTTP request message. The Surrogate-Capability request-header serves the following purposes:

• Enables applications to detect OracleAS Web Cache

• Identifies the types of ESI operations that OracleAS Web Cache can perform

Server Response-Header Field

For objects sent to clients, OracleAS Web Cache adds diagnostic information to the Server response-header field of the HTTP response message.

Using the Server response header information, you can determine whether a request was served from the cache or the origin server. For diagnostics purposes, it can be useful to also display this information as a textual string in the HTML response body of an object and in the access logs.

Surrogate-Control Response-Header Field

The Surrogate-Control response-header field enables application developers to specify caching attributes of an object. This response-header field enables the application Web server to override the caching rules configured through administrative interfaces Oracle Enterprise Manager 10g Application Server Control Console or OracleAS Web Cache Manager.

Surrogate-Key Response-Header Field

The Surrogate-Key response-header field enables application developers to identify search key strings for a given response object. Search keys are strings that may not appear in the URL, cookies, or HTTP request headers of objects. The intent of the search keys is to provide another criteria for invalidation. In addition to the URL of objects, OracleAS Web Cache administrators can base invalidation on one or more search keys used in the Surrogate-Key response-header field of objects in the cache.