Skip Headers
Oracle® Application Server Best Practices Guide
10g Release 2 (10.1.2)
B28654-01
  Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index
Previous
Previous 		Next
Next 		 

7 OracleAS Web Cache

This chapter describes performance best practices for OracleAS Web Cache. It includes the following topics:

7.1 Improve Performance, Scalability, and Availability

OracleAS Web Cache improves the scalability, performance and availability of e-business Web sites. Using OracleAS Web Cache, your applications benefit from higher throughput, shorter response times and lower infrastructure costs.

Using OracleAS Web Cache and its ESI features, your business application 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.

7.2 Planning and Deployment

The following sections describe best practices related to planning for and deploying OracleAS Web Cache:

7.2.1 Use Two CPUs and Consider Deploying on Dedicated Hardware to Avoid Operating System Limitations

You can deploy OracleAS 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. OracleAS Web Cache is designed for a dual CPU. Because OracleAS Web Cache is an in-memory cache, it is rarely limited by CPU cycles. Additional CPUs do not increase performance significantly. The speed of the processors is critical; use the fastest CPUs you can afford.

If other resources are competing with OracleAS 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 OracleAS Web Cache running on the same node as the application Web server, although a separate node for OracleAS Web Cache is often optimal.

For a Web site with more than one OracleAS 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 OracleAS 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.

Implementation Details


See Also:

Chapter 7, "Optimizing OracleAS Web Cache," in the Oracle Application Server Performance Guide

7.2.2 Cluster Cache Instances to Make Availability, Scalability, and Performance Gains

To increase the availability, scalability, and performance of your Web site, you can configure multiple instances of OracleAS Web Cache to run as members of a cache cluster. A cache cluster is a loosely coupled collection of cooperating OracleAS 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 OracleAS Web Cache instances, you can cache more content and support more client connections, expanding the overall capacity of your Web site and improving its performance.

Implementation Details


See Also:

Chapter 3, "Cache Clustering," in the Oracle Application Server Web Cache Administrator's Guide

7.2.3 Use a Hardware Load Balancer in Front of OracleAS Web Caches to Avoid a Single Point of Failure

Many customers deploy a single instance of OracleAS Web Cache in front of their application Web server farm. In such deployments, the OracleAS 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 OracleAS 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 recommends that two or more nodes running OracleAS Web Cache be deployed behind a third-party hardware load balancing device. In turn, customers should use the built-in load balancing functionality in OracleAS Web Cache to distribute cache miss traffic over the application Web server farm, as described in Section 7.2.4, "Use OracleAS Web Cache Built-In Load Balancing to Improve Availability and Scalability of Origin Servers".

If you need a low-cost solution to a hardware load balancer and do not require caching support, you can configure OracleAS Web Cache solely as a software load balancer. This configuration mode is useful for managing traffic to a low-volume, departmental, or test Web site.

Implementation Details


See Also:

7.2.4 Use OracleAS Web Cache Built-In Load Balancing to Improve Availability and Scalability of Origin Servers

Situated between Web browser clients and the origin servers, OracleAS Web Cache includes built-in weighted load balancing and failover detection features to ensure that cache misses are directed to the most available, highest performing origin server in the application Web server 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. You can configure OracleAS Web Cache to generate its own session-binding cookie, allowing you to use sessions without having to modify your applications.

In addition, OracleAS 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, you can deploy two or more nodes running OracleAS Web Cache behind a third-party hardware load-balancing device. Oracle also recommends that customers use the built-in load balancing and failure detection functionality in OracleAS Web Cache to route cache miss requests to origin servers. Deploying additional load balancing hardware between the OracleAS Web Cache and origin server tiers is not recommended for the following reasons:

  • Cost: Using another tier of load balancing hardware adds significant cost to a deployment, in part because these devices must also be deployed in pairs for high availability reasons.

  • Complexity: Another tier of load balancing hardware is another set of systems to configure, manage, and troubleshoot.

  • Features: OracleAS Web Cache includes performance assurance and surge protection features that enable customers to sustain higher loads with less application and database server hardware. These features depend on the capacity-based load balancing algorithms in OracleAS Web Cache.


