7.1 OracleAS Web Cache

   

OracleAS Web Cache is the primary caching mechanism provided with Oracle Application Server. An OracleAS Web Cache instance sits in front of one or more Oracle HTTP Servers, as described in Chapter 2. The responses to all requests directed to the Oracle HTTP Server through OracleAS Web Cache can be cached in OracleAS Web Cache, which means that this cache can handle any web content transmitted with the standard HTTP protocol. Thus, OracleAS Web Cache works with Oracle Application Server as well as with any other HTTP application server.

Web Cache can also act as a load balancer for multiple instances of Oracle Application Server, and it provides some high-availability features as well. By caching selected request responses, OracleAS Web Cache reduces the load on the application server. The load is reduced because cached content no longer needs to be regenerated. CPU cycles and other resources are thus freed, thereby improving performance for those items that can't be cached.

OracleAS Web Cache was designed to work on low-cost machines. Because OracleAS Web Cache works as an in-memory cache, its capabilities are more dependent on addressable, available memory than they are upon CPU speed or number of CPUs. OracleAS Web Cache was designed to use two processors. Oracle's own My Oracle site, for example, uses a pair of two-way Intel machines as its own OracleAS Web Cache cluster.

7.1.1 Basic Principles

OracleAS Web Cache is a server accelerator. OracleAS Web Cache instances act as a front end cache for pages, content fragments , and other objects coming from one or more application servers. OracleAS Web Cache can also be used with third-party web servers, such as BEA's WebLogic or IBM's WebSphere.

In the simplest case, a web server delivers static pages in response to a client request. In this case, the server retrieves a page from disk. For many sources of web content, however, the case isn't nearly so simple. A page may be based on dynamic content, changing either with time or because of the characteristics of the user who has made a request. A page may even be assembled from several sources of content, which can individually be either static or dynamic.

A database uses a memory cache to hold frequently used data, allowing for faster retrieval. OracleAS Web Cache does the same thing with web pages and, more importantly, portions of web pages. This second capability expands the scope of potential performance improvement.

Many web pages are customized: a simple page contains common elements as well as portions specific to the user or the situation. For instance, the home page for an application is largely the same for all users, but may contain special greetings or messages for a particular user. OracleAS Web Cache can assemble the page from different fragments, providing the performance improvement of a memory cache everywhere content is reused.

Several other components of Oracle Application Server may also use OracleAS Web Cache to improve performance:


OracleAS Portal

OracleAS Portal comes with a set of predefined caching and invalidation rules.


OracleAS Discoverer

OracleAS Discoverer content can be cached by OracleAS Web Cache.


Oracle AS Wireless

OracleAS Wireless content can also be cached by OracleAS Web Cache. Note, however, that OracleAS Web Cache is used by the OracleAS Wireless server as a repository for content, rather than as a front end, which is the role it plays for normal HTTP requests.


eBusiness Suite

Portions of Oracle's eBusiness Suite are also supported by OracleAS Web Cache.

OracleAS Web Cache also supports a variety of security configurations including HTTPS communications between a browser and itself and between itself and origin servers, as well as redirection for an OracleAS Single Sign-On server. OracleAS Web Cache can also communicate with client programs that use client-side SSL certificates. In this case, OracleAS Web Cache forwards the certificate information in special HTTP request headers, which are then used by the Oracle HTTP Server for authentication.

OracleAS Web Cache can provide scalability and high availability in several different ways.

  • OracleAS Web Cache provides rapid response by being able to cache both static and dynamic content, allowing pages to be returned directly from OracleAS Web Cache without having to access the originating application server. This rapid response allows the cache to provide support for more users.

  • If a request comes in that can be satisfied directly from OracleAS Web Cache, there is no need to go to the application server for the content. In this scenario, OracleAS Web Cache provides availability even though the application server may be unavailable.

  • If OracleAS Web Cache can't contact the required web server (known as the origin server in this context), the instance returns a standard apology page. This page can be modified, but it can contain only static HTML. If you want to include other elements, such as an image or a company logo, you can designate another HTTP server to serve up these images and embed the images in your apology page.

  • OracleAS Web Cache can load-balance for multiple application servers, increasing the scalability of the overall site.

  • OracleAS Web Cache instances can be clustered, with each cache instance providing failover for other cache instances as well as scalability for the entire OracleAS Web Cache.

