Release 2 (9.0.2)
Part Number A95404-02
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle9iAS Web Cache Administration and Deployment Guide Release 2 (9.0.2) Part Number A95404-02 |
|
This chapter explains how Oracle9iAS 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:
Oracle9iAS Web Cache uses caching rules to determine which documents to cache. When caching rules for a particular URL are first configured, those documents contained within the URL are not cached until there is a browser request for them. When the first request for a document comes in, Oracle9iAS Web Cache appends a Surrogate-Capability request-header field to the document. The Surrogate-Capability request-header field identifies that the document passed through the cache. Oracle9iAS Web Cache then sends the request to the origin server. This is a cache miss. If the requested document is specified as one of the documents to cache, then Oracle9iAS Web Cache caches the document for subsequent requests. For a subsequent request for the document, Oracle9iAS Web Cache serves the document from its cache to the browser. This is a cache hit.
Note the following cache population considerations for browser requests:
If-Modified-Since request-header field
When a browser sends a GET method request with an HTTP If-Modified-Since request-header field for a cached document, Oracle9iAS Web Cache compares the time stamp used in header with the Last-Modified request-header field of the cached document to determine if the document needs to be served. If the cached document is more current than the one requested by the browser, then Oracle9iAS Web Cache serves the cached document to the browser. When the Last-Modified header does not exist, Oracle9iAS Web Cache uses the time the document entered the cache as the time stamp. If the cached document is less current than the one requested by the browser, then Oracle9iAS Web Cache sends an HTTP 304 Not Modified status code to the browser.
Range request header field
When the first browser request for a multi-part document with an HTTP Range request-header field comes in, Oracle9iAS Web Cache sends the request to the origin server. The origin server serves the entire document to the browser, and Oracle9iAS Web Cache caches the entire document for the request. For a subsequent request for the document, Oracle9iAS Web Cache serves only the part requested from the browser.
|
Notes:
|
Consistency and performance are crucial for the reliability of Oracle9iAS Web Cache. This section contains the following topics:
The features invalidation and expiration ensure consistency between the cache and the origin servers.
With invalidation, an HTTP POST message is sent by specifying which documents to mark as invalid. An invalidation message is intended for less predictable, more frequently changing content. When documents are marked as invalid and a browser requests them, they are removed and then refreshed with new content from the origin servers. You can select to remove and refresh invalid documents immediately, or base the removal and refresh on the current load of the origin servers.
With expiration, documents 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. If an expired document contains an ETag request-header, Oracle9iAS Web Cache first checks with the origin server to see if the document has changed since it was last refreshed. If the document is still valid, then the origin server sends an HTTP 304 Not Modified status code to Oracle9iAS Web Cache and the document is not refreshed. If the document is no longer valid, then the origin server returns a full response, with an updated version of the document.
|
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, Oracle9iAS Web Cache intelligently serves some of the documents stale until the origin servers have the capacity to refresh them.
Oracle9iAS Web Cache provides minimal trade-off between performance and consistency through performance assurance heuristics that determine which documents can be served stale. These heuristics are based on a number of factors including:
Validity is based on the expiration time, invalidation time, and removal time of an object.
Oracle9iAS 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. Scheduled removal time is something that administrators can control. 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 total available capacity is determined by the following formula:
Total Capacity - Total Load
In the formula:
Together, these factors provide Oracle9iAS Web Cache with a logical queue of content to update from the origin servers.
Figure 2-1 illustrates how performance assurance heuristics are used during widespread invalidation.
Right after invalidation, the number of fresh documents served decreases to 20 documents for each second. However, the number of fresh cache hits quickly increases to 5,000 documents for each second over a short period of time. This is because Oracle9iAS Web Cache refreshes the most popular documents first so that these documents have little chance of being served stale. Once the popular documents are refreshed, the less popular documents are refreshed. The total number of documents that can revalidated in a given period of time is dependent on origin capacity. At the end of invalidation, only fresh content is served.
Propagation of invalidation messages from one Oracle9iAS Web Cache server to another occurs in the following deployments:
In a configuration with a hierarchy of Oracle9iAS Web Cache servers, it is likely that content will be cached on multiple servers.
Figure 2-2 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 caches content from an application Web server, the remote cache caches 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-3 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.
If content from the provider sites becomes invalid, an invalidation message is sent to the provider caches. In turn, the provider caches propagate invalidation message to the subscriber cache to ensure consistency.
To ensure that the a provider cache only invalidate its content, the 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, then the subscriber cache processes the request. Otherwise, the request is rejected.
|
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 Oracle9iAS Web Cache propagates invalidation messages, it sends the invalidation messages to one cache cluster member who acts as the invalidation coordinator. The coordinator propagates the invalidation messages to the other cluster members. The coordinator waits for responses from all cluster members. When the propagation completes, it returns a message that lists, for each cluster member, the cluster member name, the status of the invalidation request, and the number of objects invalidated.
If the invalidation coordinator cannot be reached, Oracle9iAS Web Cache returns an error message and does not propagate the invalidation messages.
|
See Also:
"Invalidating Documents in the Cache" for instructions on invalidating content |
Most Web pages today are dynamically generated before delivery to the browser. Web developers frequently use database-driven technologies like Java Server Pages (JSP), Active Server Pages (ASP), PL/SQL Server Pages (PSP), Java Servlets, and Common Gateway Interface (CGI) to design their applications. These technologies are used for complex Web sites, because they are easier to modify and maintain when information is stored in a database. Examples of pages that are dynamically generated include:
Because of invalidation, Oracle9iAS Web Cache knows which documents are valid and which documents are invalid. This is especially important for dynamically generated content that changes frequently.
Most static caches and content distribution services have no mechanism to verify the consistency of dynamically generated Web pages with the data sources used to create them. Therefore, it is difficult for these services to know when content has changed. Oracle9iAS Web Cache, on the other hand, receives 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 or category information, in message headers that browsers pass with every request to the origin server. This message header can contain a Set-Cookie response-header field that specifies a cookie and its value:
Set-Cookie:cookie=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 out of privacy concerns. For this reason, applications often embed parameter information in the URL. Oracle9iAS Web Cache accepts requests that use the following characters as delimiters for embedded URL parameters: question mark (?), ampersand (&), dollar sign ($), or semi-colon (;).
Oracle9iAS Web Cache is able to recognize both cookies and embedded URL parameters, enabling it to recognize caching rules for documents with:
See Also:
http://www.cookiecentral.com/ for further information about cookies
Some pages have multiple versions, enabling categorization. Figure 2-4 shows the same document, 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 Oracle9iAS Web Cache to recognize and cache multiple-version pages by using the:
For those documents 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 document that do not use the cookie.
When a browser sends an initial request for a multiple-version document, Oracle9iAS 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
Oracle9iAS 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 it value do not match, then the response is not cached. Once versions of the document are cached, Oracle9iAS Web Cache uses the value of the cookie in the browser's request to serve the appropriate version of the document to the browser.
Table 2-1 shows four different versions of same URL, http://www.dot.com/page1.htm. The URL uses a cookie named user_type, which supports browser requests that contain cookie values of Customer, Internal, and Promotional. You can configure Oracle9iAS Web Cache to recognize the user_type cookie, enabling Oracle9iAS Web Cache to cache three different documents. In addition, you can configure Oracle9iAS Web Cache to cache a fourth document for those requests that do not use a cookie.
For those documents that use 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. Oracle9iAS Web Cache uses the header to serve the appropriate version of the URL to browsers.
Oracle9iAS Web Cache supports all valid HTTP request headers. Table 2-2 lists the HTTP request-header fields supported by the Oracle9iAS Web Cache Manager interface, as described in "Configuring Caching Rules". You can specify other HTTP request-header fields with the Surrogate-Control response-header field, as described in "Configuring Caching Attributes in Response Headers".
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 Oracle9iAS Web Cache HTML tags <!-- WEBCACHETAG--> and <!-- WEBCACHEEND-->.
Oracle9iAS Web Cache processes these tags and caches the instructions for substituting values for personalized attributes based on the information contained within a cookie or an embedded URL parameter.
This functionality enables Oracle9iAS 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 embedded URL parameter. All subsequent requests for the page that pass the cookie or embedded URL parameter are served from the cache.
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 for the user.
The HTML code for the personalized greeting Jane Doe uses the following HTML code:
<B> <!-- WEBCACHETAG="person01"--> Jane Doe <!-- WEBCACHEEND--> </B>
The HTML code for personalized greeting John Doe uses the following HTML code:
<B> <!-- WEBCACHETAG="person01"--> John Doe <!-- WEBCACHEEND--> </B>
person01 represents the personalized attribute definition assigned to the person_name cookie that Jane and John pass to Oracle9iAS 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 Oracle9iAS 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, instead of cookies, the page supported embedded URL parameters, then the URL would contain the person_name parameter. For example, the page for Jane Doe could be 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 Oracle9iAS Web Cache with a personalized attribute definition of person_name01 to map to the person_name embedded URL parameter. Oracle9iAS Web Cache would then use the value of the embedded parameter to substitute the appropriate name.
To substitute personalized attribute values:
If a request does not contain the cookie or embedded URL parameter, then Oracle9iAS Web Cache substitutes the personalized attribute with a default string.
|
Note:
You can also substitute session values between the
See Also: "Configuring Personalized Attribute Definitions and Rules for Personalized Attributes" |
You can specify how Oracle9iAS Web Cache serves requests with the existence or nonexistence of personalized attribute cookies or embedded URL parameters. You can select to:
For example, if you want to require that the request get the personalized attribute cookie or embedded URL parameter settings from the origin server, then select to serve cached documents to requests that have the personalized attribute cookie or embedded URL parameter, but do not serve cached documents to requests that do not have the personalized attribute cookie or embedded URL parameter.
When you select to serve for both choices, you can then specify if requests with or without the personalized attribute cookie or embedded URL parameter can share the same cached document.
To specify how personalized attribute pages are served by Oracle9iAS Web Cache:
Some Web sites keep track of user sessions by assigning each user a unique session ID. Session IDs are typically used for Web sites with catalog pages. 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 parameter. With its next request to the same origin server, the browser includes the embedded URL parameter. Because of the embedded URL parameter, the origin server determines that the browser already has a session.
Using session information in a cookie or an embedded URL parameter, you can configure Oracle9iAS Web Cache for the following purposes:
By default, Oracle9iAS Web Cache distinguishes origin server responses by the request URLs. However, if the request URL contains an embedded URL session parameter, then the request URL to the same page content is distinct for each session. Therefore, Oracle9iAS Web Cache will cache responses for each of the distinct URLs. This can result in low cache hit rates and redundantly cached documents.
You can configure Oracle9iAS Web Cache to ignore the value of embedded URL parameters so that one cached document is served to multiple sessions requesting the same page. Oracle9iAS Web Cache will then cache the response to the first request and serve 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 and user John Doe requesting the same page with a request URL of https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103&session_ID=33437. The only distinct part of the URLs is the value of the session_ID parameter. Rather than caching and serving two versions of the same document, you can configure Oracle9iAS Web Cache to ignore the value of session_ID so that one cached document can be served to both users.
To ignore the value of URL parameters, configure a session definition in Oracle9iAS Web Cache that specifies the name of the session embedded URL parameter. Because you specify a session definition for a site or for all sites, the specified embedded URL parameter will be ignored for all requests to the relevant sites.
In section "Ignoring the Value of Embedded URL Parameters", it is described how you can ignore the value of embedded URL parameters for documents with identical content for all sessions. However, in some cases, the HTML content of documents 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 Oracle9iAS Web Cache to substitute the values of session parameters in HTML hyperlink tags with the session information contained within a session cookie or an embedded URL parameter. Configuring session value substitution in combination with ignoring the value of embedded URL parameters, you can configure Oracle9iAS Web Cache to cache one document for multiple sessions, even if the session parameter values in session-encoded URLs vary.
Continuing with the example from "Ignoring the Value of Embedded URL 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 Oracle9i Release 1 (9.0.1) heading for Jane Doe uses the following HTML code:
<A HREF="https://oraclestore.oracle.com/OA_ HTML/ibeCCtpSctDspRte.jsp?section=11886&session_ID=334326">Master Index</A>
The same link for John Doe uses the following HTML code:
<A HREF="https://oraclestore.oracle.com/OA_ HTML/ibeCCtpSctDspRte.jsp?section=11886&session_ID=334327">Master Index</A>
By using the value of the session_ID embedded URL parameter, Oracle9iAS Web Cache substitutes the correct session information for Jane Doe and John Doe.
Once 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 or embedded URL parameter. If the request does not contain a session cookie or embedded URL parameter, then Oracle9iAS Web Cache substitutes the session information in the session-encoded URLs with a configurable default string.
To substitute session values in session-encoded URLs:
You can specify how Oracle9iAS Web Cache serves requests with the existence or nonexistence of session cookies or embedded URL parameters. You can select to:
For example, if you want the first request of a new user to establish a session from the origin server, then select to serve cached documents to requests that have the session cookie or embedded URL parameter, but do not serve cached documents to requests that do not have the session cookie or embedded URL parameter.
When you select to serve for both choices, you can then specify if requests with or without the session cookie or embedded URL parameter can share the same cached document.
To specify how session-related pages are served by Oracle9iAS Web Cache:
See Also:
Oracle9iAS 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 broken down into fragments of differing caching profiles. These fragments are each maintained as separate elements in the origin server or content delivery network. The fragments are assembled into HTML pages as appropriate when requested by end users.
By enabling dynamic assembly of Web pages on Oracle9iAS 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 Oracle9iAS Web Cache when requested. Furthermore, page assembly can be conditional, based on information provided in HTTP request headers or end-user cookies.
The basic structure a content provider uses to create dynamic content 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 tell Oracle9iAS 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 rule. 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.
Figure 2-8 shows the ESI markup language for the template page shown in Figure 2-7.
<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="/CompanyStack.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 home page. </esi:remove> ... </BODY> </HTML>
Figure 2-9 shows the XML response of GetProfile.jsp, which provides access to profile environment variables.
<?xml version=1.0?> <esi-environment esiversion="ORAESI/9.0.2"> <PersonalInterests>Sports</PersonalInterests> <zipcode>94065</zipcode> <tickers>ORCL,YHOO</tickers> <address>500 Oracle Parkway, Redwood Shores, CA 94065</address> </esi-environment>
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. Oracle9iAS Web Cache stores the enclosed portions as separate fragments and the original page as page templates without the enclosed fragments. Fragments are shared if their names are identical.
Figure 2-10 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.
<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:
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.
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.
ESI <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.
Figure 2-11 shows an <esi:inline> example with a fetchable fragment named /news101. A request for the page returns the template page and the fetchable fragment.
<HTML> ... <esi:inline name="/news101" fetchable="yes"> <TABLE> ... </TABLE> </esi:inline> ... </HTML>
|
See Also:
"ESI inline Tag" for further information about the |
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 <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 makes its applicable scenarios very different from those of <esi:inline>:
<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.
<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:
<esi:include> tags fetch and assemble directly, reducing one layer of redundancy.
<esi:inline> tags. If <esi:include> is used for page fragmentation and assembly, Oracle9iAS 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.
Figure 2-8 shows ESI markup with <esi:include> tags.
Session cookie establishment for ESI templates and fragments works much the same way as typical Oracle9iAS Web Cache documents 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 Oracle9iAS Web Cache. A fragment requests inherit 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, Oracle9iAS 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, Oracle9iAS 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 match the Host request-header field in the template, Oracle9iAS 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, and any Web programming technology. The ESI language includes the following features:
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.
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.
ESI allows use of boolean comparisons for conditional logic in determining how pages are processed.
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.
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.
Oracle9iAS Web Cache does not perform character set conversion for non-ESI pages.
Oracle9iAS 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 Oracle9iAS 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.
|
Note: The Oracle proprietary language elements described in Table D-2, " Oracle Language Elements" are not supported by the JESI in this release. Oracle Corporation plans to support these language elements in a future implementation. |
|
See Also:
|
Oracle9iAS Web Cache provides support for following HTTP request and response-header fields:
For each requested document from the cache, Oracle9iAS Web Cache appends a Surrogate-Capability request-header field to a document's HTTP request message. The Surrogate-Capability request-header enables Oracle9iAS Web Cache to identify the operations it is capable of performing to origin server. 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.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 Oracle9iAS Web Cache in release 9.0.2.
"ESI/1.0" to process standard ESI tags for content assembly and partial page caching
"ESI-Inline/1.0" to process <esi:inline> tags
"webcache/1.0" to process the <!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> tags for personalized attributes and session-encoded URLs
"webcache/1.0" is mutually exclusive with "ORAESI/9.0.2","ESI/1.0", and "ESI-Inline/1.0".
For documents sent to browsers, Oracle9iAS Web Cache adds diagnostic information to the Server response-header field of the HTTP response message:
Server: Oracle9iAS/9.0.2 Oracle HTTP Server/version Oracle9iAS-Web-Cache/9.0.2 (diagnostic_information)
The Server response-header field specifies name/value pairs for Oracle HTTP Server and Oracle9iAS Web Cache. The information for Oracle9iAS 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=document_age]
Table 2-4 describes the diagnostic fields.
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 document was a cache hit:
Server: Oracle9iAS/9.0.2 Oracle HTTP Server/9.0.2 Oracle9iAS-Web-Cache/9.0.2.0.0 (TH;max-age=60+30;age=55)
(TH;max-age=60+30;age=55) 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 document 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 is 5 seconds to expiration and 35 seconds to removal
"Diagnostic Information in the Server Response-Header Field or HTML Body" for instructions on disabling the diagnostics information or displaying the information in the HTML response
See Also:
Application developers can choose to store some of the caching attributes in a Surrogate-Control response-header field header. This response-header field enables the application Web server to override the settings configured through the Oracle9iAS Web Cache Manager interface. It is also required to enable partial page caching for pages supporting ESI.
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...)]
|
See Also:
"Configuring Caching Attributes in Response Headers" for complete information about configuring the supported |
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|