See Also:

7.2.5 Test Application Upgrades and Patches to Ensure Existing Cache and Session Rules Still Function Correctly

Although there is a growing trend to specifying the caching rules dynamically with the Surrogate-Control response header, some sites continue to use OracleAS 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, OracleAS Web Cache is deployed in a production environment. Problems may 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 caching rules in OracleAS 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 caching rules much the same way as you did during the initial deployment cycle, including, but not limited, to using debug-level event logging. And if possible, include OracleAS Web Cache in your application regression test cycle.

7.3 Secure Content to Prevent Tampering

Depending on the application, you may or may not want requests for secure pages to go through the cache. Be cautious about caching secure content in OracleAS Web Cache. For secure content you do cache, ensure users cannot do URL tampering to see other user content. For this content, 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 or decryption processing time by OracleAS Web Cache.


See Also:

7.4 Configuring OracleAS Web Cache

The following sections describe best practices related to configuring OracleAS Web Cache:

7.4.1 Configure Enough Memory to Avoid Swapping Objects In and Out of the Cache

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 OracleAS Web Cache should be set to at least 500 MB.

The amount of memory that OracleAS Web Cache uses to store an object depends on whether the object is larger or smaller than 2 KB:

Implementation Details

To determine the maximum amount of memory required, take the following steps:

  1. Determine which objects you want to cache, how many are smaller than 2 KB and how many are larger than 2 KB. Determine the average size of the objects that are larger than 2 KB. Determine the expected peak load—the maximum number of objects to be processed concurrently.

  2. Calculate the amount of memory needed.


    See Also:

    Chapter 8, "Setup and Configuration," in the Oracle Application Server Web Cache Administrator's Guide provides a formula to use in calculating the amount of memory needed to cache your objects

7.4.2 Allocate Sufficient Network Bandwidth to Accommodate the Throughput Load

When you use OracleAS Web Cache, make sure that each node has sufficient network bandwidth to accommodate the throughput load. Otherwise, the network may be saturated even though OracleAS Web Cache has additional capacity. For example, if your application generates more than 100 megabits of data for each 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 interface cards (NIC): 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.

7.4.3 Set a Reasonable Number of Network Connections to Maximize Performance

It is important to specify a reasonable number for the maximum connection limit for the OracleAS Web Cache server. If you set a number that is too high, you can affect performance, 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.

Implementation Details


See Also:

Chapter 8, "Setup and Configuration," in the Oracle Application Server Web Cache Administrator's Guide for information about setting the number of network connections

7.4.4 Create Custom Error Pages to Suit Your Environment

By default, OracleAS Web Cache ships with and is configured to serve the following error pages:

  • network_error.html: This file is served when OracleAS 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.

  • esi_fragment_error.txt. This file is served when OracleAS Web Cache is unable to fetch the src specified in an <esi:include> tag and the alt attribute, onerror attribute, or the try |attempt |except block are either not present or fail.

For a production environment, Oracle advises that you modify the defaults or create entirely new error pages to be consistent with other error pages generated by your site.

Implementation Details


See Also:

Chapter 8, "Setup and Configuration," in the Oracle Application Server Web Cache Administrator's Guide for information on creating or modifying default error pages

7.5 Increasing Cache Hits

The following sections provide tips in increasing the cache-hit rate:

7.5.1 Use Cookies and URL Parameters to Increase Cache-hit Ratios

OracleAS Web Cache can cache different versions of an object 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 objects are cached under their full URLs, then the cache-hit ratio becomes very low. You can configure OracleAS Web Cache to ignore the non-differentiating URL parameter values when composing the "cache key" for objects, so a single object 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, OracleAS Web Cache can still store one single copy of the object with placeholders for the embedded URL parameters or the personalized strings, and dynamically substitute the correct values into the placeholders when serving the object to clients.

You can also control whether a cached object is served to a client based on its session state.

Implementation Details


See Also:

Chapter 2, "Caching Concepts," in the Oracle Application Server Web Cache Administrator's Guide for more information on multiple-version objects, sessions, ignoring URL parameter values, simple personalization, and how to control whether OracleAS Web Cache serves a cached object based on sessions