The following subsections describe how OracleAS Web Cache handles incoming requests and the various topologies that can be used for OracleAS Web Cache and their implications. We also cover the basics of how OracleAS Web Cache moves content out of the cache with invalidation; how OracleAS Web Cache handles static, dynamic, and partial pages; administration of OracleAS Web Cache instances; and other features of the product.

7.1.2 How It Works

OracleAS Web Cache sits in front of a web server, as shown in Figure 7-1. The web server here is referred to as an origin server. The web server could also be a proxy server used to access content outside the firewall.

Figure 7-1. OracleAS Web Cache fulfilling user requests
figs/oas_0701.gif

When a request comes into an OracleAS Web Cache instance, it determines whether the request is for a site that uses the instance. That information is provided by the Host request-field header from the request, the host portion of the URL, or the src attribute of the ESI include tag, which is explained later in this chapter.

ESI stands for Edge Side Includes , an open standard specification for defining web-page components for dynamic page assembly. More information on ESI is available at http://www.esi.org.


If the request is for a document from a site that uses the instance, OracleAS Web Cache checks to see if the document is in the cache. If OracleAS Web Cache can satisfy the request, it returns the page to the user. If it can't satisfy the request, it requests the object from the application server after appending a Surrogate-Control response-header field to the document. The application server returns the object to OracleAS Web Cache.

If the object is specified as cacheable, by either a caching rule or an attribute in the returned Surrogate-Control response-header, the object is cached for future use. For pages that are constructed of page fragments, using ESI (as described later), OracleAS Web Cache follows the same procedure for each fragment.

Once the document is available, OracleAS Web Cache returns it to the user. If the newly retrieved object is marked as being cacheable, the object is placed in OracleAS Web Cache's cache.

The flow of logic for OracleAS Web Cache requests is shown in Figure 7-2.

Figure 7-2. Logic flow of requests to OracleAS Web Cache
figs/oas_0702.gif

Objects remain in the cache until they are either removed (because of demand for cache resources) or marked invalid, as described later. If the total size used by OracleAS Web Cache exceeds a configurable percentage of the overall memory available for the instance, OracleAS Web Cache will initiate a garbage-collection routine that will select content to be removed. You might want to set the maximum size for any single cached object to avoid using up too much cache memory too quickly.

OracleAS Web Cache lets you set a maximum size for any cached object. Any object that exceeds the specified size isn't cached, regardless of how it is marked or how caching rules apply to it.

7.1.3 Topologies for OracleAS Web Cache

Earlier, Figure 7-1 showed a simple configuration for an OracleAS Web Cache instance, with a single OracleAS Web Cache instance supporting a group of sites. OracleAS Web Cache can be on the same machine with multiple instances of an application server. In this configuration, OracleAS Web Cache uses interprocess communication (IPC) to assign requests to application server instances.

If, instead, OracleAS Web Cache is on a different machine, it uses HTTP to communicate with the origin server. In this configuration, a single OracleAS Web Cache instance can communicate with multiple origin servers. OracleAS Web Cache uses a connection pool for each origin server for faster communication with the server.

OracleAS Web Cache can work in several other topologies to provide additional features and benefits. Although OracleAS Web Cache is primarily used for caching content, you can also use it as a load balancer that supports application server failover. Three common OracleAS Web Cache deployment topologies include:

  • Use of OracleAS Web Cache to support load balancing and failover for multiple origin servers

  • Use of multiple instances of OracleAS Web Cache for load balancing and failover for OracleAS Web Cache itself

  • Use of multiple instances of OracleAS Web Cache in a cluster

Another set of topologies, known as hierarchies , is used for specific needs, such as geographic distribution of caching.

7.1.3.1 OracleAS Web Cache and multiple origin servers

The ability to support multiple application servers is built into OracleAS Web Cache's architecture. This capability allows OracleAS Web Cache to load-balance requests across multiple application servers and to provide automatic failover when an application server instance fails.

