Release 2 (9.0.3)
Part Number B10578-02
 Core |
Platform |
 Contents |
| Oracle9i Application Server Best Practices Release 2 (9.0.3) Part Number B10578-02 |
|
This chapter describes Oracle9iAS Web Cache best practices. The topics include:
Many Web pages, such as portal pages, are composed of fragments with unique caching properties. For these pages, full-page caching is not feasible. However, Oracle9iAS Web Cache provides a partial page caching feature that enables each Web page to be divided into a template and multiple fragments that can in turn be further divided into templates and lower level fragments. Each fragment or template is stored and managed independently; a full page is assembled from the underlying fragments upon request. Fragments can be shared among different templates, so that common fragments are not duplicated to waste precious cache space. Sharing can also greatly reduce the number of updates required when fragments expire. Depending on the application, updating a fragment can be cheaper than updating a full page. In addition, each template or fragment may have its own unique caching policies such as expiration, validation, and invalidation, so that each fragment in a full Web page can be cached as long as possible, even when some fragments are not cached or are cached for a much shorter period of time.
Oracle9iAS Web Cache uses Edge Side Includes (ESI) to achieve flexible partial-page caching. ESI is a simple markup language for partial-page caching. Applications can mark up HTTP responses with two different kinds of tags, <esi:inline> and <esi:include>, that define the fragment/template structure in the response.
Personalized information often appears in Web pages, making them unique for each user. For example, many Web pages contain tens or hundreds of hyperlinks embedding application session IDs.
To resolve this, create your ESI pages with variables. Because variables can be resolved to different pieces of request information or response information, the uniqueness of templates and fragments can be significantly reduced when personal information abounds. This in turn results in better cache hit ratios.
In dynamic applications, you can use ESI tags for better caching in two ways: hand generating the tags, or using Edge Side Includes for Java (JESI) tags. The latter is recommended for two reasons:
Oracle Corporation recommends that you use JESI to write JSP-based applications.
If a partial page fragment can be fetched independently, such as with a URLPortlet, it should always be referenced with an <esi:include> template. This enables Oracle9iAS Web Cache to fetch the fragment independently of the rest of the page or fragments. However, if the fragment cannot be generated independently of the surrounding page, then the <esi:inline> tag enables Oracle9iAS Web Cache to cache the inline fragment and re-use it in different contexts. This also results in a single update or invalidation message as opposed to requiring multiple invalidation/updates.
When you need to invalidate one object in the cache, send a basic rather than an advanced invalidation request to avoid cache traversal. Advanced invalidation requests should be reserved for invalidation of multiple objects.
Further, use substring matching to invalidate all objects that match a certain criteria to speed up invalidation.
Oracle9iAS Web Cache is designed for caching highly dynamic Web pages. There are several ways to safeguard the correctness of the cached content. For those cached pages with content that changes following unpredictable actions by Web site users, the most effective way to ensure correct content is to build programmatic invalidation into application logic.
The application Web server and database are two areas that may benefit from embedded programmatic invalidation. On the application Web server, you can build invalidation into CGI's, JSPs and Java servlets using the Oracle9iAS Web Cache Java invalidation API jawc.jar. jawc.jar is located in the $ORACLE_HOME/webcache/jlib directory on UNIX and ORACLE_HOME\webcache\jlib directory on Windows. For example, page A displays information about a certain bike in stock. This page is cacheable. Page B provides users a way to reserve one bike for purchase. On the mid-tier there is a Java servlet or JSP to service page B. To make this servlet cache-aware, use jawc.jar to invalidate page A.
Similarly, you can build invalidation into PL/SQL applications using the Oracle9iAS Web Cache PL/SQL invalidation API wxvutil.sql and wxvappl.sql. This way, developers can embed the invocation of invalidation PL/SQL procedure calls into the PL/SQL Web page. wxvutil.sql and wxvappl.sql are located in the $ORACLE_HOME/webcache/examples directory on UNIX and ORACLE_HOME\webcache\examples directory on Windows.
In order to facilitate the caching of JSPs, developers can use the JESI custom tag library included with OC4J and Oracle JDeveloper9i. One of the tags is <jesi:invalidate>, which enables programmatic invalidation when the JSP engine processes a page containing this tag. For more information about JESI, see the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.
Alternatively, developers can tie invalidation logic to database updates. In the same bike example, you can use a PL/SQL invalidation procedure call to invalidate pages that rely on inventory data stored in the database. In other words, you can apply a database trigger to the row or table containing information about the bike.
For more information about invalidation, see Chapter 8, "Administering Oracle9iAS Web Cache," of the Oracle9iAS Web Cache Administration and Deployment Guide.
There are two ways to specify the caching properties of an HTTP response using Oracle9iAS Web Cache:
and/or
Surrogate-Control response header. If a given property is set in both a response header and the configuration, the value set by Surrogate-Control overrides rules specified in the configuration.
Although caching rules support the setting of more properties than the Surrogate-Control header, it is generally more manageable to set properties in the Surrogate-Control header whenever possible. For example, if you need to set the expiration policy and the multiple-version property for a document, it is preferable to use the Surrogate-Control header.
Caching rules can be less manageable when there are many different categories of cacheable and non-cacheable documents. In these circumstances, you need to carefully define rule selectors and rule priorities so that the appropriate rule is used for any document. Since a Surrogate-Control response header is only associated with one response and overrides the configuration, the properties set in Surrogate-Control will not be mistakenly replaced by other configuration rules or newly created configuration rules.
On the other hand, sometimes the configuration approach is more convenient. If a small number of rules are sufficient to describe all the caching properties of all documents that Oracle9iAS Web Cache can receive from an origin server, then editing the configuration using the Oracle9iAS Web Cache Manager administration interface may be simpler than generating Surrogate-Control headers for many documents.
Often, a combination of the two approaches is best.
Oracle9iAS Web Cache improves the scalability, performance and availability of e-business Web sites. Using Oracle9iAS Web Cache, your applications benefit from higher throughput, shorter response times and lower infrastructure costs.
Using Oracle9iAS Web Cache and its ESI features, your business application's performance can improve by several orders of magnitude with very little development effort. The return on investment is also significant, both in terms of developer resources (you no longer need to build your own dynamic caching solution) and hardware cost savings.
You can deploy Oracle9iAS Web Cache on the same node as the application Web server or on a separate node. When making your decision, consider system resources, such as the number of CPUs. Oracle9iAS Web Cache is designed to use one or two CPUs. Because Oracle9iAS Web Cache is an in-memory cache, it is rarely limited by CPU cycles. Additional CPUs do not increase performance significantly. However, the speed of the processors is critical; use the fastest CPUs you can afford.
If other resources are competing with Oracle9iAS Web Cache for CPU usage, then you should take the requirements of those resources into account when determining the number of CPUs needed. You can derive a significant performance benefit from Oracle9iAS Web Cache running on the same node as the application Web server, although a separate node for Oracle9iAS Web Cache is often optimal.
For a Web site with more than one Oracle9iAS Web Cache instance, consider installing each instance on a separate two-CPU node, either as part of a cache cluster or as standalone instances. When Oracle9iAS Web Cache instances are on separate nodes, you are less likely to encounter operating system limitations, particularly in network throughput. For example, two caches on two separate two-CPU nodes are less likely to encounter operating system limitations than two caches on one four-CPU node.
To avoid swapping objects in and out of the cache, it is crucial to configure enough memory for the cache. Generally, the amount of memory (maximum cache size) for Oracle9iAS Web Cache should be set to at least 256 MB.
To determine the maximum amount of memory required, take the following steps:
When you use Oracle9iAS Web Cache, make sure that each node has sufficient network bandwidth to accommodate the throughput load. Otherwise, the network may be saturated even though Oracle9iAS Web Cache has additional capacity. For example, if your application generates more than 100 megabits of data per second, 10/100 Megabit Ethernet will likely be saturated.
If the network is saturated, consider using Gigabit Ethernet rather than 10/100 Megabit Ethernet. Gigabit Ethernet provides the most efficient deployment scenario to avoid network collisions, retransmissions, and bandwidth starvations. Additionally, consider using two separate network cards: one for incoming client requests and one for requests from the cache to the application Web server.
If system monitoring tools reveal that the network is under utilized and throughput is less than expected, check whether or not the CPUs are saturated.
It is important to specify a reasonable number for the maximum connection limit for the Oracle9iAS Web Cache server. If you set a number that is too high, performance can be affected, resulting in slower response time. If you set a number that is too low, fewer requests will be satisfied. You must strike a balance between response time and the number of requests processed concurrently.
For information about setting the number of network connections, see the Oracle9iAS Web Cache Administration and Deployment Guide.
To increase the availability, scalability, and performance of your Web site, you can configure multiple instances of Oracle9iAS Web Cache to run as members of a cache cluster. A cache cluster is a loosely coupled collection of cooperating Oracle9iAS Web Cache instances working together to provide a single logical cache.
Cache clusters provide failure detection and failover of caches, increasing the availability of your Web site. If a cache fails, other members of the cache cluster detect the failure and take over ownership of the cached content of the failed cluster member.
By distributing the Web site's content across multiple Oracle9iAS Web Caches, more content can be cached and more client connections can be supported, expanding the capacity of your Web site and improving its performance.
For more information about cache clusters, see Chapter 3, "Cache Clustering," of the Oracle9iAS Web Cache Administration and Deployment Guide.
If you have not configured the origin server or the cache correctly, response time may be slower than anticipated. If the origin server is responding more slowly than expected or if the origin server is not responding to requests from the cache because it has reached its capacity, check the origin server and the Oracle9iAS Web Cache settings.
First, check the following:
MaxClients parameter limit. The MaxClients parameter, which limits the number of clients that can simultaneously connect to the origin server, should be large enough to allow connections (requests) from the caches. See the Oracle9i Application Server Performance Guide for more information about setting limits for the origin server.
MaxClients parameter limit on the origin server should be greater than or equal to the origin server capacity as set through the Oracle9iAS Web Cache Manager.
Then, if the origin server is still busier than anticipated, it may mean that the cache cannot process the requests and is routing more requests to the origin server. Check the following Oracle9iAS Web Cache settings:
For information on specifying these settings, see the Oracle9iAS Web Cache Administration and Deployment Guide.
If these resources are set reasonably, check the following:
If the settings for the origin server and Oracle9iAS Web Cache are set correctly, but the response times are still higher than expected, check system resources, especially:
With expiration rules, cached 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 documents from remaining in the cache indefinitely, Oracle Corporation recommends creating expiration rules for all cached documents.
With invalidation requests, an HTTP POST message specifies which objects to mark as invalid. Invalidation requests are intended for less predictable, more frequently changing content. Send invalidation requests when you know objects have been refreshed on the origin server. Invalidation policies can be automated, as described in Section 5.6, "Build Programmatic Invalidation Into Application Logic".
In a cache cluster, you can send invalidation messages to a particular cache cluster member that acts as the invalidation coordinator. The coordinator can also be chosen at random when invalidation messages are sent via the network load balancer deployed in front of the cluster. The coordinator propagates the invalidation messages to the other cache cluster members.
The benefits of invalidation propagation include data consistency across cluster members and ease of use for the administrator.
However, under the following circumstances, you may want to disable invalidation propagation and send the invalidation messages to each individual member of the cluster:
Note that if you do not invalidate data for all cluster members, the cached data may become inconsistent. In addition, cluster members may serve stale data, not only in response to requests from clients, but also in response to requests from their peers.
For more information about invalidation propagation, see the Oracle9iAS Web Cache Administration and Deployment Guide.
In general, you should route all HTTP and HTTPS requests through Oracle9iAS Web Cache. Ensure documents, especially HTTPS documents, are sent to authorized users through careful use of caching rules.
Depending on the application, you may or may not want requests for secure pages to go through the cache. If every HTTPS request is a non-cacheable page that is unique for each user session or is too sensitive for caching a copy, then route this traffic directly to the origin server. Because no traffic will be cached in this case, routing traffic to the origin server avoids extra encryption/decryption processing time at the Oracle9iAS Web Cache layer.
By default, Oracle9iAS Web Cache ships and is configured to serve the following two apology pages:
network_error.html: This file is served when Oracle9iAS Web Cache encounters network problems while connecting, sending, or receiving a response from an origin server for a cache miss request.
busy_error.html: This file is served when origin server capacity has been reached.
For a production environment, Oracle Corporation advises that you modify the defaults or create entirely new apology pages to be consistent with other error pages generated by your application.
To create or modify default apology page:
$ORACLE_HOME/webcache/docs on UNIX and %ORACLE_HOME%webcache\docs on Windows.
Because ESI has its own language elements for exceptions, there is no default apology page for <esi:include> errors. If you plan to use <esi:include> tags for partial-page caching and you do not implement the onerror attribute or the try|attempt|except block, then you must create an apology page. The onerror attribute is used before the try|attempt|except block. If the try|attempt|except block does not exist, then the exception handling is propagated to the parent or template page. The parent page will use the apology page, onerror attribute, or try|attempt|except block to handle the error. (Note that for the Oracle9iAS Web Cache 2.0.0.x and 9.0.2.x releases, when an apology page is configured, Oracle9iAS Web Cache bypasses any ESI programmatic exception handling code as described in bug 2412543.)
To configure exception handling:
onerror attribute or the try|attempt|except block for exception handling.
$ORACLE_HOME/webcache/docs on UNIX and%ORACLE_HOME%\webcache\docs on Windows: If there are many ESI fragments and you do not want display errors for each fragment, then configure Oracle9iAS Web Cache to serve a one-byte blank apology page for ESI errors. If you want to display a generic error message for each fragment that fails, then configure Oracle9iAS Web Cache to serve an apology page containing the error message.
For some popular site entry pages, such as "/", that typically require session establishment, session establishment effectively makes the page non-cacheable to all new users without a session. To cache these pages while preserving session establishment, you can either:
For more information on configuring caching rules for pages requiring session
establishment, see Chapter 7, "Creating Caching Rules," of the Oracle9iAS Web Cache Administration and Deployment Guide.
Some applications protect certain Web pages with authentication or authorization or validate session information in the HTTP request. Even though the page content can be cached, every HTTP request must be authenticated, authorized, or validated by the origin server. For these pages, it is not appropriate to cache the full page. While it is possible to utilize JavaScript to achieve authentication, authorization, and validation through a separate HTTP request, the <esi:environment> tag provides a better solution to this problem.
An ESI environment is a type of fragment with a response that defines a set of variables that can be accessed by response variable occurrences in the enclosing template. The tag itself does not contribute to the final assembled output. If a page has cacheable content but requires mandatory authentication, authorization, and session validation, you can enclose an <esi:environment> tag in the page referencing a non-cacheable environment, and cache the enclosing page as desired. When the cached page is requested, an HTTP request that specifies the environment will always be sent to the origin server, making a callback to the application. In this callback request, if you want to validate a cookie in the enclosing page request for session validation, authorization, or authentication, then specify the <esi:environment> tag to include that cookie in its request. It is also possible to include other information from the page request in the environment request.
If authentication, authorization, and validation are passed, your application should return HTTP status code 200 and any ESI environment response. Oracle9iAS Web Cache will proceed to finish assembling the page. If the authentication, authorization, and validation fail, then your application should return an appropriate HTTP status code at or above 500 to denote a server error, or between 400 and 499 to denote a client request error. Oracle9iAS Web Cache will then recognize that this environment has failed, and resort to standard ESI exception handling to abort this page or output an alternative error page or login page.
For more information about using the <esi:environment> tag or implementing ESI exception handling, see Appendix D, "Edge Side Includes Language," of the Oracle9iAS Web Cache Administration and Deployment Guide.
Oracle9iAS Web Cache can cache different versions of a document with the same URL based on request cookies or headers. To use this feature, applications may need to implement some simple change, such as creating a cookie or header that differentiates the pages.
On the opposite side of the spectrum, some applications contain some insignificant URL parameters that lead to different URLs representing essentially the same content. If the documents are cached under their full URLs, then the cache-hit ratio becomes very low. You can configure Oracle9iAS Web Cache to ignore the non-differentiating URL parameter values when composing the "cache key" for documents, so a single document will be cached for different URLs, greatly increasing cache hit ratios.
Sometimes the content for a set of pages is nearly identical, but not exactly the same. For example, the pages may contain hyperlinks composed of the same URL parameters with different session-specific values, or they may include some personalized strings in the page text, such as welcome greetings and shopping cart totals. In this case, Oracle9iAS Web Cache can still store one single copy of the document with placeholders for the embedded URL parameters and/or the personalized strings, and dynamically substitute the correct values into the placeholders when serving the document to clients.
You can also control whether a cached document can be served to a client based on its session state.
For more information on multiple version documents, sessions, ignoring URL parameter values, simple personalization, and how to control whether a cached document can be served to a request based on sessions, see Chapter 2, "Caching Concepts," of the Oracle9iAS Web Cache Administration and Deployment Guide.
Many customers deploy a single instance of Oracle9iAS Web Cache in front of their application Web server farm. In such deployments, the Oracle9iAS Web Cache acts as the virtual IP address for the application, in addition to providing caching and load balancing services. This deployment is both functionally sufficient and cost-effective for customers that do not require 100 percent application uptime. The Oracle9iAS Web Cache is highly stable and, in the event of a failure, a process monitor will automatically restart the cache.
For customers who cannot tolerate a single point of failure, Oracle Corporation recommends that two or more nodes running Oracle9iAS Web Cache be deployed behind a third-party hardware load balancing device. In turn, customers should use the built-in load balancing functionality in Oracle9iAS Web Cache to distribute cache miss traffic over the application Web server farm. Please refer to Chapter 4, "Deploying Oracle9iAS Web Cache," of the Oracle9iAS Web Cache Administration and Deployment Guide for more information.
Situated between browser clients and the origin servers, the Oracle9iAS Web Cache introduces a new tier into the traditional Web farm architecture. To reduce complexity and to avoid the cost of purchasing additional load balancing hardware, Oracle9iAS Web Cache includes built-in load balancing and failover detection features to ensure that cache misses are directed to the most available, highest performing origin server in the farm. The cache supports both stateless and stateful load balancing mechanisms, including the use of cookies and URL parameters to maintain server affinity when required. In addition, Oracle9iAS Web Cache maintains a pool of HTTP connections between the cache and the origin Web servers to reduce connection establishment overhead and improve cache miss performance.
To avoid a single point of failure, two or more nodes running Oracle9iAS Web Cache should be deployed behind a third-party hardware load-balancing device. However, Oracle Corporation also recommends that customers use the built-in load balancing and failure detection functionality in Oracle9iAS Web Cache to route cache miss requests to origin Web servers. Deploying additional load balancing hardware between the Oracle9iAS Web Cache and origin server tiers is not recommended for the following reasons:
For more information on load balancing, performance assurance and surge protection functionality, see the Oracle9iAS Web Cache Administration and Deployment Guide and various technical white papers on Oracle9iAS Web Cache
Oracle9iAS Web Cache features automatic compression of dynamically generated content. On average, using the standard GZIP algorithm, Oracle9iAS Web Cache is able to compress text files, such as HTML and XML by a factor of four. Because compressed objects are smaller in size, they require less bandwidth to transmit and can be delivered faster to browsers. With compression, everyone benefits: Internet Service Providers (ISPs), Hosting Service Provider (HSPs), corporate networks and content providers reduce their transmission costs, while end-users enjoy more rapid response times. Since 1997, all major browsers support the expansion of GZIP encoded documents.
Most application Web servers on the market are capable of serving compressed pages, but few enable caching of compressed output. With Oracle9iAS Web Cache, compression is a simple Yes/No option that an administrator selects when specifying a caching rule. Because Oracle9iAS Web Cache supports regular expression for caching rules, compression can be applied to responses using criteria other than just file extension. Regular expression makes it very easy to select which pages to compress and which pages not to compress, as well as whether or not a particular browser should receive compressed content. Unlike the typical application Web server, Oracle9iAS Web Cache offers compression and caching for pages that have been dynamically generated. By caching compressed output, Oracle9iAS Web Cache reduces the processing burden on the application Web server, which would otherwise have to re-generate and compress dynamic pages each time they are requested. Because compressed objects are smaller in size, they are delivered faster to browsers with fewer round-trips, reducing overall latency. In addition, compressed objects consume less cache memory.
Do not compress images, such as GIFs and JPEGs, as well as executables and files that are already zipped with utilities like WinZip and GZIP. Compressing these files incurs additional overhead without the benefits of compression. Also, do not compress JavaScript includes (.js) and Cascading Style Sheets (.css), as some browsers have difficulty expanding these file types.
For more information on compression, see the Oracle9iAS Web Cache Administration and Deployment Guide.
Oracle9iAS Web Cache offers hierarchical caching features that enable customers to easily create Content Delivery Networks (CDNs). For high availability and performance, many Internet businesses mirror their Web sites in strategic geographical locations. Caching is an excellent low-cost alternative to full-scale mirroring. Caching may also be used to serve local markets in order to shorten response times to these markets, and to reduce bandwidth and rack space costs for the content provider. Within the corporate intranet, so-called "Enterprise" CDNs (eCDNs) provide shorter response times for branch office users of e-business applications. Compared to application mirroring and database replication, eCDN is a more manageable and cost-effective model of distributed computing. Using Oracle9iAS Web Cache, customers can distribute the content assembly and delivery functions of their applications to key network access points, while maintaining centralized management of application logic and data.
In setting up an eCDN, customers typically deploy Oracle9iAS Web Cache in each branch office data center as well as in the central office where the application and database are maintained. For example, a U.S.-based company might deploy instances of Oracle9iAS Web Cache in its U.S., Japanese, and Australian offices. The central cache residing in the U.S. serves as the origin server for the caches in Japan and Australia. Using various commercially available DNS routing techniques, requests are handled by the cache that is closest to the end user. A browser request made by a Japanese employee, for instance, is handled by the cache instance in Japan, thereby reducing WAN traffic and eliminating long-haul network latencies. In a distributed cache hierarchy, the central cache is aware of the branch office caches. As a result, any content invalidation messages sent to the central cache automatically propagate to the remote caches. This invalidation propagation feature ensures content consistency across the CDN and simplifies the management of cache hierarchies.
Verbose event logs are useful for debugging purposes. However, verbose event logging consumes system resources. Unless you need the verbose event log to diagnose problems, you should disable verbose mode. Oracle9iAS Web Cache will write only typical events to the event log.
For information on specifying these settings, see Chapter 8, "Administering Oracle9iAS Web Cache," of the Oracle9iAS Web Cache Administration and Deployment Guide.
The Oracle9iAS Web Cache Manager is a graphical user interface for administering, configuring, and managing caches. Oracle Corporation recommends that you use it rather than manually editing the configuration files to make configuration changes.
In cache clusters, it is especially important to use Oracle9iAS Web Cache Manager to modify the configuration and to propagate it to the other cluster members. If you manually edit the configuration files, you may encounter problems. For example:
If you do not set the site name properly for each cluster member, identical objects could be cached in each cluster member, but the objects may be known by a different name in the different caches. For example, you could have the same object cached as:
mysite:7777:document1.html myste:7777:document1.html
If the site names are not consistent, the objects with the variant site name will not be invalidated even if you use invalidation propagation.
Oracle9iAS Web Cache was designed from the ground up to provide high performance, reliability and scalability on low-cost commodity hardware. A single Oracle9iAS Web Cache instance can be configured to support thousands of concurrent inbound HTTP connections. The throughput (requests/second) that a single cache instance can sustain scales linearly with CPU speed. Additionally, Oracle9iAS Web Cache fully supports the HTTP/1.0 and HTTP/1.1 header fields, including Keep-Alive. Keep-Alive reduces the frequency of connection establishment and improves performance and scalability under heavy load.
When clustered, the capacity - the amount of content stored in RAM - of the cache tier scales linearly, as well. Cache clustering achieves high availability by failing over among cluster nodes, as well as high scalability by utilizing memory and processing power of multiple inexpensive computing hardware units in parallel.
Not surprisingly, many customers have reported the successful use of Oracle9iAS Web Cache to prevent distributed and single-source denial-of-service attacks. Denial-of-service attacks attempt to prevent access to Web sites either by flooding sites with traffic volumes that surpass throughput and connection capacities or by sending malicious requests intended to exploit software flaws that cause servers to crash. By caching responses to denial-of-service requests, Oracle9iAS Web Cache helps address the throughput and scalability limitations of Web sites, while creating a crucial barrier between malicious queries and a site's origin application and database servers.
The guidelines for configuring connection limits, caching rules, and cache clusters are outlined in the Oracle9iAS Web Cache Administration and Deployment Guide.
To improve performance of advanced invalidation requests that use QUERYSTRING_PARAMETER to match objects with the same embedded URL parameters, manually create an invalidation index. Because an invalidation index creates more depth to an internal invalidation tree used by Oracle9iAS Web Cache, Oracle9iAS Web Cache is able to categorize objects in the cache for faster lookup and traversal. To use this feature for a URL or a request POST body, consider moving the URI or BODY value to QUERYSTRING_PARAMETER instead.
To specify an invalidation index, add an INVALIDATIONINDEX element to the webcache.xml file that specifies the substring value used for QUERYSTRING_PARAMETER:
<SECURITY> ... </SECURITY> <INVALIDATIONINDEX> <INDEXPARAM VALUE="VALUE_of_QUERYSTRING_PARAMETER"/> <INDEXPARAM VALUE="VALUE_of_QUERYSTRING_PARAMETER"/> </INVALIDATIONINDEX> <WATCHDOG ENABLE="YES|NO"/>
Oracle Corporation recommends using invalidation indexes to create more depth to flat directory structures.
For more information about invalidation, see Chapter 8, "Administering Oracle9iAS Web Cache," of the Oracle9iAS Web Cache Administration and Deployment Guide.
Though there is a growing trend to use options provided by Oracle9iAS Web Cache for specifying the caching rules dynamically with the Surrogate-Control response header, some sites will continue to use Oracle9iAS Web Cache Manager for configuring the rules statically. Typically this configuration is done at the start of the deployment cycle. After adequate testing in a staging area to validate the rules, Oracle9iAS Web Cache is deployed in a production environment. Problems arise when the backend application is upgraded for patches or with new versions and some or all of the earlier statically configured rules become not applicable and void. For example, if a site uses a session-related caching rule and, after applying a patch the name of the session cookie or session-embedded URL parameter changes, all the pages related to that rule will no longer be cacheable, resulting in poor performance for the site.
When applying application upgrades and patches, it is important to understand the extent of the application changes and then verify and tune the related cacheability rules in Oracle9iAS Web Cache. By periodically checking the cache-hit percentage and ensuring that it remains more or less constant, you can guard against unexpected behavior. Whenever there is a major change in the database or the mid-tier layer, such as for upgrades or application patches, you should validate cacheability rules much the same way as you did during the initial deployment cycle, including but not limited to using verbose event logging. And if possible, include Oracle9iAS Web Cache in your application regression test cycle.
The default configuration for Oracle9iAS Web Cache does not enable HTTPS for administration, invalidation, or statistics monitoring requests. Instead, these ports are configured for HTTP basic authentication. On an insecure network, the passwords for the administrator user and the invalidator user can be decoded if they are sniffed out of the HTTP traffic. To avoid breach of security information for unprotected and insecure networks, set the communication protocol to HTTPS for administration and invalidation operations in the Operation Ports page (Cache-Specific Configuration > Operations Ports) of Oracle9iAS Web Cache Manager.
|
 Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|