7.5.2 Use Redirection to Cache Entry Pages

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 create a blank page that provides session establishment for all initial requests and redirects to the real popular page. This way, subsequent redirected requests to the popular page will carry the session, enabling the popular page to be served out of the cache.

Implementation Details


See Also:

Chapter 12, "Creating Caching Rules," in the Oracle Application Server Web Cache Administrator's Guide for more information on configuring caching rules for pages requiring session establishment,

7.5.3 Use Surrogate-Control Headers Instead of Caching Rules to Better Manage Cacheability

There are two ways to specify the caching properties of an HTTP response using OracleAS Web Cache. You can use one or both of the following:

  • Administrators can configure caching rules using the Application Server Control Console or OracleAS Web Cache Manager interface.

  • Application developers can set caching policies through the 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 an object, it is preferable to use the Surrogate-Control header.

If you define many different categories of cacheable and non-cacheable objects, you need to carefully define rule selectors and rule priorities so that the appropriate rule is used for any object. Because 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. If you are creating new applications, consider building in Surrogate-Control response headers.

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 objects that OracleAS Web Cache can receive from an origin server, then editing the configuration using one of the administration interfaces may be simpler than generating Surrogate-Control headers for many objects.

Often, a combination of the two approaches is best.

Implementation Details


See Also:

Chapter 12, "Creating Caching Rules," in the Oracle Application Server Web Cache Administrator's Guide for more information about the Surrogate-Control response header

7.5.4 Use Partial Page Caching Where Possible to Increase Cacheability

Many Web pages, such as portal pages, are composed of fragments with unique caching properties. For these pages, full-page caching is not feasible. OracleAS 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. Different templates can share the same fragment, so that common fragments are not duplicated to waste cache space. Sharing can also greatly reduce the number of updates required when fragments expire. Depending on the application, updating a fragment is 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. You can cache each fragment in a full Web page as long as possible, even when some fragments are not cached or are cached for a much shorter period of time.

For example, a Portal page may include stock quotes that expire in 20 minutes, news that expires in three hours, and rotating ad banners that should not be cached. To serve consistent content, traditional full-page caches need to update the entire page at the highest change frequency of all its fragments. With partial page caching, you can update particular fragments rather than the entire page.

OracleAS 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.

7.5.5 Use ESI Variables to Improve Cache-hit Ratios for Personalized Pages

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.

OracleAS Web Cache allows application developers to use variables in an ESI template. Because OracleAS Web Cache can resolve variables to different pieces of request information or response information, you can significantly reduce the uniqueness of templates and fragments when personal information abounds.

There are two kinds of ESI variables: request variables and response variables. When an ESI template is assembled, a request variable is instantiated to a piece of request information such as a query string parameter, a cookie, or an HTTP header. For example, when a request for a dynamic page carries an application session ID in a query string parameter, this page may contain many hyperlinks with ESI request variables accessing this session ID, so that generated hyperlinks can carry the session ID into the next clicked page.

A response variable is similar to a request variable, except that its value comes not from the request, but from a special fragment called ESI environment. Response variable occurrences in the enclosing template can access an ESI environment, which is a type of fragment with a response that defines a set of variables. The tag itself does not contribute to the final assembled output. For example, a dynamic page with a calendar may need to present personal appointments that cannot be stored in Web browser cookies due to cookie size limits. The application can instead refer to a "profile" environment fragment in the template, in effect referring to all appointment in the environment without making separate requests for each appointment. In addition, you can merge multiple small fragments into one environment, so that each fragment can be referenced through response-variable instantiation. This operation reduces storage and retrieval overhead similarly.

7.5.6 Use the <esi:environment> Tag to Authenticate or Authorize Callbacks

Some applications protect certain Web pages with authentication, authorization, or session validation in the HTTP request. Even though you can cache page content, 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.

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. 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, specify the <esi:environment> tag to include that cookie in its request. You can also 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. OracleAS Web Cache proceeds to finish assembling the page. If the authentication, authorization, or validation fail, your application should return an appropriate HTTP status code (at or more than 500 to denote a server error, or between 400 and 499 to denote a client request error). Then, OracleAS Web Cache will recognize that this environment has failed, and resort to standard ESI exception handling to terminate this page or output an alternative error page or login page.

