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

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.

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

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.

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:

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 increases. 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 concept4.gif follows

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

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

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 concepta.gif follows

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, you set cacheability rules that specify the cookie name and whether to cache versions of the URL that do not use the cookie. Oracle Web Cache then uses the value of the cookie to serve the appropriate version of the URL to browsers.

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

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>", on an otherwise generic page. You can configure the page with the personalized attributed information with a HTML tag called

that Oracle Web Cache can parse. Oracle Web Cache reads this tag and is able to cache 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. All subsequent requests for the page will result in a cache hit from Oracle Web 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 concept3.gif follows

Text description of the illustration concept3.gif

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.

In session tracking, session information is passed back and forth between a Web browser and an application Web server. The session information is contained within a cookie or embedded in the URL as a parameter.

In session-encoded URLs, session information is embedded in <A HREF=...> HTML links.

Session Tracking

Because session tracking does not alter the actual content of pages, you can configure Oracle Web Cache to serve the same page to multiple users.

When a user first accesses a Web site, 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.

If Oracle Web Cache is configured to cache pages that use session information and a subsequent request for a page contains a session ID, then Oracle Web Cache serves the page from its cache.

Consider the HTML pages shown Figure 2-3 . When Jane Doe and John log in, they are assigned session IDs of 33436 and 33437, respectively. As they access pages for the Oracle Store site, they send cookie name value pairs of session_ID=33436 and session_ID=33437. 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.

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.

Figure 2-4 shows a page with several links. All the links for user Jane Doe have a session ID of 334326. The links for John Doe have a session ID of 334327. The Release 2 (8.1.6) under Oracle8i Documentation for Jane Doe uses the following HTML code:

<A HREF="/cec/cstage?ecaction=ecproditemlistbysupersect& ecsid=20330&eccookie=&template=decsectview_pub.en.htm&sessionID=334326">Release 2 (8.1.6)</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&sessionID=334327">Release 2 (8.1.6)</A>

Figure 2-4 Session-Encoded URLs

Text description of session.gif follows.

Text description of the illustration session.gif

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.

2 Oracle Web Cache Concepts