At the forefront of online financial dealing, Charles Schwab & Co., Inc. (member SIPC/NYSE) provides high volume trading and tailored, timely financial information. Having developed various separate e-business channels during the early days of the Internet, their runaway success made it clear the next step was to give customers a single view of their different dealings with the company. The current infrastructure was serving its purpose well but, with the number of customer transactions rocketing skywards, Schwab needed to establish an architecture for the future that could cope with soaring growth, give greater flexibility and economy, and provide state-of-the-art customer service and satisfaction.
After thorough investigation, the obvious choice to meet their business goals was a JavaTM-based architecture built on the IBM WebSphere® Software Platform for e-business. Having narrowed the field to this combination, Wilfried Kruse, Vice President of Architecture for Electronic Brokerage at Schwab, put up one more hurdle before the final mission-critical decision was made: "I want proof that Java/WebSphere can provide at least the same level of scalability and robustness as our current CGI (Common Gateway Interface) implementation." He looked to IBM to provide that proof.
IBM's High Volume Web Sites organization performed an extensive benchmark, which resulted in all requirements met and many exceeded, providing validation of the chosen architecture for future Schwab.com trading.
Schwab's trading site -- one of the best known in the finance industry -- is just one of a number of electronic financial product channels that has evolved in response to market demand. Schwab's presence on the Web is well established and growing strongly. Today that strong growth is manageable and containable using existing technologies but to meet future demand Schwab looked for a single architecture to:
- Provide an integrated view of the different channels to customers
- Exploit the opportunities that e-business has opened up by streamlining future development
- Separate business and presentation logic to accommodate changes more efficiently
- Reduce costs
Schwab was looking for integration without losing scalability or dependability, and after careful research decided Java and IBM WebSphere Application Server looked like the answer to the new cross-channel application architecture. Java, as a leading edge technology, would attract programming skills to Schwab, and the combination of Java and WebSphere would provide the capacity for future growth while reducing the cost profile.
The proposed new architecture was code-named Barista (a barista is a person who serves coffee, in this case Java), and as Wilfried Kruse, VP of Architecture for Electronic Brokerage points out with tongue in cheek, "Once a project has a code name it's taken seriously." To obtain proof of viability for large-scale deployment using the Barista architecture, he joined with IBM to demonstrate that Java and WebSphere together perform as well or better than his current Web trading infrastructure.
Today's busy Charles Schwab Web site runs on approximately 700 RS/6000®s with four CPUs each, serving over 90,000 concurrent end user sessions. The majority of the current Web applications are based on C/CGI technology, which exhibits good linear horizontal scalability -- adding new systems to the configuration results in a predictable increase in throughput on the Web servers.
Making sure the new architecture measures up
Wilfried Kruse, recognizing the mutual benefits, invited IBM to demonstrate that the new Barista architecture was mature enough to handle his future mission-critical workload and provide, at least, the scalability and robustness of the current C/CGI implementation. "We teamed with IBM so they could help us get the best from their technology and we could help them best utilize their technology in our market."
In response, the joint Schwab and IBM team set up the Barista High Volume Web Site Benchmark environment with four major goals:
- Administration - To demonstrate that IBM's implementation of Java and IBM WebSphere Application Server can be installed and administered economically in a large scale, multi-node environment.
- Stability - To demonstrate that the Java and WebSphere Application Server technologies are robust and stable, by running the environment for 48 consecutive hours without failure or performance degradation.
- Scalability - To demonstrate that the Java and WebSphere Application Server technologies can scale at least as well as, or better than, Schwab's existing C/CGI technology, by varying the workload and number of nodes used in testing.
- Performance - To demonstrate the Java and WebSphere technologies perform at least as well as, or better than, the current Schwab CGI technologies in comparable circumstances.
For Wilfried Kruse the key business goal was "whether the architecture and the technology could support Schwab volumes. Could we achieve comparable performance and scalability without incurring extra deployment costs? Our existing systems have known scalability characteristics and we wanted the future systems to be at least as good."
To accomplish these benchmark goals, a large-scale system environment was set up at IBM's SP Benchmark Center in Poughkeepsie representing approximately one tenth of the scale of Schwab's existing production systems. It consisted of 64 R/S6000 4-way SMP Web servers running Netscape Enterprise Server and WebSphere Application Server software, 12 additional systems emulating the corporate server functions, and several other systems driving the application workload by distributing requests across the Web servers. The administration and operational procedures were developed and enhanced during the benchmarking.
Schwab selected a critical aspect of their online trading system for the benchmark: presenting account information to customers, and a servlet was created to perform that function. For the test, five accounts were defined that differed mainly in the number of positions that the account held, resulting in varying amounts of information being delivered. The corporate server functions for the Schwab application were emulated in the test, because they use proprietary interfaces.
Figure 1. A large-scale system environment set up at IBM's SP Benchmark Center.
The results achieved for the benchmark were:
- Administration - A Java and WebSphere installation and an efficient administration process were developed and successfully implemented for a 64-node SP configuration.
- Stability - The stability of the large-scale WebSphere configuration was demonstrated by a soak test in which the 64-node WebSphere system ran for 48 consecutive hours without failure or errors in either the hardware or software. Performance data collected over 12 consecutive hours showed stable throughput and CPU utilization.
- Scalability - Scalability was demonstrated in configurations up to 64 nodes by showing almost linear throughput (page views/second against number of nodes) at both low and high levels of workload.
- Performance - The Java and WebSphere technologies performed at 300% of the stated goal. The current C/CGI technology provides approximately 1.3 page views/second/node at 37% CPU utilization; IBM Java and WebSphere technologies achieved approximately 3.8 page views/second/node at 30 - 40% CPU utilization. At higher CPU utilization (> 90%), 564 page views/second were attained with an average response time of less than two seconds using the 64-node configuration. Assuming a configuration comparable with Schwab's installation in February 2000, this level of performance will support 100,000 concurrent end-user sessions during "market storms" (periods with very high volumes of requests).
Figure 2. Levels of performance
These results met or exceeded the criteria set by Wilfried Kruse and his team at Schwab. Not only does Barista, backed by IBM Java and WebSphere technologies, ease development, simplify the separation of business and presentation logic, reduce development costs, and provide an integrated view of the different channels to customers, but its benchmark results fully met the criteria for handling high volume mission critical workload.
Schwab's response to the benchmark results
In summary, the results achieved in the Barista High Volume Web Site Benchmark adequately demonstrated the suitability of the Schwab Barista architecture and the IBM Java/WebSphere technologies for high volume application use at Schwab.com. When asked about the outcome of the benchmark project, Wilfried Kruse replies, "Performance was comparable, so that was good. The stability was good, which we'd expect from IBM. But throughput was much better, by a factor of three, so that was really good because it means we can utilize the new technology, keep the existing hardware, and handle higher volumes."
He also comments on having to curb the enthusiasm of Schwab programmers for the new technology until the benchmark was completed. "Once the results came out and were positive, it was like a floodgate opened. In the past some developers were interested in building their own product architectures, but now they've seen the new architecture is proven, and it's simple enough and yet sophisticated enough to handle our business, they're saying 'let me use it,' which is a really good change."
"Initially we'll be writing a lot of infrastructure that already exists, reinventing the same wheels in the Java space, so there won't be savings straight away, but once we have a critical mass of the new infrastructure and products deployed in this new environment, new development will be much more productive than in the current C/CGI environment."
And what benefits will Schwab's customers see? "They'll see more consistent products, and more coherent product behavior," says Kruse, "because there will be a more integrated front-end presentation layer across the different financial product channels." Other benefits are that Schwab can roll out new functions in smaller increments much faster, our product release procedure will be more efficient. And quality will improve because we'll get a lot more reusable code -- that means code that's already tested will be used in new ways, it won't need to be reinvented. I expect a lot of productivity and quality gains from that."
And Wilfried Kruse recognizes the value of teaming with IBM, "A very encouraging effort, I'm very pleased with how it went." Follow-on work is to explore the use and scalability of Enterprise JavaBeansTM (EJB) technology.
IBM partnership executive Keith Jones reflects on the results achieved, "This project presented a significant challenge to both the Schwab and IBM teams. The results speak to the strength of the Barista architecture and the strength of IBM Java and WebSphere technologies and the people behind them. Schwab are leading exploiters of these technologies; their leadership translates to a quantum leap for large scale e-business."
The four major goals were:
- Administration - To demonstrate that WebSphere can be installed and administered in an environment with a large number of nodes. Sets of nodes would be administered at the same time, with a single command to any set of nodes. This technique was verified against the 64 Web server nodes and 12 back-end nodes, and was used for all components in the setup.
- Stability - To demonstrate that Java and WebSphere Application Server technologies are robust and stable, by running the environment for 48 consecutive hours without failure. System performance, judged by a few key performance indicators, would be constant over the period. IBM would monitor the rate at which the system processes requests to ensure that it could handle the same load throughout the period. Response times of the requests would also be monitored to make sure the CPU utilization was not increasing over the period.
- Scalability of servlet - To demonstrate that Java and WebSphere Application Server technologies will scale. Linear scalability is achieved if twice as many nodes can handle twice the throughput with the same CPU utilization of each node. IBM tested this by varying the number of nodes and the throughput. They also verified that as the number of nodes increased the throughput would increase proportionally. CPU utilization and response time would also be measured.
- Performance of CGI vs. Servlet - To demonstrate that Java and WebSphere technologies perform as well as or better than the CGI technology in Schwab's current Web trading environment. The WebSphere servlet and CGI both running under Netscape in the same configuration would be compared for performance, throughput, CPU utilization and response time.
The test scenarios used for this project exercised a servlet provided by Schwab from their Barista architecture project. The servlet performs a critical aspect of the online trading application; it allows users to view their account information. The test implemented five accounts that held varying numbers of stock positions in the account portfolio. Each account returns a different size page to the Web browser.
The servlet provides business logic that supplies data to a JavaServer PageTM (JSP), which is then returned to the user's Web browser. The servlet obtains much of the information that it displays by using a proprietary interface to a back-end server. For the purposes of this benchmark, the functions of the back-end were emulated by a C++ program and a set of sample files running on an AIX® system.
For the servlet vs. CGI performance comparison, Schwab provided production CGI programs and servlets with JSPs for the comparable application function.
The servlet function contains business logic that fills in different areas on the screen. First it performs a logon, and when done performs a logoff, so that it only obtains information that this user is allowed to see. It has the ability to handle user preferences. It shows urgent notifications, retail offerings, news items, and a graph of current market status. It also shows users their specific account balances, and a list of each position they hold. In the smallest account, there are no positions held, while in the largest account there are hundreds of positions.
The servlet obtains much of the information for these sections through proprietary interfaces to back-end systems, which Schwab has developed. For the purposes of this project, the functions of the back-end were emulated by a UNIX® program and a set of files.
In IBM's SP Benchmark Center in Poughkeepsie, New York, the setup was 64 SP Silvernodes running WebSphere Application Server, Advanced Edition, Version 3.0.2, twelve additional nodes to emulate the back-end server function, and several other machines used to drive the system (using Mercury Interactive's LoadRunner) and to distribute requests (using IBM Network Dispatcher). All these nodes were connected together using a CISCO 6509 switch. Each Web server had a single 100 MB LAN connection. Each back-end server had two 100 MB LAN cards, and the other machines had one or more gigabit LAN cards.
- Twentyfour-way S80 and 12-way S7A machines were used to simulate the workload. These systems were selected, based on the anticipated workload by the test driver.
- Four-way F50 (H70) machines were selected as network dispatcher. Their function was to dispatch and then balance the workload on 64 Websphere nodes. These are the most commonly used machines for the dispatching function.
- Sixtyfour SP Silvernodes (332 MHz, 4-way RS/6000 SMP nodes) were used to configure Websphere. These nodes were used to measure administration, performance, stability, and the scalability of the system. These are the same nodes that are used in Schwab's production system.
- Twelve Winterhawk (375 MHz, 4-way RS/6000 nodes) were used to simulate the delay of the back-end database server. These nodes were based on the anticipated workload and hardware availability.
- Network topology: Fully meshed 64 fast Ethernet connections were configured, one from each Web server, to the CISCO 6509. Additional 24 fast Ethernet connections to the switch used for the Etherchannel connections to each of the 12 Echo servers (two fast Ethernet per node). Lastly a total of 10 separate Gigabit connections were in place for the two Load drivers (S80: 4 Gigabits & S70: 2 Gigabits) and the four Network Dispatchers (1 Gigabit each). Network configuration was selected based on the anticipated load.
- IBM AIX 4.3.3
- IBM Java JDK 1.1.8
- IBM WebSphere Application Server, Advanced Edition, Version 3.02
- IBM DB2® UDB 5.2
- Netscape Enterprise Server 3.6
Figure 3. Software configuration
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