Implementation Details


See Also:

Chapter 16, "Edge Side Includes (ESI) Language Tags," in the Oracle Application Server Web Cache Administrator's Guide for more information about using the <esi:environment> tag or implementing ESI exception handling

7.5.7 Use JESI to Cache JSP Output

In dynamic applications, you can use Edge Side Includes for Java (JESI) tags.

The JESI specification is a specification and custom JSP tag library that developers can use to automatically generate ESI code. JESI facilitates the programming of Java ServerPages (JSPs) using ESI. While developers can always use ESI tags directly within their JSP code, JESI represents an easy way to express the modularity of JSPs and the caching of those modules, without requiring developers to learn a new programming syntax. JESI generates the appropriate ESI tags and headers in the JSP output that instruct ESI processors, such as OracleAS Web Cache, to cache (or not) templates and fragments for the appropriate duration. JESI also facilitates the partial execution of JSPs when an ESI processor requests fragments and templates.

7.6 Invalidation and Expiration

The following sections provide tips about invalidating and expiring cache objects:

7.6.1 Select the Invalidation Method Best Suited for Your Content to Keep Performance in Check

Pick an invalidation type that works best for your content, keeping performance in mind:

  • Use basic invalidation for one object based on an exact URL.

    A basic invalidation does not result in a cache traversal, making a basic invalidation highly performant.

  • Advanced invalidation for multiple objects that share one or more of the following common elements:

    • Path prefix

    • Host name and port number

    • HTTP request method

    • URL expression

    • POST body expression

    • Search keys from the Surrogate-Key response-header field

    • Cookies

    • HTTP request headers

    • Embedded URL parameters

    When OracleAS Web Cache receives an advanced invalidation request, it traverses the contents of the cache to locate the objects to invalidate. Depending on the structure and number of objects cached, it can take time for OracleAS Web Cache to invalidate content.

    For the quickest advanced invalidation, specify a substring match instead of regular expression match.

  • Inline invalidation to support either basic or advanced invalidation requests from the HTTP response, marked with the ESI <esi:invalidate> tag.

    Inline invalidation reduces the connection overhead associated with sending out-of-band invalidations.

Implementation Details

To send a basic invalidation request:

  • Use the step-by-step Invalidation wizard provided in Application Server Control Console. To get started:

    1. Navigate to the Web Cache Home page > Administration tab > Operations > Invalidation.

    2. In the first page of the Invalidation wizard, select The single object that matches this URL.

    3. Enter the complete URL patch and file name in the Object to Invalidate field.

  • For a standalone OracleAS Web Cache installation, use the OracleAS Web Cache Manager.

    To get started, navigate to Operations > Basic Content Invalidation.

  • Use the BASICSELECTOR element in a manual invalidation request

To send an advanced invalidation request:

  • Use the step-by-step Invalidation wizard provided in Application Server Control Console. To get started:

    1. Navigate to the Web Cache Home page > Administration tab > Operations > Invalidation.

    2. In the first page of the Invalidation wizard, select Specified Objects.

  • For a standalone OracleAS Web Cache installation, use the OracleAS Web Cache Manager.

    To get started, navigate to Operations > Advanced Content Invalidation.

  • Use the ADVANCEDSELECTOR element in a manual invalidation request.


See Also:

Chapter 13, "Sending Invalidation Requests," in the Oracle Application Server Web Cache Administrator's Guide for further information about sending basic and advanced invalidation requests, as well as inline invalidations

7.6.2 Build Programmatic Invalidation Into Application Logic to Invalidate Dynamic Content

OracleAS 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 CGIs, JSPs and Java servlets using the OracleAS Web Cache Java invalidation API, jawc.jar. 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 OracleAS 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.

To facilitate the caching of JSPs, developers can use the JESI custom tag library included with OC4J and Oracle JDeveloper. One of the tags,<jesi:invalidate>, enables programmatic invalidation when the JSP engine processes a page containing this tag.

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.