Sometimes, a web site is supported by more than one application server. In this situation, a single OracleAS Web Cache instance can manage requests for pages from as many as 100 application servers, and load-balance among them.

OracleAS Web Cache automatically sends requests to the origin server with the most available resources. The quantity of available resources for a particular origin server is determined by the workload and capacity for the server. The workload is based on the number of active connections to the origin server. An OracleAS Web Cache administrator establishes the maximum number of connections for each origin server. The available resources are determined by subtracting the workload from the capacity. If all origin servers have an equal capacity, OracleAS Web Cache uses a Round-Robin method to assign new connections.

If a connection request or a configurable number of read/write requests to an origin server fails, OracleAS Web Cache considers the server unavailable. For an unavailable server, existing requests for documents return errors, but subsequent requests to the server are failed-over to another origin server. The capacity of the failed server is assigned to the failover server. Once the failed server responds to a request to a designated URL on the server, the server is considered available, and capacity for the server is reassigned to it.

The operations we've described so far make sense for stateless requests; one origin server is as good as any other. But what about stateful requests that depend upon earlier interactions with the failed origin server? Stateful transactions require server affinity to emulate persistent connections to a server, such as for use with a shopping cart.

You can configure OracleAS Web Cache to perform stateful load balancing using session binding . Session binding requires that the origin server use cookies and session IDs to indicate server affinity for a particular request. This is done automatically by Oracle Application Server. Server affinity ensures that a stateful request will consistently return to the server that is maintaining its state.

If a request requires a connection to a particular origin server, but that server is already handling maximum capacity, the session binding for that request is disabled, and an error message is returned to the user.


7.1.3.2 Multiple instances of OracleAS Web Cache

Multiple instances of OracleAS Web Cache can be used together, either in a cluster or in a failover configuration. In both configurations, you can use a hardware load balancer in front of OracleAS Web Cache instances, as shown in Figure 7-3. In addition, in both configurations, the load balancer recognizes a single logical OracleAS Web Cache and balances requests across the instances.

Figure 7-3. Multiple instances of OracleAS Web Cache
figs/oas_0703.gif

OracleAS Web Cache can be configured to automatically restart an instance if a failure has been detected . If you have installed OracleAS Web Cache as part of a complete Oracle Application Server installation, the Oracle Process Manager and Notification Server monitors the health of an OracleAS Web Cache instance and performs the restart when necessary. If you have installed OracleAS Web Cache as a standalone product, a watchdog process restarts the instance. This process can be disabled if desired.

You can configure a hardware load balancer to send only HTTP or HTTPS requests to an instance of OracleAS Web Cache. For example, you might designate an OracleAS Web Cache instance to receive only HTTPS requests if you are going to use some type of SSL accelerator hardware only on that machine.

You can use an L7 switch to route requests to OracleAS Web Cache or an origin server via the Application Layer (Layer 7) of the OSI model. This configuration might make sense if there are certain types of content that you don't want to cache ”for example, protected or transactional content ”so you would want to completely bypass the OracleAS Web Cache servers.

7.1.3.3 Clustering

Multiple instances of OracleAS Web Cache can also be combined into a cache cluster . A cache cluster uses the same basic hardware configuration used for unclustered, multiple instances of OracleAS Web Cache, but it offers some additional functionality as well.

A cache cluster is a group of cache instances that look like a single cache. A cache cluster still requires the use of a hardware or software load balancer, as described earlier. All the instances in the cluster use the same common configuration information, such as site definitions and caching rules, and receive the same invalidation messages.

In a cluster configuration, OracleAS Web Cache instances can periodically ping each other to determine whether they are still alive , or can wait for either a connection request failure or a designated number of read and write request failures to demonstrate that an instance is no longer alive.

You can dynamically add OracleAS Web Cache instances to an established cache cluster, although you do have to restart the cluster for the new member to be included. Each member of the cluster is assigned a relative capacity, and document ownership is distributed among the instances based on their relative capacity.

Requests are handled as follows for a cache cluster:

  • If a request comes into a cache instance for a document it owns, it works just like a single cache instance.

  • If a request comes into a cache instance for a document that is owned by another instance, the cache instance passes the request off to the owning instance.

  • If a cache instance doesn't respond to a request for a document in a specified length of time, the requesting instance assumes that the other instance has failed. When this occurs, the documents owned by the failed instance are redistributed to the remaining instances according to their designated capacity.

