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 provides a case study of how Digital River, a global Commerce Service Provider (CSP), deployed Oracle Web Cache, release 1.0.2.
This case study describes the challenges that Digital River faced and the solutions that Oracle Web Cache provided. It describes Oracle Web Cache implementation details, including deployment, cacheability rules, invalidation mechanisms, and overall performance.
This chapter contains these topics:
Founded in 1994, Digital River is a leading global CSP, offering complete e-commerce systems and services to over 8,000 clients. Digital River's commerce services include e-commerce strategy, site development and hosting, order and transaction management, systems integration, product fulfillment and returns, e-marketing, and customer service. Some of Digital River's clients include Symantec, Autodesk, Major League Baseball, MLB Allstar voting, 3M, Polairs, Nabisco Gifts, and H & R Block.
Much of the content delivered by Digital River is dynamically generated. This content consists of pages that support session cookies for identifying users. Once users are identified, they are assigned a promotional campaign that is generated for each page delivered.
Requests were serviced by one of two load balancers running in active-active mode. Two load balancers managed and distributed incoming HTTP and HTTPS requests equally among the application Web servers.
The middle-tier featured two application Web servers that ran Oracle9i Application Server (Oracle9iAS) release 1.0. To ensure high availability, each application Web server was configured with identical content. They are Sun Enterprise 6500 servers, each with 10 GB of RAM and 10 x 336 MHz processors
On the back end, Digital River deployed a primary Oracle8i release 8.1.6 database, as well as standby databases. The primary database ran on a Sun Enterprise 6500 server with 20 GB of RAM and 20 x 336 MHz processors. Pages were generated dynamically with PL/SQL stored procedures, which were invoked with the mod_plsql module on the application Web servers.
The overall deployment is depicted in Figure 11-1.
Digital River currently generates more than 1.5 million page views for each day, a figure that doubles in the last quarter of the year with the holiday shopping rush. While the Digital River deployment provided high availability, it placed the burden of incoming requests on the application Web servers and the backend databases. In fact, due primarily to the dynamic generation of pages, the backend database was sustaining 300 concurrent connections at any given time.
To sustain ever-mounting traffic levels and to support a growing client base, Digital River wanted a more scalable, high-performance application Web server architecture. Digital River considered replacing the Sun Enterprise 6500 servers with more expensive Sun Enterprise 10000 servers, but decided the cost outweighed the benefits. In addition, Digital River wanted to improve overall performance by reducing the burden on the backend databases. In the end, Digital River chose a more scalable application Web server architecture and decided to deploy Oracle Web Cache to reduce the load on the backend databases.
To take advantage of Oracle Web Cache's caching features, Digital River migrated from Oracle9iAS release 1.0 to Oracle9iAS release 1.0.2.
To provide a more scalable solution that enables Digital River to incrementally add less expensive servers, Digital River created two pods of two application Web servers. Each of the application Web servers in the pod was configured with Oracle9iAS and Oracle Web Cache. Low-cost Sun Enterprise 420R computers, each with 4 GB of RAM and 4 x 450 MHz processors, replaced the Sun Enterprise 6500 servers. Each pod was configured with a dedicated Oracle8i release 8.1.6 database.
The new deployment is depicted in Figure 11-2.
The main content that Digital River wanted to cache was its dynamic content. Prior to Oracle Web Cache, dynamic content was generated from the backend database. When a user first accessed a Web site hosted by Digital River, the request was sent to the backend database. In turn, the database set a session cookie associated with a list of promotional campaigns. The database sent the session cookie back to the client and served the dynamically generated page.
In order to make this content cacheable, Digital River changed its dynamic generation so that the database sends the browser to a redirected URL that supports the appropriate campaign ID for that user. This redirected URL is then cached by Oracle Web Cache. By making this minimum application change, Digital River is able to achieve greater than 80 percent cache hit rates.
The Digital River team established the same cacheability rules for each Oracle Web Cache deployment with Oracle Web Cache Manager. The cacheability rules are shown in Figure 11-3.
Table 11-1 describes the cacheability rules.
Table 11-1 Digital River Cacheability Rules
Digital River provides a content-management system for its customers to use. This system runs automated invalidation scripts, ensuring that content changes are reflected in the cache.
The overall cache hit rate on Oracle Web Cache is 86 percent, reducing the number of concurrent connections to the backend database from 300 to 30. In addition to the 10-fold load reduction on the backend databases, pages are being delivered up to 10 times faster since deploying Oracle Web Cache. Prior to Oracle Web Cache, page response time was at least 3 seconds. With Oracle Web Cache, delivery is now between 0.1 and 0.3 seconds.
|
 Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|