Implementation Details


See Also:

7.6.3 Combine Invalidation and Expiration Policies to Keep Cache Content Fresh

With expiration, cached objects are marked 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.

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. You can automate invalidation policies, as described in Section 7.6.2, "Build Programmatic Invalidation Into Application Logic to Invalidate Dynamic Content".

7.6.4 Use Invalidation Propagation in Clusters to Improve Data Consistency

In a cache cluster, you can send invalidation messages to one cache, and that cache propagates the invalidation messages to the other caches in the cluster or hierarchy.

The benefits of invalidation propagation include data consistency across cluster members and ease of use for the administrator.

Under the following circumstances, you may want to disable invalidation propagation and send the invalidation messages to each individual member of the cluster:

  • When the cluster membership is in flux. For example, as you begin deployment, you may have made changes to cluster members but have not yet propagated the configuration changes to all members. In this case, the invalidation messages are not propagated to the members with different configurations.

  • If you do not want to invalidate data for all cluster members. For example, because of time zone differences, you want to send invalidation messages to only some of the cluster members at one time.

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.

Implementation Details


See Also:

Chapter 13, "Sending Invalidation Requests," in the Oracle Application Server Web Cache Administrator's Guide

7.7 Optimizing Response Times

The following sections describe best practices in optimizing response times:

7.7.1 Tuning Origin Server and OracleAS Web Cache Settings to Optimize Response Time

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 OracleAS Web Cache settings.

Implementation Details

Check the values of the network-related parameters in OracleAS Web Cache and the application Web server configuration file (httpd.conf).


See Also:

Section 7.6, "Tune Network-Related Parameters," in the Oracle Application Server Performance Guide contains information on how to set turning parameters in OracleAS Web Cache and the application server

If these resources are set reasonably, check the following:

  • Caching rules. Make sure that you are caching the appropriate objects including popular objects.

  • Priority rankings of the caching rules. Give the non-cacheable objects a higher priority than the cacheable objects.

  • The number of rules. If you have a large number of rules, parsing of rules will take additional time.

If the settings for the origin server and OracleAS Web Cache are set correctly, but the response times are still higher than expected, check system resources, especially:

7.7.2 Use Compression to Improve Response Times and Reduce Network Bandwidth

OracleAS Web Cache features automatic compression of dynamically generated content. On average, using the standard GZIP algorithm, OracleAS 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 Web 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 Web browsers support the expansion of GZIP encoded objects.

Most application Web servers on the market are capable of serving compressed pages, but few enable caching of compressed output. With OracleAS Web Cache, compression is a simple yes or no option that an administrator selects when specifying a caching rule. Because OracleAS Web Cache supports regular expression for caching rules, you can apply compression 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 Web browser should receive compressed content. Unlike the typical application Web server, OracleAS Web Cache offers compression and caching for pages that have been dynamically generated and for ESI fragments specified in a Surrogate-Control response header. By caching compressed output, OracleAS 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 Web browsers with fewer round-trips, reducing overall latency. In addition, compressed objects consume less cache memory.

Do not compress images, 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 Web browsers have difficulty expanding these file types.

Implementation Details


See Also:

Chapter 12, "Creating Caching Rules," in the Oracle Application Server Web Cache Administrator's Guide for instructions about how to enable compression, as well as a complete listing of objects not compressed by OracleAS Web Cache

7.7.3 Use Only Warning or Notification Logging Levels to Conserve Resources

You can specify the level of detail for the event log. The trace or debug levels are useful for debugging purposes. Using either of these levels of event logging consumes system resources. For example, the log file might fill up disk space, causing OracleAS Web Cache to fail. Unless you need to diagnose problems, you should the Warning or Notification levels. With these levels, OracleAS Web Cache writes only typical events to the event log. Also, consider disabling access logging unless you are monitoring end-user performance and access.

Implementation Details


See Also:

Chapter 15, "Using Diagnostics Tools," in the Oracle Application Server Web Cache Administrator's Guide for more information about logging

  Previous
Previous 		Next
Next
  Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index