In the last case, the other instances of the OracleAS Web Cache cluster periodically ping a specified URL for the failed server so that they will recognize when the instance rejoins the cluster. When an instance rejoins the cluster, document ownership is again redistributed according to the new relative capacities of the available instances. Keep in mind that while document ownership is redistributed, document content isn't. The new instance will retrieve a document that it now owns once the document is requested .

Although each document is owned by a single cache instance, the content may be needed by other instances. Once the content is requested and returned to another instance, the requesting server caches the content itself, so future requests to that server won't require a redirection. In this way, the same popular content may be contained in multiple cache instances.

The upshot of this design is that the most popular objects in an OracleAS Web Cache cluster are most resilient to the failure of an individual OracleAS Web Cache instance because popular objects typically reside in more than one instance and don't have to be refreshed if one instance fails.

Some operating systems ”for example, some flavors of Windows 2000 and Windows 2003 ”include the ability to load-balance requests across nodes in an operating system-defined cluster. In such a configuration, the operating system also recognizes node failure and uses automatic IP takeover in the event of a failure.

A cache cluster offers a number of benefits not provided by unclustered, multiple instances of OracleAS Web Cache, including:


Increased scalability

Multiple instances of OracleAS Web Cache can be combined for greater caching capability, but without increasing the number of content requests to the origin server.


Improved maintenance

Maintenance is easier because all members of a cache cluster share the same configuration, and one member typically receives a single invalidation message. In addition, you can add members to, or remove members from, a cache cluster without having to worry how it will affect management overhead.

7.1.3.4 Hierarchies

You can use hierarchies of OracleAS Web Cache in two basic configurations:


Remote Cache Deployment

One configuration of OracleAS Web Cache implements enterprise content delivery networks with Remote Cache Deployment. In this configuration, OracleAS Web Cache can provide better response time by caching frequently used content closer to the eventual user of the data, such as in a remote location or LAN segment, as shown in Figure 7-4.

Figure 7-4. Using OracleAS Web Cache as Remote Cache Deployment
figs/oas_0704.gif


Edge Side Includes

A second type of hierarchy uses instances of OracleAS Web Cache on ESI providers (described later) and an instance of OracleAS Web Cache on a subscriber machine, which assembles the ESI fragments into a web page. This type of hierarchy is especially appropriate for an OracleAS Portal deployment, in which complete pages are assembled from different sources. OracleAS Portal is described in detail in Chapter 13.

When you configure a cache hierarchy, the origin servers for the upstream caches, such as the ESI subscriber machine, are the downstream instances of OracleAS Web Cache. If you can't specify a site definition for an ESI provider machine, and there is a firewall between the subscriber instance and the unknown ESI provider, you must configure a proxy server because OracleAS Web Cache uses DNS to locate undefined ESI providers.

7.1.4 Types of Caching

Three different types of information can be cached in OracleAS Web Cache: static HTML pages, dynamic HTML pages, and page fragments.

7.1.4.1 Static page caching

For static pages, the use of OracleAS Web Cache is straightforward. If a document is cacheable, it is placed in the cache until it becomes invalid, either through receipt of an invalidation message or after a request for the document comes in and the caching rules indicate that it has expired .

Static pages are swapped out of OracleAS Web Cache if the cache becomes full, and the garbage-collection process selects the page as a candidate for removal, as described earlier.

7.1.4.2 Dynamic page caching

Dynamic pages are pages that can have different content for different situations or different users. These pages can be generated using a variety of scripting and programming languages and modules. Examples include JSPs, Active Server Pages (ASPs), PL/SQL Server Pages (PSPs), Java servlets, and CGI calls.

Sometimes these dynamic pages are completely unique. In these cases, OracleAS Web Cache would have to potentially cache each individual page. Frequently, though, pages are very similar, with only some different areas. In some scenarios, described in the following subsections, OracleAS Web Cache can substitute dynamic values or to recognize when a page can be reused for multiple users.

