Oracle® Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) B14046-05 |
|
![]() Previous |
![]() Next |
This chapter explains how OracleAS Web Cache decides what content to store in the cache, how it maintains the consistency of that content, and how it assembles and caches dynamically generated content.
This chapter contains these topics:
How OracleAS Web Cache Can Cache Dynamically Generated Content
About Request and Response-Header Fields Important for Caching
How OracleAS Web Cache Processes Requests with a Range Request-Header Field
Caching rules determine which objects are cached. When you establish a caching rule for a particular URL, those objects contained within the URL are not cached until there is a client request for them. When a client first requests an object, OracleAS Web Cache sends the request to the origin server. This request is a cache miss. Because this URL has an associated caching rule, OracleAS Web Cache caches the object for subsequent requests. When OracleAS Web Cache receives a second request for the same object, OracleAS Web Cache serves the object from its cache to the client. This request is a cache hit.
When you stop OracleAS Web Cache, the cache clears all objects. In addition, OracleAS Web Cache clears resets statistics.
See Also: "About Caching Rules" for a description of how OracleAS Web Cache determines cache population through caching rules |
Consistency and performance are crucial for the reliability of OracleAS Web Cache. The following features ensure consistency between the cache and origin servers:
You use invalidation for frequently changing content. With invalidation, OracleAS Web Cache marks objects as invalid. When objects are marked as invalid and a client requests them, they are removed and then refreshed with new content from the origin servers. You can choose to remove and refresh invalid objects immediately, or base the removal and refresh on the current load of the origin servers.
See Also: "Propagation of Invalidation Messages" for further information about when invalidation messages are propagated from one OracleAS Web Cache server to another |
With expiration, OracleAS Web Cache marks objects as invalid after a certain amount of time in the cache. Expirations are useful if you can accurately predict when content will change on an origin server or database. To prevent objects from remaining in the cache indefinitely, Oracle recommends creating expiration policies for all cached objects.
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 clients. Validation works by the comparing two validators, one in the request header and the other in the cached object's response header, to determine if they represent the same or different entities. Specifically, OracleAS Web Cache uses the If-Modified-Since
and If-None-Match
for cache hits.
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 clients. For this reason, OracleAS Web Cache intelligently serves some of the objects stale until the origin servers have the capacity to refresh them.
OracleAS Web Cache provides minimal trade-off between performance and consistency through performance assurance heuristics that determine which objects can be served stale. These heuristics are based on a number of factors including:
Validity is based on the expiration time, invalidation time, and removal time of an object.
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.
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 client 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 processed successful bid
Search results, which can change as you add and remove application data
Because of invalidation, OracleAS Web Cache knows which objects are valid and which objects are invalid. Invalidation 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, clients 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 clients 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 client's file system and are often used for identifying users who revisit Web sites. Clients 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-1 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 client sends an initial request for a multiple-version object, OracleAS Web Cache passes the request to the origin server. In its response, the origin server includes a Set-Cookie
response-header with the category cookie and its value:
Set-Cookie:cookie=value
Upon receiving the Set-Cookie
response-header field, the client stores the cookie in memory. With its next request to the same origin server, the client includes the Cookie
request-header field with the category cookie name and value that was received in the last response:
Cookie:cookie=value
OracleAS Web Cache evaluates whether the cookie and its value set in the Set-Cookie
response-header matches the cookie and its value set in the Cookie
request-header. If the cookie and value match, then the response is cached. If cookie and its value do not match, then the response is not cached. After versions of the object are cached, OracleAS Web Cache uses the value of the cookie in the client's request to serve the appropriate version of the object to the client browser.
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 client requests that contain cookie values of Customer
, Internal
, and Promotional
. You can configure OracleAS Web Cache to recognize the user_type
cookie, enabling OracleAS Web Cache to cache three different objects. In addition, you can configure OracleAS Web Cache to cache a fourth object for those requests that do not use a cookie.
Table 2-1 Multiple-Version Object with Different Cookie Values
Version | URL | Cookie Name/Value |
---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
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 clients to pass additional information about the request and about themselves. OracleAS Web Cache uses the header to serve the appropriate version of the URL to clients.
OracleAS Web Cache supports all valid HTTP request headers. Table 2-2 lists the HTTP request-header fields supported by the Application Server Control Console and OracleAS Web Cache Manager interfaces, as described in "Configuring Caching Rules and Rule Association". You can specify other HTTP request-header fields with the Surrogate-Control
response-header field, as described in "Configuring Expiration Policies".
Table 2-2 HTTP Request-Header Field
Header Field | Description |
---|---|
Specifies which media types are acceptable for the response Example: |
|
Specifies which character sets are acceptable for the response Example: |
|
Restricts the content-encodings that are acceptable in the response Example: |
|
Specifies the set of languages that are preferred as a response Example: |
|
Contains information about the client that initiated the request Example: |
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-2 shows two users, Jane Doe and John Doe, accessing the same page, https://oraclestore.oracle.com/OA_HTML/ibeCZzpHome.jsp?a=b
. This page contains a personalized greeting suited to the user.
Figure 2-2 Page with a Personalized Attribute
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 client first accesses a Web site that uses session IDs, the origin server includes a Set-Cookie
response-header in the response with the session cookie and value in order to establish a session.
Alternatively, origin servers can track a session with the client by including the session value in an embedded URL or POST
body parameter. With its next request to the same origin server, the client includes the embedded URL or POST
body parameter. Because of the embedded URL or POST
body parameter, the origin server determines that the client already has a session.
Using session information in a cookie, embedded URL parameter, or POST
body parameter, you can configure OracleAS Web Cache for the following purposes:
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-3 has several <A HREF=...>
links that include the session_ID
parameter. The Master Index link under the Oracle Database Standard Edition heading for Jane Doe uses the following HTML code:
<A HREF="http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10166&session_ID=334326">Master Index</A>
The same link for John Doe uses the following HTML code:
<A HREF="http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10166&session_ID=334327">Master Index</A>
By using the value of the session_ID
embedded URL parameter, OracleAS Web Cache substitutes the correct session information for Jane Doe and John Doe.
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-4, the template consists of common elements, such as a logo, navigation bars, framework, and other "look and feel" elements of the page. The fragments represent dynamic subsections of the page.
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 |
---|---|
|
Performs conditional processing based on Boolean expressions |
|
Specifies comments not be included in the output |
|
Allows variable access from an HTTP response |
|
Includes an HTML fragment |
|
Marks a fragment as a separately cacheable fragment, embedded in the HTTP response of another object |
|
Specifies an invalidation request within the response of a browser page |
|
Specifies non-ESI markup if ESI processing is not enabled |
|
Specifies alternate processing when a request fails because the origin server is not accessible |
|
Permits variable substitution for environment variables |
Example 2-1 shows the ESI markup language for the template page shown in Figure 2-4.
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 fragments for the client 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 client request for a template page with a Referer
request-header field, it forwards the request with the Referer
request header to the origin server. In turn, the origin server returns fragments to OracleAS Web Cache with the URL of the template as the value for the Referer
header. This functionality associates the fragment request with the template request.
Session cookie establishment for ESI templates and fragments works much the same way as typical OracleAS Web Cache objects with the following additional features:
Cookie
request-header field inheritance
When a client requests an ESI template page that includes fragments, requests for fragment pages are generated in OracleAS Web Cache. A fragment request inherits the Cookie
request-header field from the template request if the value of the Host
request-header field matches the value of Host
request-header field in the template request.
Set-Cookie
response-header field accumulation
When assembly of fragments is complete, OracleAS Web Cache includes a Set-Cookie
response-header field in the response with the cookie information from the template. For those fragments with a Host
request-header field that matches the Host
request-header field in the template, OracleAS Web Cache also accumulates the Set-Cookie
response-header fields with that of the template. For those fragments with a Host
request-header field that does not match the Host
request-header field in the template, OracleAS Web Cache does not accumulate the Set-Cookie
response-header field with that of the template and other matching fragments.
See Also:
|
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 uses the following Oracle-specific HTTP request and response-header fields:
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
For objects sent to clients, OracleAS Web Cache adds diagnostic information to the Server
response-header field of the HTTP response message.
Using the Server
response header information, you can determine whether a request was served from the cache or the origin server. For diagnostics purposes, it can be useful to also display this information as a textual string in the HTML response body of an object and in the access logs.
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 administrative interfaces Oracle Enterprise Manager 10g Application Server Control Console or OracleAS Web Cache Manager.
See Also:
|
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.
When the first client 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 client, 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 client.