Keeping track of what's happening with your Web site is a big ask. There are several dimensions to the issue, and in some aspects you can quickly collect many megabytes of data that must be turned into information.
Infrastructure
IBM Australia's market manager for WebSphere, Jack Verdins, says the company has a four-step methodology for Web site performance measurement: establish performance objectives, monitor and measure the site, analyse and tune components, and predict and plan for the future.
Performance objectives can include business-oriented criteria such as browse-to-buy ratios as well as technical criteria including application availability and resource utilisation.
Monitoring and measuring should be done in terms of the objectives set in the previous step, so you are aware of any metric that goes outside the established norms.
Component analysis can be broken into four main areas, namely edge servers (caches, etc), Web servers, application servers, and database servers and legacy systems.
"Each has their unique tuning opportunity," says Verdins. Viewing the system in this way makes it easier to identify the source of any problems, and the appropriate testing tool can be brought to bear on the affected subsystem.
Examples of real-life problems identified by this methodology include a failure to provide enough connections between the application server and the back-end database, an inappropriately indexed database, and a firewall configured to allow too few simultaneous connections to the Web server.
"IBM has a good history at the back end," Verdins says, but moving from traditional applications to the Web "increases the number of performance-related matters." Performance issues tend to be a concern mainly with transactional systems, Verdins says, adding "we've done most of the Wall Street sites" and those systems managed to cope with peaks in transaction volumes.
Planning for the future can be tricky. "The Web introduces 'interesting' volumes and unpredictability for marketing campaigns...very unpredictable things can happen," he says. That may be true, but it is still worth looking for fluctuations in transaction levels according to the time of day, day of the week, or the season, and planning accordingly.
Approximately one-third of performance bottlenecks can only be found by testing from outside the firewall, according to Mercury Interactive.
While the majority of problems can be traced to internal subsystems such as those identified by IBM, 35 percent are due to tuning and configuration issues with external routers, gate ways and switches, bandwidth constraints, and ISP peering point problems.
Company officials claimed that "performance problems occur 98 percent of the time simply because the infrastructure components have not been tuned or configured properly for a specific application."
Mercury Interactive provides a hosted service to load-test Web sites by emulating as many users as appropriate--1.35 million concurrent connections in one case--while measuring the performance of infrastructure components.
"Often, solving a performance problem with the one component will reveal previously hidden problems with another component," says Graham Sowden, managing director of Mercury Interactive in Australia.
"Proper load testing is an iterative process. It's like peeling an onion and examining each layer looking for ways to improve performance. By taking this approach, our ActiveTest experts have typically helped our customers increase the performance of their Web applications by more than 400 percent, without adding more hardware," he says.
Over the last few years, network appliances--pre-packaged Web servers, firewalls, and so on--have become increasingly commonplace. This trend has even extended to performance monitoring in the shape of Sniffer Technologies' Sniffer Pulse which monitors and analyses Web traffic in real time.
Sniffer Pulse has a Web-based interface to present detailed analyses of Web site components, and custom views can be created to focus on aspects of particular interest.
According to the company, it helps answer questions such as "How long are visitors waiting to view critical Web pages?" or "Are certain objects on my Web page degrading the performance?".
It can help determine whether complaints of poor performance are due to a site problem or bottlenecks at the user's end, and when installed between a load balancer and the Web server farm, it can verify that load balancing is being carried out appropriately.
In addition to displaying data on request, Sniffer Pulse can generate e-mail alerts on over 50 metrics including response time, page download time, and server error codes.
Specific alarm thresholds can be set, or they can be derived in terms of deviations from automatically generated baselines. These baselines identify the times when particular resources are heavily used, and can reveal when they are reaching capacity.