In other scenarios, developers can combine some static objects with dynamic objects by caching portions of an overall page.

7.1.4.2.1 Multiple versions for a single URL

Some web sites create different versions of the same page for different sets of users. These sites either use a cookie with an identifying value or encode the value in the URL.

If a cookie is used, the value for the cookie is passed back from the origin server in the Set-Cookie response header, which is stored with the document. When a subsequent request comes in with a value in the corresponding Cookie request header, OracleAS Web Cache returns the appropriate page. OracleAS Web Cache can also use values in request-header fields to determine which version of a page to return.

If appropriate, you can configure OracleAS Web Cache to ignore embedded URL parameters when determining which page to return. This approach avoids the requirement to cache every version of a web page with distinct URL embedded information, such as a session ID. You can also configure OracleAS Web Cache to ignore POST body parameters, as discussed in the next section.


You can use multiversion caching to support different cached pages for different types or groups of browsers. This technique allows you to build in flexible pages for different browsers while still taking advantage of OracleAS Web Cache.

7.1.4.2.2 Personalization in a page

You can specify personalization information in a web page with special OracleAS Web Cache HTML tags. When OracleAS Web Cache receives a request for the page, the specified information is retrieved from a cookie, from a URL embedded parameter, or from POST body parameters.

When you specify the attribute that will be used for personalization, you can also specify whether to return the page for requests that are missing the attribute, or what to use in place of the attribute for pages missing a value.

7.1.4.2.3 Session-encoded URLs

Some web pages use session-specific information in internal hyperlinks. You can also configure OracleAS Web Cache to substitute session values in hyperlinks that use session-encoded URLs. As with personalization attributes, you can specify how OracleAS Web Cache should handle a request with missing session information.

7.1.4.3 Partial page caching

As mentioned earlier, some pages combine static objects, such as a page template and logos, with dynamic objects. These pages use ESI tags to indicate where the dynamic objects are located on the page and where to get their content.

ESI tags were originally introduced by Oracle and Akamai, and are on the standards track for the World Wide Web Consortium (W3C).


OracleAS Web Cache can work with both include fragments, which are always fetched , and inline fragments, which are identified with a unique name and can be reused by multiple pages without refetching.

OracleAS Web Cache can cache page fragments independently, with each fragment having its own validation rules. This method allows OracleAS Web Cache to cache individual fragments, which can be used in many different pages. Each fragment has its own set of validation rules; these rules can use the same information and logic as a rule for an entire page. This separation means that an individual fragment doesn't have to be re-fetched every time a page requiring the fragment is requested.

For instance, you can have the template and logos for a page cached indefinitely, the news for the day cached for several hours, and stock prices not cached at all. By separating all these fragments into separate ESI fragments, OracleAS Web Cache can intelligently refresh the fragments as appropriate. ESI tags can use XML stylesheets to transform content into HTML.

When you configure the origin servers that OracleAS Web Cache will access, you can specify that the site is an ESI provider only, which prevents browsers from accessing the site directly. You don't have to configure all sites that are ESI providers. However, failing to configure an ESI provider site disables OracleAS Web Cache's capacity heuristics capability, as we discuss in the next section. If there is a firewall between an ESI provider and a OracleAS Web Cache subscriber cache, as described in Section 7.1.3.4, you must configure a proxy server to contact the ESI provider.

For ESI use in JSPs, a set of Java ESI tags, known as JESI tags , can implement ESI fragments more productively. JESI tags will automatically create the surrogate control headers that are used by ESI fragments to determine caching characteristics. By using JESI tags with JSPs, you can use JSP expressions for more flexible implementation of caching rules.

7.1.5 Cache Invalidation

Caching is, of course, nothing new in the world of computing. Databases have long used caches to improve performance. In a database cache, the database uses the concept of least-recently-used (LRU) to swap out blocks of data when the cache becomes full.

In Oracle Application Server, OracleAS Web Cache performs the same type of operation when it becomes full, but there are also other options for removing content from an OracleAS Web Cache instance. Some content stored in OracleAS Web Cache changes frequently, while some rarely changes at all. To handle this breadth of "freshness," OracleAS Web Cache lets you specify when content becomes invalid, which marks it as ready to be discarded from the cache.

