Financial Sites

Most financial sites handle large request volumes . Often their customers log on when the market opens, and remain active all day. These users repeatedly check the value of their portfolios and obtain price updates on stocks they're following. They also review (with less frequency) news and research materials on companies, currencies, and other instruments of interest. All of this information is very time-sensitive, requiring real-time quotes, up-to-the-minute market news, and the latest analysts' reports . Much of the information displayed by the web site comes from remote databases and third-party systems.

While all of these functions provide value to the users, the financial web site's real purpose is trading. A large portion of the site's traffic volumes results from trade requests . On busy market days, these trading volumes grow dramatically, often to many times the average load. (See Figure 5.1 for an example.) Trading volumes translate to commissions revenue for the financial institution behind the web site. This gives the web site's owners incentive to focus on trading performance. Additional incentive often comes from the government. Failure to support timely trades, regardless of the circumstances, may attract the attention of regulatory agencies. Financial web sites also like to convey the same sense of reliability and responsiveness to their customers as their brick-and-mortar counterparts. Media scrutiny, the threat of poor publicity, and the resulting lack of customer confidence all play a role in pressuring financial web sites to be fast and reliable, despite frequent wide swings in traffic volumes.

Figure 5.1. A brokerage web site's traffic patterns

Financial trading heavily engages the dynamic portions of the web site. The trading application uses a variety of external resources to prepare the trade, including the customer account database and quote servers to pull the trade information together. However, the actual trade usually occurs outside the web site in a trading engine. The engine usually resides on a mainframe, or it may belong to a third-party trade clearing house. The web site must maintain fast access to this central trading engine, and the engine must keep pace with the trading demands from the web site as well as other trading software inside the brokerage

Caching Potential

Financial web site pages usually contain few graphics. A typical page may display the institution's logo and some aesthetically pleasing navigational aides (tabs, buttons , shading graphics, and so on). The page frequently contains JavaScript and a few advertisements for related services. However, users sometimes request customized graphics, and generating these requires the involvement of the web application. (For example, a graph of portfolio gains and losses over the past 30 days requires dynamic generation.)

This leads to the next major characteristic of financial web sites: They cannot rely on long-lived data caches. The data returned by a financial web site actually falls under a "freshness" hierarchy. Real-time data such as stock quotes or market indices changes frequently and must be current. Any cache of such data must refresh constantly, and it only benefits the web site if it receives large, simultaneous request volumes requiring this information. Next in the hierarchy comes market news and bulletins. These bulletins arrive continuously, but their information remains relevant longer than an "old" stock quote. Caching these bulletins makes sense, but the cache requires frequent refreshing as well to load the latest bulletins . Finally, at the bottom of the information hierarchy lies longer-lived data such as analysts' reports or company quarterly statements. Given the size of these reports, as well as their low access rate, most web sites retrieve them only as needed from a database.

Special Considerations

Financial web sites deal with time-critical and confidential information. Therefore these web sites operate differently in some important areas, as we'll discuss in this section.

Security

Security is a very important consideration. Financial web sites contain, manipulate, and display sensitive information about their users. The data returned routinely contains account numbers , trading history, portfolio content and value, and other highly personal information. To defend this data, the web site uses SSL to encrypt sensitive communications. To protect the site from unauthorized internal or external access, the institution shields the site with other security measures such as multiple firewall layers and internal security features (authentication and/or authorization). Of course, all this security impacts performance. More than other web site types, financial sites use SSL on a higher percentage of page requests. This increases overall response time as well as the burden on the HTTP servers.

Traffic Patterns

The traffic pattern for a financial web site tracks to major market operating hours. Request volumes spike around the market opening, and again just before closing. Also, traffic tends to be high around lunchtime. Before and after the major U.S. East coast markets close, significantly smaller traffic volumes visit the web site to check portfolios and research investments. Market upheavals result in abnormally large, sustained traffic volumes during the market day. Figure 5.1 in the next section shows an example of financial web site traffic patterns.

Financial web sites plan for market upheavals rather than the normal days. For this reason, these sites invest significantly in reserve hardware capacity. The web applications occupying this hardware undergo stringent performance and scalability tests to gauge their performance under extreme loading.

Auditing

Financial sites track detailed information about every trade, both within the web site and within the trading system. Often such auditing results from government mandate , but it also proves useful when settling disputes with customers.

Customers occasionally try to renounce a trade if it results in losses. If the customer claims they never executed the trade, the web site needs detailed logging to track the trade from initiation through every step until completion. This includes following the trade across multiple, distributed systems.

Logging adds overhead to web site processing. However, nonrepudiation is so important that logging is a must for these transactions. Use performance testing to evaluate the impact of logging on trading performance.

Performance Testing Considerations

Financial web site performance testing stresses the limits of throughput and user logins for the web site. Generating the traffic necessary to stress the systems under test frequently requires a large client environment. See the suggestions in Chapter 6 on managing these types of performance tests.

Also, your test needs test data. Obviously, you don't want to make hundreds of stock trades from real accounts while testing performance. Many financial companies use specially designed test accounts for these situations. Make sure you have enough data in the test system to avoid artificially inflating your results through data caching. (For example, using the same customer IDs repeatedly often leads to caching of these accounts at the customer database. This artificially improves their average retrieval time.)

Since financial web sites incorporate many distributed systems, consider the availability of these systems when planning your test. Overloading a quote server with your testing leads to unhappy customers on the existing web site. Schedule off-shift testing for these elements, or develop test simulators for these systems.