Oracle Web Cache Administration and Deployment Guide Release 1.0.2.3 Part Number A86722-03 |
|
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:
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.
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:
Together, these factors provide Oracle Web Cache with a logical queue of content to update from the application Web servers.
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.
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:
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:
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
.
You can configure Oracle Web Cache to recognize and cache multiple-version pages by using the:
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.
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
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.
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.
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.
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.
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&
session_ID=334326
ecsid=20330&eccookie=&template=decsectview_pub.en.htm&">Release 3 (8.1.7)</A>
The same link for John Doe uses the following HTML code:
<A HREF="/cec/cstage?ecaction=ecproditemlistbysupersect&
session_ID=334327
ecsid=20330&eccookie=&template=decsectview_pub.en.htm&">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.
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:
<A HREF=...>
links with an empty string
If you want to instead require session establishment, then set a session-related caching rule.
|
![]() Copyright © 1996-2001 Oracle Corporation. All Rights Reserved. |
|