Validation is the process of verifying whether an object in OracleAS Web Cache is still valid. Invalidation is the process used to flag an object as no longer being available. Invalidating an object doesn't necessarily remove it from the cache. Once an object is put into OracleAS Web Cache, it remains valid until it is marked as invalid.

There are basically two types of invalidation:


Predictable

This type of invalidation can be indicated with an expiration time, either in elapsed time or at a specific time.


Unpredictable

This type of invalidation occurs in response to some other event. Unpredictable invalidation can be implemented with a message, as described later.

There are two ways to indicate that an object is invalid:


Policies

These are evaluated each time a request is made for an object.


Messages

These are sent to OracleAS Web Cache, either manually or programmatically.

If an object in OracleAS Web Cache is marked as invalid, the next request for the object causes OracleAS Web Cache to fetch a fresh version of the object from the origin server.

Just as you assign validation rules to objects and groups of objects, you can mark objects as noncacheable, which means that they are never placed in OracleAS Web Cache.


These techniques are used for the OracleAS Web Cache instance itself to invalidate content. OracleAS Web Cache can use HTTP validators , included in the browser request, to ensure that delivery of cached documents is appropriate. OracleAS Web Cache compares the If-Modified-Since value with the value in the Last-Modified response-header field of the cached document, or compares the If-None-Match validator with the ETag response-header field of the cached document.

OracleAS Web Cache has its own set of caching rules (described later), but it can also accept caching directives, either in the Surrogate-Control response-header field in the object returned from the origin server, or in the HTTP Cache-Control header. If there is a rule in more than one of these areas, the Surrogate-Control rule overrides OracleAS Web Cache rules, which override the HTTP Cache-Control header. If a Surrogate-Control response-header rule is used, additional properties in the OracleAS Web Cache rule, such as compression, can be merged with the rule.

If you are using a hierarchy of caches, the top cache instance in the hierarchy receives the invalidation message and then propagates it to the other downstream caches. If you are using cache instances in a cluster, you can choose either to have a cluster member act as an invalidation coordinator (which propagates invalidation messages) or to send invalidation messages to all members of the cluster.

Invalid objects are removed from OracleAS Web Cache by a garbage-collection process. This process runs when the OracleAS Web Cache instance runs out of space. The garbage-collection process uses a heuristic algorithm to determine which objects to remove, which takes into consideration the popularity of an object (how long it has been since the object was requested), whether an object is invalid, and other considerations. An object is marked as invalid, based on rules and messages, but it isn't discarded from the cache until a garbage-collection process is initiated by the load on the OracleAS Web Cache instance.

7.1.5.1 Cacheability /invalidation rules

You describe the objects that an OracleAS Web Cache instance should cache by specifying caching rules. A caching rule contains four properties:


Selector

Specifies the pages to which a rule applies. The selector contains a URL expression, which could be based on a URL prefix, a file extension type, or a regular expression (for more extensive logical selection). It can also be based on a URL or POST body parameter, or on a POST body expression.


Caching policy

Indicates whether the selected URL should be cached. You can also indicate whether the URL has an expiration policy or whether it should be compressed. An expiration policy uses a time-based indicator, which can work on the amount of time an object is in the cache, on the amount of time since an object was last requested, or on information in the HTTP Expires or Cache-Control response fields.


Cache key policy

Defines what information OracleAS Web Cache uses to create a unique ID for an object. This ID is used to retrieve the object from the cache for subsequent requests. This information can include the site name, the URL of the object, the POST body expressions, the cookie names and values, and the HTTP request header name and values.


Priority

Defines the order of use of the caching rules. If some objects aren't cacheable, this property specifies their rules first to avoid excess overhead.

OracleAS Web Cache comes with some default caching rules, such as one used with OracleAS Wireless. If you don't specify any caching rules, content isn't cached. Even if content isn't cached, OracleAS Web Cache can still be used as a load balancer to multiple origin servers.

7.1.5.2 Invalidation messages

To invalidate an object by a message, an OracleAS Web Cache instance must receive an HTTP POST message from one of two accounts ”the administrator account or the invalidator account. Both accounts are set up at installation time and can be modified with Web Cache Manager. These messages must be received on the invalidation listening port, which is also configured at runtime.

