|
Oracle® Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) Part No. B14046-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) Part No. B14046-01 |
|
|
Previous |
Next |
This chapter explains how OracleAS Web Cache is populated with content, how that content maintains consistency, and how dynamically generated content is assembled and cached.
This chapter contains these topics:
Caching rules determine which objects are cached. When a caching rule for a particular URL is first established, those objects contained within the URL are not cached until there is a browser request for them. When an object is first requested, OracleAS Web Cache appends a Surrogate-Capability request-header field to the object. The Surrogate-Capability request-header field identifies that the object passed through the cache. OracleAS Web Cache then sends the request to the origin server. This is a cache miss. If the requested object is specified as one of the objects to cache, then OracleAS Web Cache caches the object for subsequent requests. When the object is subsequently requested, OracleAS Web Cache serves the object from its cache to the browser. This is a cache hit.
You configure a caching rule by specifying caching attributes based on the URL with Oracle Enterprise Manager 10g Application Server Control Console or OracleAS Web Cache Manager, or you configure the caching attributes for a specific object within a Surrogate-Control response-header field. OracleAS Web Cache uses the following priority to determine object cacheability:
Caching rule configured with Application Server Control Console or OracleAS Web Cache Manager
Other HTTP headers:
If any of these headers are present, then OracleAS Web Cache does not cache the object.
Cookie values from Cookie request header and Set-Cookie response header
The Surrogate-Control response-header field enables the origin server to override the caching rules configured through Application Server Control Console or OracleAS Web Cache Manager. When both a Surrogate-Control response header and a caching rule for the same object are present, OracleAS Web Cache merges the two. For example, if there a caching rule for an non-cacheable object set in Application Server Control Console or OracleAS Web Cache Manager with compression enabled, and the response header contains Surrogate-Control: max-age=30+60, then OracleAS Web Cache respects both settings. OracleAS Web Cache uses the max-age control directive from the Surrogate-Control response-header to cache the object and the compression setting from the caching rule. If there is a conflict between the Surrogate-Control response header and a caching rule, then OracleAS Web Cache uses the settings from the Surrogate-Control response header.
|
Notes:
|
When the first browser request for a multi-part object with an HTTP Range request-header field comes in, OracleAS Web Cache sends the request to the origin server. OracleAS Web Cache serves the entire object received from the origin server response to the browser, and OracleAS Web Cache caches the entire object for the request. For a subsequent request for the object, OracleAS Web Cache serves only the part requested from the browser.
Consistency and performance are crucial for the reliability of OracleAS Web Cache. The following features ensure consistency between the cache and origin servers:
Invalidation is intended for frequently changing content. With invalidation, objects are marked as invalid. When objects are marked as invalid and a browser 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.
Propagation of invalidation messages from one OracleAS Web Cache server to another occurs in the following deployments:
Cache hierarchy whereby one OracleAS Web Cache server acts as an origin server to another OracleAS Web Cache server
Cache cluster with multiple OracleAS Web Cache servers
In a configuration with a hierarchy of OracleAS Web Cache servers, it is likely that content will be cached on multiple servers.
Figure 2-1 depicts a distributed cache hierarchy. A central cache is located in the United States office, and a remote cache is located in the Japan office. While the central cache stores content from an application Web server, the remote cache stores content from the central cache. In other words, the central cache acts as an origin server to the remote cache in Japan.
When an invalidation message is sent to the central cache to refresh content, the central cache automatically propagates the invalidation message to the remote cache in Japan to ensure consistency.
Figure 2-1 Scenario 1: Invalidating Content in a Distributed Cache Hierarchy
Figure 2-2 depicts an ESI cache hierarchy. A subscriber cache performs Edge Side Includes (ESI) assembly. Provider caches locally cache ESI fragments for ESI provider sites www.providersite1.com and www.providersite2.com. During ESI page assembly, the subscriber cache contacts the provider caches for the ESI fragments.
Figure 2-2 Scenario 2: Invalidating Content in an ESI Cache Hierarchy
When an invalidation message is sent to a central or provider cache to refresh content, the central or provider cache automatically propagates the invalidation message to the remote or subscriber cache to ensure consistency.
To ensure that the central or provider cache only invalidates its content, the remote or subscriber cache checks the site host name specified in the invalidation message with the IP address of the provider cache from which the invalidation message propagated. If there is a match, the remote or subscriber cache processes the invalidation request. Otherwise, the request is rejected. For distributed cache hierarchies, the site host name for the central and remote caches should be configured to be identical, making a mismatch unlikely.
|
See Also:
|
In a cache cluster, administrators can decide whether to propagate invalidation messages to all cache cluster members or to send invalidation messages individually to cache cluster members.
When OracleAS Web Cache propagates invalidation messages, the cache that received the invalidation request acts as the invalidation coordinator for that request. The coordinator propagates the invalidation messages to the other cluster members. The coordinator waits for responses from all cluster members. When the propagation completes, the coordinator returns a message to the sender that lists, for each cluster member, the cluster member name, the status of the invalidation request, and the number of objects invalidated.
If any cluster member cannot be reached, OracleAS Web Cache returns an error message and does not propagate the invalidation messages.
During a cache cluster upgrade, you upgrade one cache cluster member at a time. The caches will continue to respond to requests. However, because other cluster members have a different version of the configuration, the caches will not forward invalidation messages to those cache cluster members operating with a different version. Instead, if the requested object is not cached by that cache or by cluster members with the same version of the configuration, OracleAS Web Cache forwards the request to the origin server.
When the cache cluster members are not running the same version of OracleAS Web Cache, you can still invalidate objects, and you can propagate the invalidation to other cluster members, but the invalidation message must originate with the cache that is operating with the earlier version of OracleAS Web Cache.
|
See Also:
|
With expiration, objects are marked as invalid after a certain amount of time in the cache. Expirations are useful if it can be accurately predicated 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.
|
See Also: "Configuring Caching Rules and Rule Association" and "Configuring Expiration Policies" for instructions on creating expiration policies |
OracleAS Web Cache uses HTTP/1.1 validation models to determine how to best serve a response to browsers. 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 following validators for cache hits:
When a browser sends a GET method request with an HTTP If-Modified-Since request-header field for an object, OracleAS Web Cache compares the time stamp used in the header with the Last-Modified response-header field of the cached object to determine if the object can be served. If the cached object is more current than the one requested by the browser, then OracleAS Web Cache serves the full content of the object to the browser. When the Last-Modified header does not exist, OracleAS Web Cache uses the time the object entered the cache as the time stamp. If the cached object is less current than the one requested by the browser, then OracleAS Web Cache sends an HTTP 304 Not Modified status code to the browser.
If-None-Match Validator
When a browser sends a GET method request with an HTTP If-None-Match request-header field for an object, OracleAS Web Cache compares the entity tag used in the request header with the ETag response-header field of the cached object to determine if the object is current. If the values match, then OracleAS Web Cache sends an HTTP 304 Not Modified status code to the browser. If the values do not match or if there is no If-None-Match request-header, then OracleAS Web Cache returns an HTTP 200 OK status code to the browser and serves the full content of the object.
If an expired or invalid object contains an ETag response-header field, then OracleAS Web Cache first checks with the origin server to see if the object has changed since it was last refreshed. If the object is still valid, then the origin server sends an HTTP 304 Not Modified status code to OracleAS Web Cache and the object is not refreshed. If the object is no longer valid, then the origin server returns a full response HTTP 200 OK status code to OracleAS Web Cache. After the object is refreshed, OracleAS Web Cache checks the ETag value of the original request to determine the response status.
For non-cacheable objects, OracleAS Web Cache passes the If-Modified-Since and If-None-Match request headers to the origin server. In turn, the origin server responds with either an HTTP 304 Not Modified or HTTP 200 OK status code. For non-cacheable misses, OracleAS Web Cache removes these request headers before passing the requests to the origin server. After an object is cached, OracleAS Web Cache applies either the time comparison of If-Modified-Since or the entity tag match with ETag, as previously described.
|
Note: OracleAS Web Cache does not support weak validators for theIf-None-Match validator. OracleAS Web Cache supports all other If-None-Match request-header field formatting.
|
|
See Also:
|
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 browsers. 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 is based on the expiration time, invalidation time, and removal time of an object.
OracleAS Web Cache calculates validity by comparing the current time relative to an object's expiration or invalidation time and the object's scheduled removal time. Prior to expiration or invalidation time, the object is considered valid. Between expiration or invalidation time and removal time, the object's validity level decreases linearly. During this interim state, objects with a higher validity level have a higher propensity to be served stale. When current time reaches removal time, the object is considered totally invalid and can no longer be served stale. Administrators can control scheduled removal time. When expiring or invalidating content, administrators have the option to remove objects immediately, which may be necessary for sensitive objects that should never be served stale. Likewise, where some degree of inconsistency is tolerable, administrators can specify a removal time in the near future.
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.
Figure 2-3 illustrates how performance assurance heuristics are used during widespread invalidation. Immediately after invalidation, the number of fresh objects served decreases to 20 objects for each second. However, the number of fresh cache hits quickly increases to 5,000 objects for each second over a short period of time. This is because OracleAS Web Cache refreshes the most popular objects first so that these objects have little chance of being served stale. After the popular objects are refreshed, the less popular objects are refreshed. The total number of objects that can be revalidated in a given period of time is dependent on origin server capacity. At the end of invalidation, only fresh content is served.
|
Note: Performance assurance heuristics do not apply to objects configured to be removed and refreshed immediately. |
Most Web pages today are dynamically generated before delivery to the browser. Web developers frequently use technologies like JavaServer Pages (JSP), Active Server Pages (ASP), PERL, PL/SQL Server Pages (PSP), servlets, PHP Hypertext Preprocessor (PHP), and Common Gateway Interface (CGI) to design their applications. 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 application data is added and removed
Because of invalidation, OracleAS Web Cache knows which objects are valid and which objects are invalid. This is especially important for dynamically generated content that changes frequently.
Most traditional 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 products and services to know when content has changed. OracleAS Web Cache, on the other hand, supports several mechanisms for receiving invalidation messages from the origin server containing the original content.
For dynamically generated pages, browsers pass information about themselves to the origin server, enabling the origin server to serve appropriate content to the browser.
The HTTP protocol has a way for browsers and origin servers to share information, such as session information, in message headers that browsers pass with every request to the origin server. This message header can contain a Set-Cookie request-header field that specifies a cookie and its value:
Set-Cookie:cookie_name=value
Cookies are stored on the browser's file system and are often used for identifying users who revisit Web sites. Browsers send a request with a Cookie request-header field with the cookie name and value that was received in the last response:
Cookie:cookie=value
Many users choose to disable cookies in their browsers because of privacy concerns. For this reason, applications often embed parameter information in the URL or POST body. OracleAS Web Cache accepts requests that use the following characters as delimiters for an embedded URL parameter, or POST body parameter: question mark (?), ampersand (&), dollar sign ($), or semi-colon (;).
|
Note: TheSet-Cookie response header field is not cached.
|
OracleAS Web Cache recognizes cookies, embedded URL parameters, and POST body parameters, enabling you to configure caching rules for objects with the following characteristics:
Some pages have multiple versions, enabling categorization. Figure 2-4 shows the same object, https://oraclestore.oracle.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=293017§ion=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.
You can configure OracleAS Web Cache to recognize and cache multiple-version pages by using the:
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 browser sends an initial request for a multiple-version object, OracleAS Web Cache passes the request to the origin server. In turn, the origin server includes a Set-Cookie response-header in the response with the category cookie and its value:
Set-Cookie:cookie=value
Upon receiving the Set-Cookie response-header field, the browser stores the cookie in memory. With its next request to the same origin server, the browser 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 browser's request to serve the appropriate version of the object to the browser.
|
Note: OracleAS Web Cache does not cache theSet-Cookie response header field.
|
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 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.
Table 2-1 Multiple-Version Object 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 objects that have different versions based on HTTP request headers, configure caching rules that specify the HTTP request header. HTTP request headers enable Web browsers 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 browsers.
OracleAS Web Cache supports all valid HTTP request headers. Table 2-2 lists the HTTP request-header fields supported by the OracleAS Web Cache Manager interface, 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".
Table 2-2 HTTP Request-Header Field
|
Note: By default, OracleAS Web Cache does not interpret the values of these HTTP request headers. If the values for two pages are different, OracleAS Web Cache caches both pages separately.This issue is especially problematic with the You can override this behavior for the |
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.
|
Note: To achieve personalization within an HTML tag, use ESI, as described in "Using ESI for Simple Personalization". |
Figure 2-5 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.
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:
Configure a personalized attribute definition with the personalized attribute cookie, embedded URL parameter, or POST body parameter.
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.
|
Note: You can also substitute session values between the<!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> tags:
See Also: "Configuring Rules for Popular Pages with Session Establishment" |
You can specify how OracleAS Web Cache serves requests with the existence or nonexistence of personalized-attribute cookies, embedded URL parameters, or POST body parameters. You can choose to:
Serve or not serve cached objects to requests that have the cookie, embedded URL parameter, or POST body parameter
Serve or not serve cached objects to requests that do not have the cookie, embedded URL parameter, or POST body parameter
For example, if you want to require that the request get the cookie or parameter settings from the origin server, then choose to serve cached objects to requests that have the cookie or parameter, but do not serve cached objects to requests that do not have the personalized attribute cookie or parameter.
When you choose to serve for both, you can then specify if requests with or without the cookie or parameter can share the same cached object. OracleAS Web Cache uses a default string for those requests without the cookie or parameter.
To specify how personalized attribute pages are served by OracleAS Web Cache:
Configure a personalized attribute definition that specifies the name of the cookie, embedded URL parameter, or POST body parameter.
Specify the behavior for caching objects with or without personalized attribute information by defining a personalized attribute-related caching rule.
Associate URLs with the personalized attribute-related caching rule.
Some Web sites keep track of user sessions by assigning each user a unique session ID. When a browser 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:
Set-Cookie:cookie=value
Upon receiving the Set-Cookie response-header field, the browser stores the cookie in memory. With its next request to the same origin server, the browser includes the Cookie request-header field with the cookie name and value that was received in the last response:
Cookie:cookie=value
Because of the Cookie request-header field, the origin server determines that the browser already has a session and uses the value of the session to keep track of the browser state.
When returning a response to a request that already has a session, the origin server may or may not send a Set-Cookie header. If it does send it, it may or may not change the session cookie value. Origin servers really only need to send this response-header field to establish new cookies or change the value of the cookies.
Alternatively, origin servers can track a session with the browser by including the session value in an embedded URL or POST body parameter. With its next request to the same origin server, the browser includes the embedded URL or POST body parameter. Because of the embedded URL or POST body parameter, the origin server determines that the browser 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:
By default, OracleAS Web Cache distinguishes origin server responses by the request URLs. However, if the request contains an embedded URL or POST body parameter, the request URL to the same page content is distinct for each session. Therefore, OracleAS Web Cache caches responses for each of the distinct URLs. This can result in low cache hit rates and redundantly cached objects.
By configuring OracleAS Web Cache to ignore the value of embedded URL or POST body parameters, you enable OracleAS Web Cache to serve one cached object to multiple sessions requesting the same page. OracleAS Web Cache caches the response to the first request and serves subsequent requests for the page from its cache.
Consider user Jane Doe accessing a page with a request URL of:
https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103&session_ID=33436
User John Doe accesses the same page with a request URL of:
https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103&session_ID=33437
In addition, this page contains the following POST body for Jane Doe and John Doe, respectively:
section=1013 &session_ID=3346 section=1013 &session_ID=3347
The only distinct part to the request URL and the POST body is the value of the session_ID parameter. Rather than caching and serving two versions of the same object, you can configure OracleAS Web Cache to ignore the value of session_ID so that one cached object can be served to both users.
To configure parameters to ignore:
Establish global parameters.
Specify site-specific parameters overrides.
When creating a caching rule, specify either global or site-specific parameters.
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 theSet-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-6 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.
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:
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.
Configure a caching rule with Session-Encoded URL enabled. Only requests matching the caching rule will perform the substitution.
You can specify how OracleAS Web Cache serves requests with the existence or nonexistence of session cookies, embedded URL parameters, or POST body parameters. You can choose to:
Serve or not serve cached objects to requests that have a session cookie, embedded URL parameter, or POST body parameter
Serve or not serve cached objects to requests that do not have a session cookie, embedded URL parameter, or POST body parameter
For example, if you want the first request of a new user to establish a session from the origin server, then choose to serve cached objects to requests that have the session cookie or parameter, but do not serve cached objects to requests that do not have the session cookie or parameter.
When you choose to serve for both, you can then specify if requests with or without the session cookie or parameter can share the same cached object. OracleAS Web Cache uses a default string for those requests without the cookie or parameter.
To specify how session-related pages are served by OracleAS Web Cache:
Configure a session definition that specifies the name of the session cookie, embedded URL parameter, or POST body parameter.
Specify the behavior for caching objects with or without session information by defining a session-caching policy.
Associate URLs with the session-caching policy.
|
See Also:
|
OracleAS Web Cache provides dynamic assembly of Web pages with both cacheable and non-cacheable page fragments. It provides for assembly by enabling Web pages to be divided into fragments of differing caching profiles. These fragments are maintained as separate elements in the cache. The fragments are assembled into HTML pages as appropriate when requested by end users.
By enabling dynamic assembly of Web pages on OracleAS Web Cache rather than on the origin servers, you can choose to cache some of the fragments of assembled pages. With partial page caching, much more HTML content can be cached, and then assembled and delivered by OracleAS Web Cache when requested. Furthermore, page assembly can be conditional, based on information provided in HTTP request headers or end-user cookies.
The section contains the following topics:
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-7, 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.
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.
Table 2-3 Summary of ESI Tags
| Tag | Description |
|---|---|
<esi:choose>
|
Performs conditional processing based on Boolean expressions |
<esi:comment>
|
Specifies comments not be included in the output |
<esi:environment>
|
Allows variable access from an HTTP response |
<esi:include>
|
Includes an HTML fragment |
<esi:inline>
|
Marks a fragment as a separately cacheable fragment, embedded in the HTTP response of another object |
<esi:invalidate>
|
Specifies an invalidation request within the response of a browser page |
<esi:remove>
|
Specifies non-ESI markup if ESI processing is not enabled |
<esi:try>
|
Specifies alternate processing when a request fails because the origin server is not accessible |
<esi:vars>
|
Permits variable substitution for environment variables |
Example 2-1 shows the ESI markup language for the template page shown in Figure 2-7.
Example 2-1 ESI Markup
<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.
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.
Most existing applications are only designed to output an entire Web page to HTTP requests. These fragments and templates are non-fetchable, meaning they are not to be fetched independently from the origin server. If a cache needs any of these fragments or templates, the corresponding full Web page must be requested. To use ESI page assembly for non-fetchable fragments, an application can output the full page response just as it does normally, with the exception that at the beginning and the end of each fragment, an <esi:inline> tag is inserted with a fragment name to demarcate the fragment. OracleAS Web Cache stores the enclosed portions as separate fragments and the original page as a page template without the enclosed fragments. Fragments are shared among templates if their names are identical and they are from the same site.
Example 2-3 shows a simple <esi:inline> example. The HTML table enclosed by the <esi:inline> tag is the fragment content. The area preceding <esi:inline name="/news101"> and the area following </esi:inline> form the page template. If another page contains an <esi:inline> tag with the same name "/news101", the two fragments logically share the same content.
Example 2-3 Inline Non-Fetchable Example
<HTML> ... <esi:inline name="/news101"> <TABLE> ... </TABLE> </esi:inline> ... </HTML>
When an application uses non-fetchable <esi:inline> fragments, the full page must be requested for every cache miss. At first, it can appear that there is no apparent cache benefit for cache misses. However, non-fetchable <esi:inline> fragments improves overall caching by:
Increasing the cache hit ratio
Because shared fragments can be extracted into separate fragments, the size of the dynamic portion is reduced. A reduced space requirement results in a higher cache hit ratio than full page caching.
Reducing cache update frequency
Dynamic shared fragments require only one update. For example, a shared stock market fragment may expire much more frequently than any other parts of the page. With <esi:inline> fragmentation, only one cache update of any full page containing this fragment is enough to bring all full pages sharing this fragment current. Therefore, even non-fetchable <esi:inline> fragments can significantly reduce cache update frequency. The cost reduction is proportional to the degree of sharing.
To invalidate non-fetchable fragments, you must invalidate both the template object and the non-fetchable fragments to ensure the fragments are invalidated.
<esi:inline> fragments are by default non-fetchable. If an application supports independently fetchable fragments, it is possible to use the <esi:inline> for fetchable fragments by setting the fetchable attribute to yes.
Example 2-4 shows an <esi:inline> example with a fetchable fragment named /news101. A request for the page returns the template page and the fetchable fragment.
Example 2-4 Inline Fetchable Example
<HTML> ... <esi:inline name="/news101" fetchable="yes"> <TABLE> ... </TABLE> </esi:inline> ... </HTML>
The <esi:include> tag is another way to define fragments and templates in an HTTP output for dynamic content caching and assembly. It is in many ways similar to the <esi:inline> tag. It defines a name for the defined fragment. The page including an <esi:include> tag is a template that references the defined fragment. However, it also has some key differences which make its applicable scenarios very different from those of <esi:inline>:
An <esi:include> tag in a template only defines the reference to a fragment.
It does not enclose an embedded fragment directly in the template. As a result, a template with <esi:include> tags can be applied to multiple users. In contrast, a template with embedded <esi:inline> tags must be unique to each user.
A fragment referenced by an <esi:include> tag must always be independently fetchable by HTTP or HTTPS.
The requested URL is the same as the fragment name. In contrast, an <esi:inline> tag's name only identifies the uniqueness of the fragment and is not used to fetch the actual content. The attribute defining the fragment name in <esi:include> fragment is src instead of name.
There are at least two scenarios where using <esi:include> tags is beneficial:
Some applications, such as a Web portal, naturally assemble content from external sources. The application only provides a template that is used to fetch various fragments from third-party sources. In this case, the <esi:include> tags fetch and assemble directly, reducing one layer of redundancy.
Some applications offer faster responses for template-only requests than full-page requests that use <esi:inline> tags. If <esi:include> is used for page fragmentation and assembly, OracleAS Web Cache can miss only on the templates when most or all fragments are already cached, saving effective cache miss cost. In many cases, it is also valuable to cache the personalized templates because these seldom change.
Example 2-1 shows ESI markup with <esi:include> tags.
Although both <esi:include> and <esi:inline> enable OracleAS Web Cache to fetch objects to fetch fragments directly to the browser, <esi:include> is more robust for performing this task and provides an easy way in which to manage fragments. Because <esi:include> affects the application flow, it is best to incorporate <esi:include> early in the design phase of an application. For an existing application, <esi:inline> is better mechanism because it requires minimal change to your application.
When OracleAS Web Cache receives a browser 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.
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 browser 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:
|
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:
OracleAS Web Cache receives a request for a template page.
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.
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.
|
See Also:
|
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.
|
See Also: http://www.oracle.com/technology/products/ias/web_cache/index.html for further information about the ESI Servlet Filter
|
OracleAS Web Cache provides support for the following HTTP request and response-header fields:
The Oracle-ECID request header is used to track requests as they move through the Oracle Application Server architecture. This information is especially useful for diagnostic purposes. Because OracleAS Web Cache is the initial receiver of browser requests, it sets the request header before forwarding a cache miss to an origin server. The Oracle-ECID request header takes the following format:
Oracle-ECID: request_id, sequence_number
In the format, request_id is a 64-bit unique integer for the request, and sequence_number is the hop number of the request as it passes through Oracle Application Server. OracleAS Web Cache typically assigns an initial sequence number of 0 to a request. As a request passes from OracleAS Web Cache to other Oracle Application Server components, the request ID remains constant, but the sequence number increments with each hop.
You can configure OracleAS Web Cache to log the request ID and sequence number from the Oracle-ECID request header in the event and access logs. To display the Oracle-ECID request header in the logs, you enable Include Request Details for the event log, and select the x-ecid field for the access logs. The x-ecid field is provided by default with the Enhanced CLF (ECLF), Enhanced Combined Log Format, and End-User Performance Monitoring Format. Additionally, you can configure Oracle HTTP Server to log the Oracle-ECID request header information, enabling you to correlate events at different Oracle Application Server stops for the same request.
OracleAS Web Cache also includes Oracle-ECID request header information whenever you configure to display diagnostic information in the Server response-header field or the HTML response body.
|
See Also:
|
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
The Surrogate-Capability request-header enables OracleAS Web Cache to identify the operations it is capable of performing to origin servers acting as caches. The Surrogate-Capability request-header field supports the following syntax:
Surrogate-Capability: orcl="operation_value operation_value ..."
where "operation_value" is one or more of the following:
"ORAESI/9.0.4" to process ESI tags with Oracle-proprietary additions for content assembly and partial page caching. "ORAESI/9.0.4" supports all the ESI tags provided by OracleAS Web Cache in 10g (9.0.4) and later releases.
"ORAESI/9.0.2" to process ESI tags with Oracle proprietary additions for content assembly and partial page caching. "ORAESI/9.0.2" supports all the ESI tags provided by OracleAS Web Cache in Release 2 (9.0.2 and 9.0.3).
"ESI/1.0" to process standard ESI tags for content assembly and partial page caching
"webcache/1.0" to process the <!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> tags for personalized attributes
The values "ORAESI/9.0.2", "ESI/1.0", and "ESI-Inline/1.0" are subsets of "ORAESI/9.0.4". For this release, you specify only "ORAESI/9.0.4" for ESI assembly, "ESI-INV/1.0" for inline invalidation, or "webcache/1.0" for personalized attributes.
For objects sent to browsers, OracleAS Web Cache adds diagnostic information to the Server response-header field of the HTTP response message:
Server: Oracle Application Server-10g/version Server_header_from_origin_server OracleAS Web Cache/10g (10.1.2) (diagnostic_information)
The Server response-header field specifies name/value pairs for Oracle HTTP Server and OracleAS Web Cache. The information for OracleAS Web Cache includes version and diagnostic information.
diagnostic_information has the following format:
{ESI_processing_type}{cache_request_type}[;max-age=expiration_time[+removal_time];age=object_age;]{ecid=request_ID,sequence_number}
Table 2-4 describes the diagnostic fields.
Table 2-4 Control Directives for Server
| Control Directive | Description |
|---|---|
ESI_processing_type
|
ESI_processing_type can be one of the following:
|
cache_request_type
|
cache_request_type can be one of the following:
|
max-age="expiration_time[+removal_time]
|
Specifies the time, in seconds, to expire the object, and optionally, the time, in seconds, to remove the object from the cache after the expiration time. max_age does not appear if the cache_request_type is N.
|
age=object_age
|
Shows how long, in seconds, the object has been in the cache. age does not appear if the object is non-cacheable
|
ecid=request_ID, sequence_number
|
Specifies the request ID and sequence number specified in Oracle-ECID request header:
See Also: "Oracle-ECID Request-Header Field" |
Using the Server response header information, you can determine whether a request was served from the cache or the application Web server. In the following example, the Server field specifies that the object was a cache hit:
Server: Oracle-Application-Server 10g/10.1.2 Oracle-HTTP-Server OracleAS-Web-Cache-10g/10.1.2.0.0 (TH;max-age=60+30;age=55;ecid=23248098121,0)
(TH;max-age=60+30;age=55;ecid=23248098121,0) is the diagnostic information.
T means this page is composed by ESI
H means this request resulted in cache hit
max-age=60+30 means that the object is to expire in 60 seconds from population and to be removed from the cache 30 seconds from the expiration. This provides a total of 90 seconds from population.
age=55 in age means that 55 seconds have passed since population of the cache, meaning there are 5 seconds to expiration and 35 seconds to removal
ecid=23248098121,0 specifies the request ID and sequence number from the Oracle-ECID request header.
To display the Server response header in the access logs, you select the sc(Server) field. You must configure the sc(Server) field as a user-defined access log format.
|
See Also:
|
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 the OracleAS Web Cache Manager interface.
|
See Also: "Cache Population" for a description of how OracleAS Web Cache determines when to use caching attributes from theSurrogate-Control and OracleAS Web Cache Manager
|
The Surrogate-Control response-header field supports the following syntax:
Surrogate-Control:[content=content_type, content_type,..] [no-store][no-store-remote][max-age=expiration_time[+removal_time]] [vary=headers(headerheader...)][coookie(cookie_namecookie_name...)] [compress=yes|no]
Table 2-5 describes the supported control directives.
Table 2-5 Control Directives for Surrogate-Control
| Control Directive | Description |
|---|---|
content
|
Specify what kind of processing is required:
See Also: Table 16-2 for further information about the ESI tags supported for each processing version |
no-store
|
Specify that OracleAS Web Cache not cache the object. |
no-store-remote
|
Specify to not allow other ESI-compliant caches, such as a third-party Content Delivery Network (CDN), to cache the object.
The This directive is especially useful if you want to cache changing content locally, where invalidation propagation is immediate, but not in a distributed network of upstream ESI processors, where invalidation may take several minutes. |
vary
|
Specify the HTTP request headers or cookies from which OracleAS Web Cache will use to cache and identify multiple-version objects. Use the following format:
Specify /f to instruct OracleAS Web Cache to only cache versions of the object based on the existence of the HTTP request headers or cookies. Exclude Usage notes:
|
compress
|
Specify yes for OracleAS Web Cache to serve compressed cacheable and non-cacheable objects to all browser types; specify no for OracleAS Web Cache to not serve compressed cacheable and non-cacheable objects to browsers.
This control directive does not enable you to specify browser types. If you specify yes and need to limit the browser types, specify a compression caching rule in OracleAS Web Cache Manager, as described in Step 11 of "Task 1: Create Caching Rules". Notes: Even if you enable compression, OracleAS Web Cache does not compress the following:
|
max-age
|
Specify that OracleAS Web Cache cache the object.
Specify the time, in seconds, to expire the object after it enters the cache. Optionally, specify the time, in seconds, to remove the object from the cache after the expiration time. Use the following format:
Usage notes:
|
Usage Notes
Control directives are case sensitive.
no-store and no-store-remote are mutually exclusive.
content="ORAESI/9.0.4", content="ESI-Inline/1.0", content="ESI-INV/1.0", content="ESI/1.0" are mutually exclusive with content="webcache/1.0"
|
See Also:
|
In the following example, the Surrogate-Control response-header field specifies that the object is to expire 30 seconds after it enters the cache and be removed 60 seconds after expiration. It also specifies that the object contains ESI tags that require processing:
Surrogate-Control: max-age=30+60, content="ORAESI/9.0.4"
In the following example, the Surrogate-Control response-header field specifies that the object is not to be cached:
Surrogate-Control: no-store
In the following example, the Surrogate-Control response-header field specifies ESI processing with the content control directive. The vary control directive specifies to cache versions of the multiple-version object, regardless of whether the request contains the HTTP Accept request header.
Surrogate-Control: content="ORAESI/9.0.4", vary=headers(Accept)
In the following similar example, the Surrogate-Control response-header field specifies ESI processing with the content control directive. The vary control directive specifies to cache versions of the multiple-version object only if the request contains the Accept and MyCustomHeader headers and news and sports cookies.
Surrogate-Control: content="ORAESI/9.0.4", vary=headers(Accept/f);cookies(news/f sports/f)
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.
The Surrogate-Key response-header field supports the following syntax:
Surrogate-Key: search-key=("key" "key" "key" ...)
Usage Notes
If search-key is specified in this header, then at least one search key value must be present.
Search key values must be enclosed within quotes (").
Search key values can be of any format, such as "key_value" or "key_name=key_value".
The maximum number of allowed search keys is defaulted to 20.
Multiple search key values are separated by quotes.
Space between search keys is optional.
The search keys must remain the same.
If search keys are replaced in a response, then OracleAS Web Cache assumes the search keys are the same.
The following examples show valid Surrogate-Key fields. The first example shows one search key of template_id=33,31345, and the second example shows search keys of template_id=33,31345 and category.
Surrogate-Key: search-key=( "template_id=33,31345" )
Surrogate-Key: search-key=("template_id=33,31345" "category")
The following examples show invalid Surrogate-Key fields. The first example shows one search key of 348 without an ending quote ("), and the second example shows search-key without any search key values.
Surrogate-Key: search-key=( "template_id=33,31345 ) Surrogate-Key: search-key=( )
