Release 2.0.0
Part Number A90372-04
 Library |
 Services |
 Contents |
 Index |
| Oracle9iAS Web Cache Administration and Deployment Guide Release 2.0.0 Part Number A90372-04 |
|
This chapter describes the performance barriers faced by Web sites and introduces the technology which can provide a complete caching solution.
This chapter contains these topics:
The e-business model creates new performance requirements for Web sites. To carry out electronic business successfully, Web sites must protect against poor response time and system outages caused by peak loads. Slow performance translates into lost revenue.
Many high-volume Web sites 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 application Web servers will have to be added. In short, the manageability costs associated with adding application Web 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.
Faced with these performance challenges, e-businesses need to invest in more cost-effective technologies and services to improve the performance of their sites. Oracle offers Oracle Web Cache to help e-businesses manage Web site performance issues. Oracle Web Cache is a content-aware server accelerator, or reverse proxy server, that improves the performance, scalability, and availability of Web sites that run on Oracle9i Application Server and Oracle8i.
By storing frequently accessed URLs in memory, Oracle Web Cache eliminates the need to repeatedly process requests for those URLs on the application Web server. Unlike legacy proxy servers that handle only static documents, Oracle Web Cache caches both static and dynamically generated content from one or more application Web servers. Because Oracle Web Cache is able to cache more content than legacy proxies, it provides optimal performance by greatly reducing the load on application Web servers.
Figure 1-1 shows the basic architecture. Oracle Web Cache sits in front of application Web servers, caching their content, and providing that content to Web browsers that request it. When Web browsers access the Web site, they send HTTP protocol or HTTPS protocol requests to Oracle Web Cache. Oracle Web Cache, in turn, acts as a virtual server to the application Web servers. If the requested content has changed, Oracle Web Cache retrieves the new content from the application Web servers. The application Web servers may retrieve their content from an Oracle database.
To Web browsers, Oracle Web Cache acts as the virtual server for application Web servers. You configure Oracle Web Cache with the same IP address that is registered for a site's domain name and the application Web servers' host names. This configuration enables Web browsers to communicate with Oracle Web Cache rather than application Web servers when accessing a Web site.
Figure 1-2 shows how Web caching works. Oracle Web Cache has an IP address of 144.25.190.240 and the application Web server has an IP address of 144.25.190.245. The steps for browser interaction with Oracle Web Cache follow:
www.company.com.
This request in turn generates a request to Domain Name System (DNS) for the IP address of the Web site.
144.25.190.240.
144.25.190.240.
A page stored in the cache is removed when it becomes invalid or outdated, as described in "Cache Freshness and Performance Assurance".
Note:
Web caching provides the following benefits for Web sites:
Running on inexpensive hardware, Oracle Web Cache can increase the throughput of a Web site by several orders of magnitude. In addition, Oracle Web Cache significantly reduces response time to browser requests by storing documents in memory and by serving compressed versions of documents to browsers that support the GZIP encoding method.
In addition to unparalleled throughput, Oracle Web Cache can sustain thousands of concurrent browser connections, meaning that visitors to a site see fewer application Web server errors, even during periods of peak load.
Oracle Web Cache supports content-aware (Layer 4 - Layer 7) load balancing and failover detection. These features ensure that cache misses are directed to the most available, highest-performing Web server in the cluster. Moreover, a patent-pending capacity heuristic guarantees performance and provides surge protection when 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, Oracle Web Cache offers a simple and inexpensive means of reducing a Web site's cost for each request.
Most requests are resolved by Oracle Web Cache, reducing traffic to the application Web servers. The cache also reduces traffic to backend databases located on computers other than the application Web server.
The main features of Oracle Web Cache make it a perfect caching service for e-business Web sites that host online catalogs, news services, and portals. These features include:
Oracle Web Cache uses cacheability rules to store documents. These rules fall into two categories:
See Also:
Oracle Web Cache supports invalidation as a mechanism to keep its cache consistent with the content on the application Web servers, origin databases, or other dynamically generated means.
Administrators can invalidate cache content in one of two ways:
When documents are invalidated and a browser requests them, Oracle Web Cache refreshes them with new content from the application Web server.
When a document expires, Oracle Web Cache treats it like an invalid document, that is, if requested by a browser, it refreshes it with a updated content from the application Web server.
When a large number of documents have been invalidated, the retrieval of a new documents can result in overburdened application Web servers.
To handle performance issues while maintaining cache consistency, Oracle Web Cache uses built-in performance assurance heuristics that enable it to assign a queue order to documents. These heuristics determine which documents can be served stale and which documents must be refreshed immediately. Documents with a higher priority are refreshed first. Documents with a lower priority are refreshed at a later time.
The queue order of documents is based on the popularity of documents and the validity of documents assigned during invalidation. If the current load and capacity of the application Web server is not exceeded, the most popular and least valid documents are refreshed first.
|
See Also:
"Cache Freshness and Performance Assurance" for further information about performance assurance |
Oracle Web Cache passes requests for non-cacheable or stale documents to the application Web servers. To prevent an overload of requests on the application Web servers, Oracle Web Cache has a surge protection feature that enables you to set a limit on the number of concurrent requests that the application Web servers can handle. When the limit is reached, subsequent requests are queued to wait up to a maximum amount of time. If the maximum wait time is exceeded, Oracle Web Cache rejects the request and serves a site busy apology page to the Web browser that initiated the request.
Most Web sites are served by multiple application Web servers running on multiple computers that share the load of HTTP and HTTPS requests. This feature enables Web sites to be built with a collection of servers for better scalability and reliability. Oracle Web Cache is designed to manage requests for up to 100 application Web servers. All requests that Oracle Web Cache cannot serve are passed to the application Web servers. Oracle Web Cache has a load balancing feature that distributes these requests over a set of application Web servers. To configure load balancing, you set the capacity (concurrent connections) for each application Web server. Based on the capacity assigned, Oracle Web Cache prescribes the relative percentage load of each application Web server.
Figure 1-3 shows three application Web servers, whereby 30 percent of traffic goes to www.server1.com, 30 percent goes to www.server2.com, and 40 percent goes to www.server3.com.
|
See Also:
|
After a specified number of continuous request failures, Oracle Web Cache considers an application Web server as failed. When an application Web server fails, Oracle Web Cache automatically distributes the load over the remaining application Web servers based on the remaining proportion. Oracle Web Cache polls the failed application Web server for its current up/down status until it is back online.
The failover feature is shown in Figure 1-4. An outage of www.server3.com, which was receiving 40 percents of requests, results in 50 percent of the requests going to www.server1.com and 50 percent of requests going to www.server2.com. This is based on a 30 percent load for both www.server1.com and www.server2.com. If www.server1.com were to fail instead, based on a 30 percent load for www.server2.com and a 40 percent load for www.server3.com, 42.86 percent of the requests would go to www.server2.com and 57.14 percent of requests would go to www.server3.com.
When the failed server returns to operation, Oracle Web Cache will include it in the load mix as previously prescribed.
Oracle Web Cache supports Web sites that use session IDs and/or session cookies to bind user sessions to a given application Web server in order to maintain state for a period of time. To utilize the session binding feature, the application Web server itself must maintain state, that is, it must be stateful. Web sites bind user sessions by including session data in the HTTP header or body it sends to Web browsers in such a way that the browser is forced to include it with its next request. This data is transferred either with parameters embedded in the URL or cookies, which are text strings stored on the client.
Figure 1-5 shows how Oracle Web Cache supports documents that use application Web server binding:
www.server2.com was chosen.
www.server2.com handles the subsequent requests.
Oracle Web Cache provides the following security-related features:
Oracle Web Cache restricts administration with the following features:
The Secure Sockets Layer (SSL) protocol, developed by Netscape Corporation, is an industry-accepted standard for network transport layer security. SSL provides authentication, encryption, and data integrity, in a public-key infrastructure (PKI). By supporting SSL, Oracle Web Cache is able to cache pages for HTTPS requests.
As shown in Figure 1-6, you can configure Oracle Web Cache to receive HTTPS browser requests. In addition, you can secure connections between the application Web server and the database with SSL.
SSL interacts with the following entities:
A certificate authority (CA) is a trusted third party that certifies the identity of third parties and other entities, such as users, databases, administrators, clients, and servers. The certificate authority verifies the party identity and grants a certificate, signing it with the its private key. The Oracle Web Cache certificate must be signed by a CA.
Different CAs may have different identification requirements when issuing certificates. One may require the presentation of a user's driver's license, while others may require notarization of the certificate request form, or fingerprints of the requesting party.
The CA publishes its own certificate, which includes its public key. Each network entity has a list of certificates of the CAs it trusts. Before communicating with another entity, a given entity uses this list to verify that the signature on the other entity's certificate is from a known, trusted CA.
Network entities can obtain their certificates from the same or different CAs. By default, Oracle Advanced Security automatically installs trusted certificates from VeriSign, RSA, Entrust, and GTE CyberTrust when you install a new wallet (See: Wallet).
A certificate is created when a party's public key is signed by a trusted CA. A certificate ensures that a party's identification information is correct, and that the public key actually belongs to that party.
A certificate contains the party's name, public key, and an expiration date--as well as a serial number and certificate chain information. It can also contain information about the privileges associated with the certificate.
When a network entity receives a certificate, it verifies that it is a trusted certificate--one issued and signed by a trusted certificate authority. A certificate remains valid until it expires or is terminated.
A wallet is a transparent database used to manage authentication data such as keys, certificates, and trusted certificates needed by SSL. A wallet has an X.509 version 3 certificate, private key, and list of trusted certificates.
Security administrators use the Oracle Wallet Manager to manage security credentials on the Oracle Web Cache server. Wallet owners use it to manage security credentials on clients. Specifically, Oracle Wallet Manager is used to do the following:
The authentication process between the browser and Oracle Web Cache consists of the following basic steps:
At the commencement of an HTTPS network connection between a browser and Oracle Web Cache, an SSL handshake is performed. An SSL handshake between the browser and Oracle Web Cache includes the following actions:
Oracle Web Cache provides a graphical user interface tool called Oracle Web Cache Manager that combines configuration and monitoring options to provide an integrated environment for configuring and managing Oracle Web Cache and the Web sites it caches for. With Oracle Web Cache Manager, you can easily:
You can select to have Oracle Web Cache compress both cacheable and non-cacheable documents upon insertion into the cache for browsers. Because compressed documents are smaller in size, they are delivered faster to browsers with fewer round-trips, reducing overall latency. On average, Oracle Web Cache is able to compress text files by a factor of 4. For example, 300 KB files are compressed down to 75 KB.
|
 Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|