The message contains information presented in XML that identifies the page to be invalidated. There are two types of XML descriptions:


Basic

Lists the identifying URL


Advanced

Uses pattern and range matching to identify a number of different pages

Invalidation messages can be sent in a variety of ways, including:

  • Via Telnet

  • From OracleAS Web Cache Manager

  • Via application logic

  • From database triggers using Oracle's UTL_TCP built-in package

  • With scripting languages

OracleAS Web Cache ships with an API for invalidation messages for Java and PL/SQL. An invalidation message sent by OracleAS Web Cache Manager can include a removal time, which must be later than the invalidation time. This time is used for performance assurance heuristics, discussed in the next section.

If you use ESIs, you can invalidate fragments, based on the retrieval of another inline fragment. For instance, if one inline fragment is invalid, you may want to indicate that the other fragments associated with the document are also invalid.

OracleAS Web Cache sends an HTTP response for all invalidation requests. This response contains a status code indicating the outcome of the request. The application that sent the request can use this information in its own logic.

7.1.5.3 Performance assurance heuristics

Objects in OracleAS Web Cache can be marked as invalid, as explained earlier, but a large number of objects can become invalid at any one time. For example, a bulk application of changes to material used in an online catalog may invalidate all the pages in the catalog. How does OracleAS Web Cache avoid impacting performance when it saturates the origin server with requests for new versions?

The answer is that OracleAS Web Cache uses something called performance assurance heuristics . These heuristics are used to create a queue for refresh requests. If the capacity of the origin application server is exceeded, OracleAS Web Cache uses this queue to keep the number of requests to a more reasonable level. Requests are prioritized in the queue based on two factors:

  • Levels of invalidation defined for the object

  • Popularity of the object

The concept of levels of invalidation is based on the concept of removal time . You can specify a removal time for an object, which indicates how long an invalid object can stay in the cache before it is removed. The greater the time since an object has been invalidated, the staler it is. There may be multiple levels of staleness.

For example, a web page may contain the following:

  • A logo, which is static

  • A news feed, which should be updated on a regular basis

  • An account balance, which must always be up to date

If OracleAS Web Cache determines that refresh requests are overwhelming the origin server, it can assemble the page with a stale version of the news feed item, but not the account balance. The only real consequence of this decision for the user is that it provides slightly older news content, while providing better performance for all users.

If objects are equally stale, OracleAS Web Cache uses popularity ratings to remove the least-requested object. In this way, OracleAS Web Cache can smooth out the performance it delivers, regardless of the number of objects that are invalid at any one time. In addition, you can use this feature to help address issues associated with surges of traffic. By designating some content as acceptable for stale delivery, you allow OracleAS Web Cache to automatically throttle back its requests as demand grows.

7.1.6 Compression

OracleAS Web Cache uses the standard GZIP compression algorithm to reduce the size of pages returned to the browser ( assuming that the requesting browser supports this type of compression). On average, OracleAS Web Cache compression can reduce the size of compressed documents by 75%. A compressed document may contain both cached and noncached elements, or may be a complete page that has not been cached. OracleAS Web Cache itself stores content in a compressed format to save caching space.

If the HTTP header for a request indicates that a browser can expand compressed content, OracleAS Web Cache compresses the content before returning it, reducing bandwidth requirements and potentially improving response time. Most browsers have supported the GZIP algorithm since 1997. However, OracleAS Web Cache caches both compressed and uncompressed version of objects, and returns whichever is appropriate.

You indicate whether you want content to be compressed by supplying the appropriate information in the cacheability rules you specify to select the content. Because these rules allow the use of regular expressions for evaluating cacheability, you can use the same flexible expressions to determine whether content is to be compressed. If the origin server has already compressed content, OracleAS Web Cache recognizes this in the response header and does no further compression.

If you are using a hierarchy of caches, you should configure the OracleAS Web Cache closest to the origin server to compress content, and configure the downstream OracleAS Web Cache instances so that they don't compress. This approach delivers the compressed content early on in the flow of the response, and consequently, the transmission benefits over the greatest distance.

