2
Oracle Web Cache Concepts

This chapter explains how Oracle Web Cache is populated with content, how that content maintains consistency, and how dynamically generated content is cached. This chapter contains these topics:

• Populating Oracle Web Cache

• Cache Freshness and Performance Assurance

• Caching Dynamically Generated Content

Populating Oracle Web Cache

Oracle Web Cache uses cacheability rules to determine which documents to cache. When Oracle Web Cache is first configured with a cacheability rule for a set of documents, those documents are not initially in the cache until there is a browser request for those documents. When a request comes in, Oracle Web Cache sends the request to the application Web server. If the requested document is specified as one of the documents to cache, Oracle Web Cache caches the document for subsequent requests.

If a document contains a cookie, Oracle Web Cache evaluates the cookie value of the browser request and application Web server response. If the values match and there is a corresponding cacheability rule, Oracle Web Cache caches the response. However, session cookie values are not evaluated. For documents that use these cookies, the response is cached, regardless if the cookie values match.

Note: The cache can also be populated with Apache Benchmark tool. See your Apache documentation for further information.

See Also: "Caching Dynamically Generated Content" for an overview of cookies

Cache Freshness and Performance Assurance

Consistency and performance are crucial for the reliability of Oracle Web Cache.

Invalidation and expiration ensure consistency between the cache and the content on the application Web servers. With invalidation, a HTTP message is sent by specifying which documents to mark as invalid. With expiration, documents are marked as invalid after a certain amount of time in the cache. When documents are marked as invalid and a browser requests them, they are either immediately removed and refreshed or refreshed whenever the application Web servers can refresh them.

Expirations are useful if it can be accurately predicated when content will change on an application Web server or database. An invalidation messages is intended for less predictable, more frequently changing content.

One could logically assume that widespread cache invalidation or expiration would negatively impact performance of the application Web servers, resulting in the generation of HTTP 503 Server Busy errors in the access log file or even application Web server overload. For this reason, Oracle Web Cache intelligently serves some of the documents stale until the application Web servers have the capacity to refresh them.

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

Popularity of Document	Popularity is determined by: The number of times the documentation has been requested since being placed in the cache The number of recent requests for the document
Validity of Document	The level assigned during invalidation or expiration. The higher the validity level, the longer Oracle Web Cache serves these documents stale from the cache before invalidating them. For documents with lower validity levels, Oracle Web Cache serves these documents stale for a short amount of time before invalidating them. Critical documents should be assigned a low validity level, and non-critical documents should be assigned a higher validity level.
Load of the Application Web Server	The current load on the application Web server is determined by the number of open connections from Oracle Web Cache to the application Web servers, that is, the total number of pending requests to the application Web servers.
Limit on the Application Web Server	The configured limit on the application Web server load is the configured number of concurrent connections the application Web server can have.

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

Note: Performance assurance heuristics apply when you configure documents to be refreshed based on when the application Web servers can refresh them; performance assurance heuristics do not apply when documents are immediately removed.

Figure 2-1 illustrates how performance assurance heuristics are used during widespread invalidation. At the beginning of the invalidation curve, the number of fresh cache hits decrease to 20 and the number of stale cache hits increase to 4,980. However, during invalidation, the number of fresh cache hits quickly increase. This is because Oracle Web Cache refreshes the most popular documents first so that these documents have little chance of being served stale. Once the popular documents are refreshed, the less popular documents are refreshed. The total number of documents that can revalidated in a given period of time is dependent on application Web server capacity. At the end of invalidation, only fresh content is served.

Figure 2-1 Performance Assurance Heuristics Graph

Text description of the illustration concept4.gif

Caching Dynamically Generated Content

Because of invalidation, Oracle Web Cache knows what documents are valid and what documents are invalid. This is especially important for dynamically generated content that changes frequently. Dynamically generated content is created using technologies like Java Server Pages (JSP), Active Server Pages (ASP), PL/SQL Server Pages (PSP), Java Servlets, and Common Gateway Interface (CGI). Examples of pages that are dynamically generated include:

• A Web site's product catalog, where information on pricing and inventory might vary from one moment to the next

• Auction views, which must be regenerated after each successful bid is processed

• Search results, which can change as catalog items are added and removed

Most static caches and content distribution services have no mechanism to verify the consistency of dynamically generated Web pages with the data sources used to create them. Therefore, it is difficult for these services to know when content has changed. Oracle Web Cache, on the other hand, receives invalidation messages from the application Web server, containing the original content.

For dynamically generated pages, browsers pass information about themselves to the application Web server, enabling the application Web server to serve appropriate content to the browser.

