Turbocharging a Slow Site

Check out the tricks and tools that IT managers use to spot bottlenecks and speed up their sites.

It was a systems manager's nightmare - an intermittent failure of a business-critical Web application. But instead of fixing the code, the staff just rebooted the server every night. "It was swept under the rug, like so many problems that have temporary fixes that become permanent fixes," says Eric Jones, senior network engineer at Greensboro, N.C.-based VF Corp., the world's largest apparel maker.

But Jones should consider himself lucky. A May study by the Business Internet Group of San Francisco revealed that 205 of 315 sites studied suffered application failures that weren't visible to IT operations. This research underscores the critical problem that stumbling applications - not inadequate bandwidth, pokey processors or even inept users - are crippling performance on Web sites today.

Slow Web software can add up to lost sales for e-commerce vendors and higher costs if performance problems result in missed thresholds in service-level agreements. Here's a look at some tools that a few IT managers have found effective in identifying and fixing application performance problems.

Problem: Web software was certainly the culprit at VF. The errant server ran an in-house Web application with poorly written Dynamic Link Libraries (DLL) that caused a memory leak. But the DLL failure didn't happen every time: VF's business-to-business partners for its Wrangler- and Lee-brand clothing sites would log in and sometimes get an error page, sometimes not. But because the DLL problem didn't shut down the Microsoft Internet Information Server (IIS), no alert was sent to IT.

Fix: Jones says that by using real-time code-analysis software - AppSight from Identify Software Inc. in Raleigh, N.C. - he was able to locate the troublesome DLL, which was ultimately rewritten in its entirety. But that fix took nearly a year to get through in-house decision-making. In the meantime, an IT staffer had to reboot the IIS server every night. "That was the worst-case solution," he says.

Problem: When a Web site bogs down, users initially blame the network, says Jim Demos, vice president for global network services at Reader's Digest Association Inc. in Pleasantville, N.Y. But they're usually wrong, he says.

In one instance at Reader's Digest, a Java application that linked a Web server to a back-end database was causing a Web slowdown.

The application wasn't releasing the connection between the servers. Because the database server required a set number of connections, once that number was reached, the next link failed to connect and subsequent users sat waiting.

Fix: The magazine publisher invested in SuperAgent, a monitoring package from NetQoS Inc. in Austin, Texas, which uncovered the problem with the Java application.

Detecting the source of a slowdown takes some investigative work. Demos notes that site performance is more variable than, say, mainframes and client/server response rates, where subsecond returns are the norm. "But users have had to become a lot more patient in a Web environment," Demos says. That's because the complex interdependencies in Web applications provide many opportunities for software to slow down operations.

Problem: Java was at the center of a similar headache for Jim Struve, assistant manager of information support services at WEA Trust, a Madison, Wis.-based insurance and retirement services enterprise for the state's public school employees. He says a Java applet couldn't release the connection to a DB2 database on its Web site.

Fix: Struve used a performance-monitoring tool called Fenway, from Dirig Software Inc. in Nashua, N.H. With it, he discovered that the Java software wasn't the culprit. Rather, the DB2 application was responsible for not releasing the connection to the Java program.

The Trouble With Fixes

These IT users found products on the market to help ferret out which applications were causing their performance problems. But while there are a lot of products to choose from, they come with their own sets of problems.

For one, these products aren't meant for novice systems administrators. "I have one caveat," says Jones, referring to Identify's AppSite product. "It needs experts to use it, experts who know Windows workings inside and out."

Another issue is that the monitoring software itself chews up processing cycles on the servers. Mark Rogers, Identify's vice president for product management, acknowledges that AppSite 4.0 can command 3% to 5% of a system's capabilities. Jones says this isn't a problem at VF, but he advises others to be aware of the impact a monitoring tool could have on existing hardware before deploying it.

At VF, AppSite feeds alerts into the Tivoli network management framework, which in turn fires off trouble tickets to the help desk. But while that works at VF, it isn't sufficient as a long-term solution, says Jean-Pierre Garbani, an analyst at Giga Information Group Inc. in Cambridge, Mass. "With the Web infrastructure going mainstream, point tools need to better integrate into managed frameworks," he says.

A View From the Top

Some IT managers continue to use just the management consoles of the monitoring tools, because they offer targeted information on areas of concern.

Tom Ballard, chief technology officer at Austin-based Hoovers Inc., a business information provider, uses the "executive dashboard" from ProactiveNet Inc. in Santa Clara, Calif. The software gives him the right amount of high-level information he needs to see if problems exist and then lets him drill down for details. "That way, I can see if the problem is being fixed," he says.

Harry Nicholos, assistant director for Unix and Web services at North Carolina State University in Raleigh, is content to use the console from Sunnyvale, Calif.-based Resonate Inc. "We haven't even considered connecting it to OpenView," which the university uses to oversee its IT operations.

Although imperfect, there are tools that will track down the root causes of a Web bottleneck. And by keeping your Web site running at a nice clip, they can save your company money.

There's no doubt that the accomplishments of Tim Berners-Lee and his colleagues at CERN, the European Laboratory for Particle Physics in Switzerland, were revolutionary. They created the four building blocks of the World Wide Web: HTML, the Web protocol HTTP, a Web server and a basic browser.

By Christmas 1990, Berners-Lee had set up a Next computer - an easy-to-program, Unix-based black cube that was the brainchild of Steve Jobs - as the world's first Web server.

But at the time, the Web didn't exactly look impressive. And it wasn't "World Wide" at all. In fact, it was more like a small intranet for CERN physicists. Information traveled no farther than a few buildings.

That changed after Stanford University physicist Paul Kunz got a peek at the future during a September 1991 visit to Berners-Lee's office in Geneva.

When Berners-Lee demonstrated information retrieval via the Internet between Next computers, Kunz wasn't impressed. But when he saw it was possible to send a query from the Next box to CERN's IBM mainframe and retrieve the results, Kunz started to get interested. Document retrieval from incompatible computer systems opened up many possibilities. But would it work between computers half a world apart?

"Tim couldn't demonstrate how well this is going to work because all the world's Web servers were at CERN," Kunz recalls. "It's not a very exciting demo."

So they used the Internet to remotely set up Kunz's computer at the Stanford Linear Accelerator Center (SLAC) with a browser and retrieved a Web page.

"We were both shocked at how well it worked," Kunz recalls.

Kunz and Berners-Lee then discussed putting something substantial - Stanford's meaty bibliographic database of 300,000 physics references - on the Web. Kunz returned to Stanford to do exactly that, with help from SLAC librarian Louise Addis.

On Dec. 12, 1991, the first Web server outside Europe went online at SLAC in Stanford, Calif. The next month, Berners-Lee demonstrated his Web application to more than 200 physicists at a conference in France. For his grand finale, he connected to the Stanford server and performed a search on the bibliographic database.

"People went home from this meeting telling their colleagues of a new way to access [the database]," Kunz says. "It was called the World Wide Web, and it was great."

The Stanford database is considered the Web's first "killer app" because it provided a compelling reason to use the new technology.

Web for the Masses

Though it was a hit with physicists, to reach a wider audience, the Web needed a browser for the masses. Many Web browsers were developed in academic or scientific settings, but the one that captured widespread attention was Mosaic, created by University of Illinois student Marc Andreessen. What made the Mosaic browser different is that it was a graphical user interface, instead of being text-based, and it worked on the ubiquitous Windows desktop.

Andreessen's team released Mosaic for Windows in October 1993. By the next year, thousands of people were downloading the free browser every day. The number of Web servers jumped markedly, and the Web took off. A page-and-a-half article about the Web and Mosaic that appeared in The New York Times didn't hurt, either.

Soon the Web took on a commercial flavor, as cybermalls opened and closed, Yahoo became the major directory of Web sites and Amazon.com Inc. started selling books and music CDs.

During the dot-com boom of the 1990s, some Web sites were slapped together quickly, and the biggest challenge for webmasters was keeping up with the spikes in traffic generated by their Super Bowl ads. Crashes and outages were headline news.

After the dot-com bust, the new goal was to apply time-honored IT disciplines, such as scalability, reliability and security, to make Web sites solid platforms for doing business.

But Web sites are growing increasingly complex, with multiple servers, load balancing, caching, firewalls, search engines and personalization - all geared toward improving the end user's experience.

And now, on with the story. . . .

1991: Paul Kunz, a physicist, installs the first Web server in the U.S., at Stanford University.

1991: Paul Kunz, a physicist, installs the first Web server in the U.S., at Stanford University.

Photo Credit: L.A. Cicero/Stanford University
1989: European physicists Tim Berners-Lee and Robert Cailliau propose the World Wide Web.
1989: European physicists Tim Berners-Lee and Robert Cailliau propose the World Wide Web.

1987: Larry Wall creates the programming language Perl, which later is widely used for Web site applications.

1989: European physicists Tim Berners-Lee and Robert Cailliau propose the World Wide Web.

1990: The Web protocols on Berners-Lee’s Next computer undergo initial implementation.

1991: Paul Kunz, a physicist, installs the first Web server in the U.S., at Stanford University.

1993: Marc Andreessen, a student at the University of Illinois’ National Center for Supercomputer Applications (NCSA), develops Mosaic, the first Web browser with mass appeal.

1994: Andreessen and colleagues leave NCSA to form Mosaic Communications Corp., which announces a Web browser called Netscape Navigator and a Web server called NetSite. The company later adopts the name Netscape Communications Corp.
1993: Marc Andreessen, a student at the University of Illinois' National Center for Supercomputer Applications (NCSA), develops Mosaic, the first Web browser with mass appeal.
1993: Marc Andreessen, a student at the University of Illinois' National Center for Supercomputer Applications (NCSA), develops Mosaic, the first Web browser with mass appeal.
1995: Sun Microsystems Inc. debuts Java 1.0.
1995: Sun Microsystems Inc. debuts Java 1.0.

1995: The open-source Apache Web server software is officially released to the public.

1995: Sun Microsystems Inc. debuts Java 1.0.

1996: The browser wars heat up as Microsoft Corp. releases Internet Explorer 3.0 and Netscape releases Navigator 3.0.

2000: Hackers take down major Websites with massive distributed denial-of-service attacks.

Special Report


Hard-Workin' Web Sites

Stories in this report:


Copyright © 2002 IDG Communications, Inc.

Shop Tech Products at Amazon