7.1.7 Administration

There are three ways to start an OracleAS Web Cache instance:

  • Through the command line, using the OPMN Server

  • Through OracleAS Web Cache Manager

  • Through Application Server Control

Of the three, OracleAS Web Cache Manager (shown in Figure 7-5) is the tool most often used to manage OracleAS Web Cache instances. This tool is the interface to the management process for OracleAS Web Cache, which in turn must be running to use the Manager.

Figure 7-5. Sample OracleAS Web Cache Manager page
figs/oas_0705.gif

You can use OracleAS Web Cache Manager to start and stop OracleAS Web Cache instances, administer invalidation or rollover log files, monitor performance and activity, and configure OracleAS Web Cache instances. You can also use the OracleAS Web Cache Manager to associate specific caching rules with URLs or sets of URLs. In addition, you can create and view caching rules with this tool, as well as edit some of the attributes of the rules, such as expiration policies, compression, and the content of HTTP request headers.

Most changes specified through OracleAS Web Cache Manager aren't applied until an OracleAS Web Cache instance is restarted. However, some of the changes do take effect as soon as the changes are saved. Such changes include setting levels of detail for the event logs, changing the buffering for event logs and access logs, enabling and disabling the inclusion of diagnostic information in the HTML response body, and setting routing to origin servers.

OracleAS Web Cache Manager tracks whether other members of a cache cluster have a different configuration and allows you to bring those members' configuration into conformance. Once you have matched the configurations, you can restart all instances of a cluster with a single button push. You can also choose to stagger the restart of the instance to reduce the impact on operations.

7.1.7.1 Monitoring OracleAS Web Cache

OracleAS Web Cache Manager can display a list of the most popular documents, based on the number of requests and the most recently received requests. This list can be limited to either cached documents or noncached documents. You can also get a listing of all documents in the cache at the present time, but this list is saved to a file.

To highlight potential performance improvements, OracleAS Web Cache Manager can give you a list of the most popular documents that return cache misses, which provides the information you need to adjust caching rules to reduce the number of misses.

OracleAS Web Cache uses an event log to record events and errors. Events include cache hits, cache misses, and invalidations. Events can be recorded with details of the request that triggered the events, such as the IP address of the browser that made the request and details about the site and URL of the request.

Event log files are periodically rolled over, with the old log file stored. Rollover intervals can be configured to once a week, once a day, hourly, or never. Starting with Oracle Application Server 10 g , you can set the level of detail in the OracleAS Web Cache log.

OracleAS Web Cache Manager displays information about the overall health and operations of an OracleAS Web Cache instance. The information includes health and utilization statistics for the instance, error and invalidation statistics, requests for each origin server supported by the instance, and information about fresh and stale documents that have been served from the cache.

For troubleshooting purposes, OracleAS Web Cache includes diagnostic information in the HTTP Server response-header fields by default. If you choose to do so, you can have this information added to the response body.

7.1.7.2 OracleAS Web Cache and performance monitoring

In addition to the event log mentioned in the previous section, OracleAS Web Cache also keeps an access log, which tracks information about HTTP requests sent to it. OracleAS Web Cache can be configured to use its access log to determine user response times for HTTP requests because the access log includes information about the elapsed time from a request to its response.

The access log can be analyzed through OracleAS Web Cache Manager and can be output into either an HTML file or a comma-separated file for import into a spreadsheet or database. The access log can also be used more fully by Oracle Enterprise Manager 10 g 's Application Service Level Management feature, which ships with Grid Control, a web-based tool described in Chapter 3. ASLM helps administrators to understand the actual performance their end users are receiving by tracking the time it takes for a response to an end-user request to be returned to the user. The OracleAS Web Cache access logs are used to track time ”from the time a request comes into OracleAS Web Cache until the time the response is returned to the user. ASLM can't be used without these access logs, so OracleAS Web Cache contributes substantially to the overall management capabilities of Oracle Enterprise Manager 10 g .

   


Oracle Application Server 10g Essentials
Oracle Application Server 10g Essentials
ISBN: 0596006217
EAN: 2147483647
Year: 2004
Pages: 120

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net