The HTTP protocol has a way for browsers and application Web servers to share information, such as session or category information, in message headers that browsers pass with every request to the application Web server. This message header can contain a cookie.

Cookies are stored on the browser's file system and are often used for identifying users who revisit Web sites. Many users choose to disable cookies in their browsers out of privacy concerns. For this reason, application Web servers often embed parameter information in the URL.

Oracle Web Cache is able to recognize both cookies and embedded URL parameters, enabling it to recognize cacheability rules for pages with:

• Multiple Versions of the Same URL

• Personalized Attributes

• Session Information

  See Also: http://www.cookiecentral.com/ for further information about cookies

Multiple Versions of the Same URL

Some pages have multiple versions of the same URL, enabling categorization. Figure 2-2 shows the same URL, http://store.oracle.com/cec/cstage?eccookie=&ecsid=1225&ecaction=ecproditemlistbysupersect&template=decsectview_mp.en.htm, 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=CUSTOMER.

Figure 2-2 Multiple-Version URL

Text description of the illustration concepta.gif

You can configure Oracle 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 URLs that use a cookie (sometimes referred to as a category cookie), you set cacheability rules that specify the cookie name and whether to cache versions of the URL that do not use the cookie.

When a browser sends a request to an application Web server for a multiple-version document and the value of the browser's cookie matches the value of the application Web server's response, the version of the document is cached. If the cookie values do not match, then the version of the document is not cached. Once versions of the document are cached, Oracle Web Cache uses the value of the cookie in the browser's request to serve the appropriate version of the URL to the 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 browser requests that contain cookie values of Customer, Internal, and Promotional. You can configure Oracle Web Cache to recognize the user_type cookie, enabling Oracle Web Cache to cache three different documents. In addition, you can configure Oracle Web Cache to cache a fourth document for those requests that do not use a cookie.

Table 2-1 Multiple-Version URL with Different Cookie Values

Version	URL	Cookie Name/Value
1	http://www.dot.com/page1.htm	user_type=Customer
2	http://www.dot.com/page1.htm	user_type=Internal
3	http://www.dot.com/page1.htm	user_type=Promotional
4	http://www.dot.com/page1.htm	No cookie

For those URLs that use HTTP request headers, you set cacheability rules that specify the HTTP request header whose values to use for disambiguation. HTTP request headers enable Web browsers to pass additional information about the request and about themselves. Oracle Web Cache uses the header to serve the appropriate version of the URL to browsers.

Table 2-2 lists the standard HTTP request headers supported.

Table 2-2 HTTP Request Headers

Header	Description
Accept	Specifies which media types are acceptable for the response Example: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Charset	Specifies which characters sets are acceptable for the response Example: Accept-Charset: iso-8859-1,*,utf-8
Accept-Encoding	Restricts the content-encodings that are acceptable in the response Example: Accept-Encoding: gzip
Accept-Language	Specifies the set of languages that are preferred as a response Example: Accept-Language: en
User-Agent	Contains information about the Web browser that initiated the request Example: User-Agent: Mozilla/4.61 [en] (WinNT; U)

Note: Oracle Web Cache does not interpret the values of these HTTP request headers. If the values for two pages are different, Oracle Web Cache caches both pages separately. For example, if one request sends a HTTP request header of User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) and another request sends a HTTP request header of User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) for a different versions of Internet Explorer, Oracle Web Cache serves two pages for the two requests.

Personalized Attributes

Many Web sites support pages with personalized attributes, such as personalized greetings in the form of "Welcome <your name>", icons, addresses, or shopping cart snippets, on an otherwise generic page. You can configure the page with the personalized attributed information contained within HTML tags <!-- WEBCACHETAG> and<!-- WEBCACHEEND--> that Oracle Web Cache can parse. The personalized attribute information can be included within any valid HTML segment that has beginning (<tag>) and ending (</tag>) HTML tags.

Oracle Web Cache reads these tags and caches the instructions for substituting values for personalized attributes based on the information contained within a cookie or an embedded URL parameter.

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

Figure 2-3 shows two users, Jane Doe and John Doe, accessing the same page, http://store.oracle.com/cec/cstage?eccookie=&ecaction=ecpassthru2&template=walkin1.en.htm. This page contains a personalized greeting suited for the user. The HTML code for the personalized greeting Jane Doe uses the following HTML code:

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

The HTML code for personalized greeting John Doe uses the following HTML code:

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

person01 represents the session name assigned to the person_name cookie that Jane and John pass to Oracle 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 Oracle Web Cache receives the cookie information from Jane and John, it maps the person_name cookie to the person01 session name and substitutes the cookie value.

