David Rubinstein: Performance Anxiety

By David Rubinstein

November 1, 2007 —

Thanks to the Web performance measuring tools at Gomez, I learned that SDTimes.com performs quite poorly. I mean, I always knew it was slow to load some images and fill some frames, but now we have hard metrics to show just how poorly it performs—down to the problematic JavaScript code itself.

Web performance was very much on the minds of the attendees at last month’s Software Test & Performance Conference. At least, that’s the impression I received from observing the large overflow turnout for performance testing guru Scott Barber’s keynote address.

While performance might not be the most critical aspect of the SDTimes.com Web site, back-end response time certainly is a big deal for the financial sector, where the price of a stock can change in less than a second. If the transaction rate is slow, millions of dollars can be lost in just a few moments.

Joseph Schlam, a principal software engineer in performance testing at Fidelity Investments, observed if someone puts in an order to buy a stock at, say, $50 a share, but because of slow software performance the stock reaches $52 a share before the order is placed, that customer won’t trade with Fidelity much longer. “There are tremendous amounts of money tied to [Web application] performance,” he said.

So, if it’s so important to businesses, Barber asked, why is it an afterthought in so many cases? Why do businesses leave so little time for this kind of testing?

It often comes down to myths, which Barber sought to dispel during his talk. “Good performance testing demands that the people doing it understand every aspect of the system—architecture, technologies, interfaces and configurations, and how users interact with the system,” he stated.

To do this, performance testers not only need access to test managers, or even development managers—they also need to communicate regularly with the business stakeholders, Barber posited. “Without access to the people making business decisions about what goes live when and what risks they’re willing to take, [performance testers] just don’t know what’s important, and can’t prioritize” areas to work on to gain more performance.

Barber said many organizations have the misguided notion that performance testing is nothing more than load testing. Pile on the load and break the system, and then you can see what to fix, they believe.

“To do performance testing at the conclusion of system or functional testing is like ordering a diagnostic blood test after the patient is dead. What are you going to do if you find a problem?” Barber mused. Most companies, he said, don’t take performance testing seriously until they’ve gotten burned.

Alternatively, companies will outsource performance testing to cut costs. But Barber asked, “I thought we were here to solve problems with good testing. Where did the ‘savings’ thing come from?” Performance testing must be done in-house, he argued, because consulting without training and mentoring only solves a problem once.

Performance should not only be tested at the end—it should be architected into how the Web application is created, said Jim Pierson, a performance architect at Microsoft’s MSN. “Server response time,” he said, “is a small component of performance.”

For instance, he explained that Java scripts don’t run concurrently; they load serially. But by adding more domains—such as msn.com, javascript.msn.com, stylesheets.msn.com—you can increase throughput, because Internet Explorer opens two ports for each domain.

In the end, for organizations to maximize Web performance, Barber said they must admit performance testing is not simple. They must focus on the satisfaction of the end user. And they must give performance testers access to the information, stakeholders and users necessary to ensure the application is optimized for performance and functionality.

“There’s some reason an executive is risking his money to fund [the site and its applications],” Barber said. “If we don’t know what that is, we can’t test for it.”

That’s as plain as can be.

David Rubinstein is editor-in-chief of SD Times.

Share this link: http://www.sdtimes.com/link/31278

David Lyman named publisher of SD Times BZ Media promoted David Lyman to publisher of SD Times, the newspaper of record for the software development industry. Lyman heads up advertising sales and marketing for all SD Times vehicles, including the print and online publications, e-newsletters, webinars, supplements, banners and lead-generation programs.

Gomez delivers cross-browser performance monitoring Focusing on the wide variety of browsers for both PCs and mobile devices, Gomez provides a way to look at apps like users do

New app-performance software goes for ease of use AppDynamics, looking to make instrumentation agile-friendly, takes on new event-type monitoring abilities

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST