|
Oracle® Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) B14046-05 |
|
 Previous |
 Next |
|
Oracle® Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) B14046-05 |
|
|
Previous |
Next |
This chapter describes the performance barriers faced by Web sites and introduces the technology that can provide a complete caching solution.
This chapter contains these topics:
The Web-based computing model creates new performance challenges for application developers and administrators. To carry out e-business successfully, Web sites must protect against poor response time and system outages caused by peak loads. Slow performance translates into lower productivity and lost revenue.
Many administrators try to counter this problem by adding more application Web servers to their existing architecture. As more users access these Web sites, more and more servers will have to be added. In short, the hardware and manageability costs associated with adding servers often outweigh the benefits.
Static caches and content distribution services can provide some relief. However, these solutions are unable to serve content that is dynamically generated. Developers spend time writing custom caching solutions.
Faced with these performance challenges, e-businesses need to invest in more cost-effective technologies and services to improve the performance of their applications. Oracle offers OracleAS Web Cache to help e-businesses manage Web site and Web-based application performance issues. OracleAS Web Cache is a content-aware server accelerator, or reverse proxy, that improves the performance, scalability, and availability of Web sites that run on Oracle Application Server.
By storing frequently accessed URLs in memory, OracleAS Web Cache eliminates the need to repeatedly process requests for those URLs on the application Web server and database tiers. Unlike legacy proxies that handle only static objects, OracleAS Web Cache caches both static and dynamically generated content from one or more application Web servers. Because OracleAS Web Cache is able to cache more content than legacy proxies, it provides optimal performance by greatly reducing the load on application Web server and database tiers. As an external cache, OracleAS Web Cache is also an order of magnitude faster than object caches that run within the application tier.
Figure 1-1 shows the basic architecture. OracleAS Web Cache sits in front of application Web servers, caching their content, and providing that content to clients that request it. When Web browsers access the Web site, they send HTTP protocol or HTTPS protocol requests to OracleAS Web Cache. OracleAS Web Cache, in turn, acts as a virtual server on behalf of the application Web servers. If the requested content has changed, OracleAS Web Cache retrieves the new content from the application Web servers. The application Web servers may retrieve their content from an Oracle database. OracleAS Web Cache can be deployed on its own dedicated tier of computers or on the same computer as the application Web servers.
Figure 1-1 OracleAS Web Cache Architecture
|
Note: OracleAS Web Cache is compatible with Oracle HTTP Server or any other HTTP-compliant application Web server. See Appendix D for further information about third-party application Web server support. |
As a reverse proxy, OracleAS Web Cache acts a gateway to the backend servers. Figure 1-2 shows how OracleAS Web Cache acts a reverse proxy cache for a backend application Web server. OracleAS Web Cache has an IP address of 144.25.190.241 and the application Web server has an IP address of 144.25.190.242. The steps for browser interaction with OracleAS Web Cache follow:
A browser sends a request to a Web site named www.company.com:80.
This request in turn generates a request to Domain Name System (DNS) for the IP address of the Web site.
DNS returns the IP address of the load balancer for the site, that is, 144.25.190.240.
The browser sends the request for a Web page to the load balancer. In turn, the load balancer sends the request to OracleAS Web Cache server 144.25.190.241.
If the requested content is in its cache, then OracleAS Web Cache sends the content directly to the browser. This is called a cache hit.
If OracleAS Web Cache does not have the requested content or the content is stale or invalid, it hands the request off to application Web server 144.25.190.242. This is called a cache miss.
The application Web server sends the content to OracleAS Web Cache.
OracleAS Web Cache sends the content to the client and stores a copy of the page in cache.
|
Note: OracleAS Web Cache marks an object stored in the cache for removal when it becomes invalid or outdated, as described in "About Cache Consistency and Performance Assurance". |
If you do not require caching support, you can configure OracleAS Web Cache solely as a software load balancer or reverse proxy. You configure OracleAS Web Cache settings for this mode.
Web caching provides the following benefits for Web-based applications:
Running on inexpensive hardware, OracleAS Web Cache can increase the throughput of a Web site by several orders of magnitude. In addition, OracleAS Web Cache significantly reduces response time to client requests by storing objects in memory and by serving compressed versions of objects to clients that support the GZIP encoding method.
In addition to unparalleled throughput, OracleAS Web Cache can sustain thousands of concurrent client connections, meaning that visitors to a site see fewer application Web server errors, even during periods of peak load.
OracleAS Web Cache supports load balancing and failover detection for application Web servers. These features ensure that cache misses are directed to the most available, highest-performing Web server in the server farm. Moreover, a patent-pending capacity heuristic guarantees performance and provides surge protection when the application Web server load increases.
Better performance, scalability and availability translates into cost savings for Web site operators. Because fewer application Web servers are required to meet the challenges posed by traffic spikes and denial of service attacks, OracleAS Web Cache offers a simple and inexpensive means of reducing a Web site's cost for each request.
Application developers can use OracleAS Web Cache to cache content rather than design and develop application-specific caches.
The features of OracleAS Web Cache make it a perfect caching service for e-business Web sites that host online catalogs, news services, and portals. These features include:
Caching rules determine which objects OracleAS Web Cache caches. Rules fall into three categories:
Rules for static content, such as GIF, JPEG, or static HTML files.
Rules for dynamically generated content created using technologies like JavaServer Pages (JSP), Active Server Pages (ASP), PL/SQL Server Pages (PSP), Java servlets, PHP Hypertext Preprocessor (PHP), and Common Gateway Interface (CGI). Support of these technologies enables OracleAS Web Cache to recognize rules for the following:
Multiple-version objects for the same URL, that is, the same URL with slightly different content
Session-aware rules for pages containing session information
Personalization rules for pages containing personalized greetings, such as "Welcome Name," and session-encoded URLs
Pages that require personalized content assembly of dynamic Edge Side Includes (ESI) fragments.
|
See Also:
|
OracleAS Web Cache supports invalidation as a mechanism to keep the cache consistent with the content on the application Web servers. Administrators can invalidate cache content in one of three ways:
Manual methods, including OracleAS Web Cache Manager or telnet
Automatic methods with database triggers, scripts, or application logic
Inline invalidation implemented as part of ESI template pages
When objects are invalidated and a client requests them, OracleAS Web Cache refreshes them with new content from the application Web server.
In addition to invalidation, OracleAS Web Cache provides expiration, whereby an expiration time limit is assigned to the objects. When an object expires, OracleAS Web Cache treats it like an invalid object. If the object is requested by a client, OracleAS Web Cache refreshes it with updated content from the application Web server.
|
See Also: "About Cache Consistency and Performance Assurance" for further information about invalidation and expiration |
When a large number of objects have been invalidated, the retrieval of a new object can result in overburdened application Web servers.
To handle performance issues while maintaining cache consistency, OracleAS Web Cache uses built-in performance assurance heuristics that enable it to assign a queue order to objects. These heuristics determine which objects OracleAS Web Cache can serve stale and which objects to refresh immediately. OracleAS Web Cache refreshes objects with a higher priority first and objects with a lower priority at a later time.
OracleAS Web Cache bases the queue order of objects on popularity and validity assigned during invalidations. If the current load and capacity of the application Web server is not exceeded, then OracleAS Web Cache refreshes the most popular and least valid objects first.
|
See Also: "About Cache Consistency and Performance Assurance" for further information about performance assurance |
OracleAS Web Cache caches and assembles dynamic content for one or more Web sites. From the perspective of OracleAS Web Cache, a site can be either a virtual host site or an ESI provider site. Depending on the site category, you can configure OracleAS Web Cache to perform different functions.
This section covers the following topics:
Virtual host sites are sites hosted by OracleAS Web Cache. In other words, clients can request cached content from these sites through OracleAS Web Cache. Figure 1-3 shows OracleAS Web Cache caching content for two sites, www.1st.company.com and www.2nd.company.com. An additional mapping of www.*.company.com uses *, enabling additional virtual sites that map to host4 and host5 to be added. In addition to caching content, OracleAS Web Cache can also assemble ESI fragments from these sites.
ESI provider sites are those sites that OracleAS Web Cache contacts for ESI assembly only. Browsers are not allowed to request content from these sites.
Figure 1-4 shows an ESI provider site configuration. In this configuration, OracleAS Web Cache receives a request for a page with ESI markup tags. OracleAS Web Cache sends the request to the application Web server. The application Web server uses an application to create a template page and sends it back to OracleAS Web Cache for assembly. OracleAS Web Cache includes the ESI fragments for the template page either with a cached copy of the contents or by contacting the following for that fragment's contents:
Provider site www.providersite1.com
Another OracleAS Web Cache server, which is caching content for www.providersite2.com
|
See Also: "About Edge Side Includes (ESI) for Partial Page Caching" for further information about ESI |
In order for OracleAS Web Cache to recognize a virtual host site or an ESI provider site, administrators need to perform the following steps:
Create a site definition that includes all the names and listening port numbers of the site that clients specify.
If two sites share the same host name, specify a URL path prefix to distinguish the sites.
Determine if OracleAS Web Cache communicates with application Web servers or proxy servers.
OracleAS Web Cache uses application Web servers for internal sites and proxy servers for external sites outside a firewall.
Specify the host name and listening port number of the application Web server or proxy server.
To ensure requests are sent to the appropriate server, map the site to the application Web servers or proxy servers.
Order the mappings. For each request, the first matching mapping is used.
Because mappings that use the wildcard * encompass a broader scope, give these mappings a lower priority than other mappings.
Because requests are resolved to the first matching mapping, give mappings that contain the optional URL path prefix a higher priority than those mappings without an URL path prefix.
For example, you should order the following mappings as follows:
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox http://www.company.com
If you instead reorder the mappings as follows, the request for URLs http://www.company.com/portal/page?_pageid=33,4232&_dad=portal and http://www.company.com/um/traffic_cop?mailid=inbox will never be reached. Requests for these URLs will instead resolve to http://www.company.com because it is listed first:
http://www.company.com http://www.company.com/portal/page?_pageid=33,4232&_dad=portal http://www.company.com/um/traffic_cop?mailid=inbox
Create caching rules that apply to the site and global rules that apply to all sites.
The site-specific caching rules are given a higher priority than the global rules.
To further understand the mappings, reconsider Figure 1-3. Web sites www.1st.company.com:80 and www.2nd.company.com:80 can have site aliases of 1st.company.com:80 and 2nd.company.com:80, respectively. The site to application Web server mappings are as follows:
www.1st.company.com maps to application Web servers host1 and host2
www.2nd.company.com maps to application Web servers host2 and host3
www.*.company.com maps to host4 and host5
When OracleAS Web Cache receives a client request for an object, it determines the destination site using one of the following elements:
Host request-header field from the request
Host portion of the requested URL
src attribute of the ESI <esi:include> tag
OracleAS Web Cache then looks up the configured site settings and mappings to determine if the site is supported, and the origin servers and caching rules for the site. If there are no site settings and mappings for external ESI provider sites, OracleAS Web Cache uses Domain Name System (DNS) to resolve the site name.
If the request does not include host information, then OracleAS Web Cache sends the request to the default site. The default site definition includes the site host name and port information. After an Oracle Application Server installation, a default site definition that includes the host name and listening port of the Oracle HTTP Server is established. If you choose to configure another site as the default site that includes a URL path prefix, the prefix is excluded in matching requests to the site. For example, if you specify a default site of www.company.com and a URL path prefix of /portal, requests are matched for www.company.com, not www.company.com/portal.
To increase the availability and scalability 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 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 Web caches, more content can be cached and more client connections can be supported, expanding the capacity of your Web site.
Many Web-based applications mirror their Web sites in strategic geographical locations. You can deploy multiple instances of OracleAS Web Cache in a cache hierarchy so that a local cache stores content from a cache in a central data center for a local market. This enables caches serving local requests to shorten response time and reduce bandwidth and rack space costs for the content provider.
OracleAS Web Cache provides supports two kinds of cache hierarchies:
A distributed cache hierarchy in which a central cache acts as an application Web server to a remote cache.
An ESI cache hierarchy in which a provider cache acts as an application Web server to a subscriber cache.
In place of an individual OracleAS Web Cache server in a hierarchy, you can deploy a cache cluster.
A distributed cache hierarchy centralizes the management of application logic and data to the central cache and provides remote assembly and delivery of content. Compared with full-scale mirroring and database replication, a distributed cache hierarchy provides a more cost-effective model of distributed computing.
The remote cache is configured with the central cache as its application Web server. When the remote cache requests content from the central cache to serve a request, the remote cache identifies itself as an OracleAS Web Cache to the central cache during a transparent registration process. After registration is complete, the central cache establishes a hierarchical relationship with the remote cache. Registration also enables invalidation messages to be propagated from the central cache to the remote cache.
Figure 1-5 depicts a distributed cache hierarchy. A central cache resides in the United States office and a remote cache resides in Japan. While the central cache in United States stored content retrieved from an application Web server, the remote cache in Japan stores retrieved content from the central cache.
In an ESI cache hierarchy, the subscriber cache is configured with the provider caches as its application Web servers. When the subscriber cache requests content from the provider caches for ESI assembly, the subscriber cache identifies itself as an OracleAS Web Cache server to the provider caches during a transparent registration process. After registration is complete, the provider caches establish a hierarchical relationship with the subscriber cache. Registration also enables invalidation messages to be propagated from the provider caches to the subscriber cache.
Figure 1-6 depicts an ESI cache hierarchy. A subscriber cache performs ESI assembly. Provider caches locally store ESI fragments for ESI provider sites www.providersite1.com and www.providersite2.com. During ESI page assembly, the subscriber cache contacts the provider caches for the ESI fragments. By storing the ESI fragments locally on the provider caches, fragments are stored both by the provider and subscriber caches. This provides for quick page assembly.
|
See Also:
|
OracleAS Web Cache provides the following features for the application Web server and proxy server it supports:
Where applicable, the term origin server is used in place of application Web server or proxy server to simplify the concepts presented in this section.
OracleAS Web Cache passes requests for non-cacheable, stale, or missing objects to origin servers. To prevent an overload of requests on the origin servers, OracleAS Web Cache has a surge protection feature that enables you to set a limit on the number of concurrent requests that the origin servers can handle. When the limit is reached, subsequent requests are queued. If the queue is full, then OracleAS Web Cache rejects the request and serves a site busy error page to the client that initiated the request.
Most Web sites are served by multiple origin servers running on multiple computers that share the load of HTTP and HTTPS requests. All requests that OracleAS Web Cache cannot serve are passed to the origin servers. OracleAS Web Cache balances the load among origin servers by determining the percentage of the available capacity, the weighted available capacity of each origin server. OracleAS Web Cache sends a request to the origin server with the most weighted available capacity. The weighted available capacity is determined by the following formula:
(Capacity - Load) / Capacity
where:
Capacity is the maximum number of concurrent connections that the origin server can accept
Load is the number of connections currently in use
If the weighted available capacity is equal for multiple origin servers, OracleAS Web Cache sends requests to the origin servers using round robin. With round robin, the first origin server in the list of configured servers receives the request, then the second origin server receives the second request. If the weighted available capacity is not equal, OracleAS Web Cache sends the request to the origin server with the most available capacity.
If the load of origin servers is equivalent, OracleAS Web Cache continues to use round robin, even when capacity is not equal for origin servers. Therefore, it is possible to see an even distribution of requests to origin server when the capacities are not configured to be the same.
To configure load balancing for a site, set the capacity of each origin server, and create one site-to-server mapping that maps all the applicable origin servers to the site.
|
See Also:
|
Figure 1-7 shows two sites, www.company.com:80 and www.server.com:80. The site www.company.com:80 is supported by application Web servers company1-host and company2-host with capacities of 50 each. The site www.server.com:80 is supported by application Web servers server1-host, server2-host, and server3-host with capacities of 150, 50, and 50, respectively.
Assuming all application Web servers have an initial load of 0, the requests to www.company.com:80 and www.server.com:80 will be distributed in the following manner:
The requests to www.company.com:80 are distributed between the two origin servers using round robin.
The requests to company1-host and company2-host will be distributed between the two origin servers so that they maintain an equal load. The first request is sent to company1-host. The second request is sent to company2-host if company1-host is still processing the first request. The third and subsequent requests are sent to the origin server that has the highest weighted available capacity.
When the capacities are equal, OracleAS Web Cache uses round robin to distribute requests.
The requests to www.server.com:80 are distributed between three origin servers using the weighted available capacity percentage.
The first request to www.server.com:80 is sent to server1-host, because it is the first in the configured list. The second request is sent to server2-host, because server1-host is still processing the first request and has a weighted available capacity of 99.3 percent and server2-host has a weighted available capacity of 100 percent. The third request is sent to server3-host because server2-host is still processing a request and has a weighted available capacity of 98 percent and server3-host has a weighted available capacity of 100 percent. The fourth request is sent to server1-host because server2-host and server3-host are still processing requests and have weighted available capacities of 98 percent. The fifth request is sent to server1-host because its weighted available capacity is 98.6 percent, which is still greater than server2-host and server3-host, respectively.
When the capacities and loads are not equal, OracleAS Web Cache uses the weighted available capacity to distribute requests. If requests were processed before new requests came in, then it is possible for all three origin servers to have loads of 0. In this case, OracleAS Web Cache uses round robin.
If you do not require caching support and need a low-cost solution to a hardware load balancer, 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.
After a specified number of continuous request failures, OracleAS Web Cache considers an origin server as failed. When an origin server fails, OracleAS Web Cache automatically distributes the load over the remaining origin servers and polls the failed origin server for its current up or down status until it is back online. Existing requests to the failed origin server result in errors. However, new requests are directed to the other origin servers. When the failed server returns to operation, OracleAS Web Cache includes it in its weighted available capacity to load balance requests.
The failover feature is shown in Figure 1-8. An outage of server3-host, which had a capacity of 50, results in 75 percent of requests being distributed to server1-host and 25 percent request being distributed to server2-host.
OracleAS Web Cache supports applications that use a session ID or session cookie to bind user sessions to a given origin server in order to maintain state for a period of time. To utilize the session binding feature, the origin server itself must maintain state, that is, it must be stateful. An application binds user sessions by including session data in the HTTP header or body it sends to a client in such a way that the client is forced to include it with its next request. This data is transferred between the origin server and the client through OracleAS Web Cache either with an embedded URL parameter or through a cookie, which is a text string that is sent to and stored on the client. OracleAS Web Cache does not process the value of the parameter or cookie; it simply passes the information back and forth between the origin server and the client.
Figure 1-9 shows how OracleAS Web Cache supports objects that use session binding.
The steps for how session binding works for requests are as follows:
When a request first comes in, OracleAS Web Cache uses load balancing to determine to which origin server the request is forwarded. In this example, application Web server www.server2.com is selected.
If the requested object requires session binding, the origin server sends the session information back to the client through OracleAS Web Cache in the form of a cookie or an embedded URL parameter.
OracleAS Web Cache sends subsequent requests for the session to the origin server that established the session, bypassing load balancing. In this example, application Web server www.server2.com handles the subsequent requests.
To configure session binding:
Specify a session definition that specifies the name of session cookie or embedded URL parameter.
You can also choose to use one of the default definitions, described in row Session Definitions of Table 8-1.
Specify session binding settings.
In a cache cluster, all cache cluster members must be able to determine which origin server established the session, although the request was routed originally through only one cache cluster member. To configure session binding in a cache cluster, you must enable the Session Binding cookie, which is specific to OracleAS Web Cache. OracleAS Web Cache generates the cookie, which tracks session information so that subsequent requests are bound to the origin server that established the session.
|
Note: If an origin server cannot accept any more connections because of the load, OracleAS Web Cache disables session binding to that origin server and attempts to connect to another origin server. |
You can specify that OracleAS Web Cache compress both cacheable and non-cacheable objects with either OracleAS Web Cache Manager or the compress control directive of the Surrogate-Control response-header field.
OracleAS Web Cache correctly handles compression of different types of content and different types of browsers. For example, OracleAS Web Cache never compresses GIF or ZIP files even if you enable compression. Similarly, OracleAS Web Cache does not compress cascading style sheets for the Netscape 4.x or Internet Explorer 5.5 browsers. With these browsers, compressed cascading style sheets can cause background attributes, such as background images, to not appear in the output.
Because compressed objects are smaller in size, they are delivered faster to browsers with fewer round-trips, reducing overall latency. Compressed content is then expanded by browsers that support the GZIP compression in the Accept-Encoding request-header field.
In a cache hierarchy, the cache closest to the browser, a remote cache in a distributed cache hierarchy or a subscriber cache in an ESI cache hierarchy, does not perform any compression actions on objects. Instead, you configure the cache closest to the origin server, a central cache in a distributed cache hierarchy or a provider cache in an ESI cache hierarchy, to compress non-cacheable objects. By configuring compression on non-cacheable responses from downstream caches, you can ensure content is delivered more effectively to browsers.
Generally, the remote cache in a distributed cache hierarchy or the subscriber cache in an ESI cache hierarchy does not forward the Accept-Encoding request-header field to the origin server. However, if a browser request is for a non-cacheable object, the remote or subscriber cache can send this header to the central or provider cache. In turn, these caches instead compress the object.
On average, OracleAS Web Cache is able to compress text files by a factor of 4. For example, 300 KB files are compressed down to 75 KB.
|
See Also:
|
OracleAS Web Cache provides an auto-restart mechanism that checks that the cache is running and automatically restarts the cache if it is not running.
|
See Also: "Task 3: Configure Auto-Restart Settings" for instructions on enabling or disabling auto-restart |
Table 1-1 describes OracleAS Web Cache compatibility with other Oracle Application Server components.
Table 1-1 Compatibility with Other Oracle Application Server Components
| Component | Description |
|---|---|
|
OracleBI Discoverer is closely integrated with OracleAS Web Cache to improve Discoverer Viewer's overall scalability, performance, and availability. OracleBI Discoverer uses ESI See Also: Oracle Business Intelligence Discoverer Configuration Guide |
|
|
You can deploy OracleAS Web Cache as a load balancer with OracleAS Forms Services applications. See Also: Oracle Application Server Forms Services Deployment Guide |
|
|
OracleAS Web Cache has been closely integrated with OracleAS Portal to improve its overall scalability, performance, and availability. OracleAS Portal ships with a number of pre-defined caching and invalidation policies that ensure optimal use of OracleAS Web Cache. OracleAS Web Cache controls have been built into the OracleAS Portal administrative user interface and can also be specified by content providers through the Portal Developer Kit (PDK). See Also: Sections 5.7, "Configuring OracleAS Web Cache Caching in OracleAS Portal" and 5.8 "Configuring OracleAS Portal to Use a Dedicated OracleAS Web Cache Instance," in Oracle Application Server Portal Configuration Guide for configuration details |
|
|
Applications that use OracleAS Single Sign-On can use OracleAS Web Cache. You can configure OracleAS Web Cache to cache content for Oracle HTTP Servers running Single Sign-On partner applications. While you should not cache content from OracleAS Single Sign-On servers for security reasons, you can configure OracleAS Web Cache as a software load balancer in front of multiple Single Sign-On mid-tiers. See Also: |
|
|
OracleAS Wireless is integrated with OracleAS Web Cache to improve page rendering performance and scalability. It should be noted that OracleAS Web Cache does not understand WAP and is not used by OracleAS Wireless in the traditional sense in that the cache does not "front-end" the wireless server. Instead, the cache is used as a repository for post-transformed content; the wireless runtime determines what content needs to be inserted into the cache and when to expire content in the cache. OracleAS Web Cache, in this case, acts as a device adaptation cache rather than a reverse-proxy cache. Since markup content is cached using OracleAS Web Cache, the performance and scalability benefits are due to two factors—reduced device adaptation costs and significantly reduced adapter invocation costs. The savings in terms of device adaptation costs stem from the fact that content that can be shared across users and sessions is essentially transformed only once (for each logical device) from its Mobile XML format. Secondly, since the content is not generated every time by an adapter, the total adapter invocation cost is significantly reduced for a site that has a large subset of cacheable pages. See Also: Oracle Application Server Wireless Administrator's Guide |