If, instead of cookies, the page supported embedded URL parameters, then the URL would contain the person_name parameter. For example, the page for Jane Doe could be http://store.oracle.com/cec/cstage?person_name=Jane+Doe and the page for John Doe could be http://store.oracle.com/cec/cstage?person_name=John+Doe. Oracle Web Cache is configured with the person_name01 session, which maps to the person_name embedded URL parameter. Oracle Web Cache uses the value of the embedded parameter to substitute the appropriate name.

Figure 2-3 Page with a Personalized Attribute

Text description of the illustration concept2.gif

If a request does not contain the cookie or embedded URL parameter, Oracle Web Cache substitutes the personalized attribute with an empty string. If you want to instead always require value of the personalized attribute, then set a session-related caching rule and require that the request get the cookie or embedded URL parameter settings from the application Web server.

See Also: "Configuring Rules for Personalized Pages"

Session Information

Some Web sites keep track of user sessions by assigning each user a unique session ID. Session IDs are typically used for Web sites with catalog pages. The session ID can be used for either session tracking or session-encoded URLs.

When a user first accesses a Web site that uses session IDs, Oracle Web Cache passes the request to the application Web server to establish the session. In turn, the application Web server assigns the user with a session ID through a cookie (sometimes referred to as a session cookie) or an embedded in the URL as a parameter. As users request pages and <A HREF=...> HTML links that use these session cookies or embedded URL parameters, application Web server track the sessions. You can configure Oracle Web Cache to serve pages that support session tracking and session-encoded URLs.

Session Tracking

Because session tracking does not alter the actual content of a page, you can configure Oracle Web Cache to cache the page and serve it to multiple users.

If you configure Oracle Web Cache to cache a page that uses session information and a subsequent request for the page contains a session cookie or embedded URL parameter, then Oracle Web Cache serves the page with the user's session information from its cache.

To better understand how session tracking works, consider the HTML pages shown in Figure 2-3. When Jane Doe and John first access the Oracle Store Web site, their initial requests are sent to the application Web server, which assigns them cookie name value pairs of session_ID=33436 and session_ID=33437, respectively. If their browsers did not support cookies, then the URL for the pages could contain the session ID. For example, the page for Jane Doe would be http://store.oracle.com/cec/cstage?session_ID=33436 and the page for John Doe could be http://store.oracle.com/cec/cstage?session_ID=33437. Oracle Web Cache can be configured to cache one version of this page and other session tracking pages and serve it to multiple users. By using the value of the session_ID cookie or embedded URL parameter, Oracle Web Cache can serve the same page to both Jane Doe and John Doe.

Unlike category cookies used for multiple versions of the same URL, Oracle Web Cache ignores the values of session cookies. The response from the application Web server is cached, even if the response session cookie value does not match the request session cookie value. If you do not want the response cached when there is a value mismatch, then modify the application to instead send a non-200 status code as the response.

See Also: "Configuring Rules for Pages with Session Tracking"

Session-Encoded URLs

You can configure Oracle Web Cache to cache the instructions for substituting session information for one user with another based on the session information contained within a cookie or an embedded URL parameter.

Continuing with the example in "Session Tracking", assume that Jane Doe and John Doe are again assigned cookies or embedded URL parameters of session_ID=33436 and session_ID=33437 by the application Web server. The page shown in Figure 2-4 has several <A HREF=...> links that include the session_ID cookie or parameter. The Release 3 (8.1.7) under the Oracle8i Documentation heading for Jane Doe uses the following HTML code:

<A HREF="/cec/cstage?ecaction=ecproditemlistbysupersect&
ecsid=20330&eccookie=&template=decsectview_pub.en.htm&session_ID=334326">Release 3 (8.1.7)</A>

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

<A HREF="/cec/cstage?ecaction=ecproditemlistbysupersect&
ecsid=20330&eccookie=&template=decsectview_pub.en.htm&session_ID=334327">Release 3 (8.1.7)</A>

By using the value of the session_ID cookie or embedded URL parameter, Oracle Web Cache is able to substitute the correct session information for Jane Doe and John Doe.

Figure 2-4 Session-Encoded URLs

Text description of the illustration session.gif

Whereas a session tracking page requires that each user establish a session with the application Web server, a page with session-encoded URLs requires that only the initial request to establish a session. Once the cache is populated with the page, other requests are served from the cache, regardless if the request has a session cookie or embedded URL parameter. This has twofold effect for those requests without the session cookie or embedded URL parameter:

• Oracle Web Cache substitutes the session information in the <A HREF=...> links with an empty string

• Session establishment for the user by the application Web server is delayed until there is a cache miss

If you want to instead require session establishment, then set a session-related caching rule.

See Also: "Configuring Rules for Personalized Pages"