Slow performance isn't an option for an e-commerce Web site. Customers want faster processing and quicker navigation at the same time as they're demanding more sophisticated features. Unfortunately, the most obvious solutions to the problem of slow-commerce sites - more bandwidth, more boxes, more servers - aren't always the most appropriate answers to the performance question. Dawne Shand reportsUsing an e-commerce site is much like driving a car on a highway. The speed at which a request gets from point A to point B depends on the traffic it encounters and the stops it must make.
As Web sites gain interaction capabilities, they must also inter-operate with more potential bottlenecks. Firewalls and switches must check out requests before releasing them to the Web server. Application servers must first talk to back-end databases to determine a final destination. Payment information must be verified by a third-party credit card service.
Each operation acts like a toll booth on a highway, slowing down the speed at which the request can be made. And since bandwidth is a finite resource, each request finds itself competing for space in an increasingly crowded pipe.
Finding solutions to bottlenecks requires a review of every part of the e-commerce architecture. In most cases, the network needs some combination of cach-ing, clustering and load balancing.
One way to speed performance and reduce traffic is to store, or cache, seldom-updated content. This can mean pushing content to the network edge, where it doesn't travel through as many switches or servers.
When The Motley Fool began dispensing investment advice in 1995, static HTML pages dished up much of the information. "Back then, we didn't need a database backend. Now it's the heart of our system," explains Dwight Gibbs, "chief techie geek" at the company. Today, The Motley Fool Web site, www.fool.com, is much more interactive. Users can access message boards, participate in discussions and listen in on live conferences. Introducing more and more complexity inevitably degrades performance.
"Nothing is ever going to be as fast as static HTML," says Gibbs, "so the question is whether hardware can keep up."
Today, Fool.com uses a series of Compaq Computer machines running Windows NT, Microsoft's Internet Information Server (IIS) and transaction servers.
Using content delivery service last year, Fool.com achieved great performance gains. Its content delivery service's proprietary technologies reside on a global network of 2000 servers. The system routes each request for content to servers that are geographically closer to the customer so the request travels a shorter distance along the Internet.
By off-loading requests for specific graphics-intensive pages to the content service deliverer's network, Fool.com fields fewer requests through its servers, firewalls and switches. Existing bandwidth gets used more efficiently. Gibbs claims that Fool.com realises 30 to 50 per cent gains in performance by using the content delivery service.
Although it can improve delivery speed, caching doesn't affect transaction performance, according to several sources. But delivering multimedia, although difficult, is just one bottleneck along the way.
Balancing the load
Craig Johnson, senior wide-area network engineer at DiscoverMusic.-com, similarly concluded that transaction performance was most critical. His company delivers via the Internet music samples heard on the best-known CD commerce sites. Interruptions mean lost revenue.
DiscoverMusic.com first began in 1996 as Enslo Audio Imaging International, a subsidiary of Muzak. The decision to spin off the division as a separate, publicly traded company coincided with the need to improve the transaction performance of the site. As investors began evaluating the company, they raised a significant concern: If you base revenue on service being available, what is your disaster-recovery plan?
Back then, the service, hosted by MCI WorldCom and running on just two Intergraph servers, couldn't recover quickly from an interruption. Lengthy delays occurred when the second server picked up a request. And at that time, DiscoverMusic.com was delivering fewer than two million streams of music a month.
To provide continuous disaster-recovery service, DiscoverMusic.com built server farms, with full redundancy in power, services, hardware and software, all capable of responding to the same request. To assure transaction performance, Johnson ran network appliances, minimising impact on the network hardware and software infrastructure. During the initial tests, "we were high-fiving each other", Johnson recalls. DiscoverMusic.com found that it could interrupt the audio stream and have a second server pick up the request without missing a beat. The company now serves 60 million to 70 million audio streams a month and has experienced no interruptions of service since initiating the new setup in November 1998.
Routing requests to the least-busy server won't solve performance problems at all e-commerce sites, however. Given the varying levels of computing power in machines that support e-commerce applications and the types of features that must be supported, certain sites employ more complex load-balancing solutions.
"The problem with traditional load balancing is its round-robin approach," says John Puckett, CIO at US-based toy retailer Toysmart.com. In a traditional load-balancing system, if a server configuration had a new PC and an old Cray machine, the least-busy server wou-ld get the request. Problems occur when the older server gets a request it can't handle.
Toysmart.com doesn't run on Cray computers, but its configuration does include Sun Microsystems Solaris machines and a multitude of Compaq servers of varying computing power running Windows NT. To make the most efficient use of its existing server configuration, Toysmart.com implemented a switch which uses a rules-based engine to determine where a user request should be sent.
"Most people think about the appliances and connections more than the network and bandwidth," says Puckett. By caching graphics at the network, tuning the local cache of the server boxes and balancing server loads, Toysmart.com uses its existing bandwidth more efficiently. With these improvements, the company doubled its capacity in terms of the number of pages its site can supply per minute.
Load balancing can happen at the server level as well as the switch communications level. Called clustering, this technique of grouping independent servers to work as a single system can often improve overall site performance.
The Motley Fool and Toysmart.com both use Microsoft Cluster Server, which is bundled in the enterprise edition of Windows NT. This connects two servers so one can take over for the other in case of failure. Whereas load balancing increases performance, this type of clustering improves a site's reliability more than its speed.
Load balancing within the server, or clustering, made a difference at ETrade Group over in the US. Begun in 1982 as the first online brokerage service, ETrade implemented its e-commerce service in 1996. Back then, it managed 60,000 accounts. Today, it manages 1.5 million.
According to Gary Kattge, director of quality assurance at ETrade, customers look for reliability and speed. Given the constant introduction of new content and features, that's no small feat.
Caching of content and clustering of back-end databases have yielded the greatest performance improvements at ETrade. Its clustering technique puts more than one server into the same box, increasing the speed at which one server can take over for another.
ETrade's system focuses on routing a request to the server best suited to handle it - something Kattge calls "services packaging". It looks at what features are most often used and guides those requests toward higher-capacity servers tuned to handle them.
Consider ETrade's "smart alerts", which notify an account holder when an event, such as a stock hitting a certain price, occurs.
"These represent a huge flow of data," says Kattge. "We set aside certain parts of the system tuned to handle these specific requests. We don't distribute the load evenly."
Working the back end
Still other companies find that their performance bottlenecks occur once the application server tries to communicate with the back-end databases. Database caching techniques significantly helped out customers of Interlinkweb.com (ICS). Resellers of data communication hardware to other businesses, it started its e-commerce site two years ago and has introduced stores targeted at specific customers.
ICS found that its customers were mainly interested in getting reports on their account status. The company's site simplifies the purchasing procedures and order-checking processes for companies. It allows corporate procurement officers to name other buyers and set credit limits. Because 90 per cent of their purchases are made through purchase orders, ICS's customers must know where their accounts stand.
To do this, ICS links its Web-site ordering with the Dynamics accounting system from Great Plains Software.
"Our goal is to maximise the customer experience with as much functionality as possible without adding inherent inefficiencies," says Paul Dietrich, ICS's chief technology officer. For a reporting-intensive site, this is a challenge, he says.
Although ICS is a Microsoft shop that runs IIS, Site Server and Commerce Server, it recently abandoned Microsoft ActiveX components for communicating with the back-end databases. Using these map query objects meant repeating certain executions that slowed the generation of reports.
ICS now relies on stored procedures, using SQL 7.0, for handling the reporting-intensive features. Stored procedures are like caches for database requests. If a report requires five steps, the stored procedure has the first three already completed. Dietrich says this change increased reporting execution speed by a factor of three to five.
In essence, an e-commerce site must scale with the number of users, respond reliably and quickly, and optimise its use of bandwidth. When it comes to performance, caching, clustering and load balancing, applied at the appropriate junctures, make these three goals more attainable.