A Light Bulb Went On

ENT, Feb 26, 2001 by Eric Binary Anderson

Question: How many computer programmers does it take to change a light bulb? Answer: It can't be done, it's a hardware problem.

While this old joke may not garner as many laughs as it once did, it still underscores an important point. In the real world there are cases where all the great software in existence won't solve a performance problem. There are also times when even if a software solution exists, it isn't the right way to go. Programmers need to recognize this situation and be ready to pass the baton to the hardware folks when it makes sense.

Programmers are not always aware of the target hardware for their products. if you are working on shrink-wrapped software, you probably won't have the luxury of specifying sky-high hardware requirements -- only video-game creators have that privilege. If you are developing server products for your company, you may indeed have some control over the target hardware. If you are developing server products for others, you'll make choices that will determine how easily the product will take advantage of additional hardware.

In the mainframe days it was easy to "throw hardware" at a performance problem. Often you simply had to negotiate with a system operator to get access to some of the unused power of the machine. While the cost of getting a 50 percent boost in mainframe computing power could be enormous, it was rare that you had to rewrite your software.

The mainframe era left many technical managers believing that increasing performance is a Simple matter of adding hardware. While generally true, there is often little comprehension of the software features required to take advantage of additional hardware. If software is written to scale nicely across a server farm, adding hardware is a snap. But what if you've created or inherited software that is not designed to work in a server farm. or you can't afford the ongoing cost of hosting additional servers?

You are going to have to get more creative.

When you inherit a poor-performing service that is not designed to run on multiple machines, start by taking stock of the situation. The best way to take stock is with system profiling software. You can get a quick and dirty view of a system using the tools provided with Windows NT/2000 and Visual Studio. Before adding anything to the system; find out whether the bottle necks are at the network, CPU, or hard disks. With the network, usually you can just pay for a wider pipe. If you haven't already added tons of system memory, that's a no-brainer. If you still find that your CPUs are maxed out, add more. Windows NT and Windows 2000 get pretty close to linear improvements from additional CPUs. Bumping up on-board cache will help as well. If you already have as many CPUs as your server can handle, consider a new box. Despite the skyward price of four- and eight-processor servers, they often save in the long run compared with rewriting software and managing a half-dozen machines.

While most programmers are aware of the multiprocessor solution to speed up CPU-bound processes, many Web server and database applications are tethered by slow disk access. This is not surprising, considering that CPUs are solid state devices while disks are mechanical devices. If you've got deep pockets, a Solid-state disk (SSD) can catapult performance by an order of magnitude.

An SSD is a matrix of memory chips, a SCSI controller, and a mechanism to preserve data in case of a power failure. Some SSDs use nonvolatile memory, while others have uninterruptible power. While SSDs and hard drives are comparable when it comes to moving large I chunks of data, typical disk access is usually made of many very small transfers. SSDs eliminate the seek-and-rotate phase that precedes every hard disk access, so SSDs can be 10 times as fast as a physical disk.

Unfortunately, SSDs carry a price tag to match their performance: 1-GB drives cost around $I4,000. At these prices most companies can't afford to stick a whole database on an SSD. Use should be reserved for database indexes, popular tables, often-served Web pages, and frequently used operating system files. Tests show that SSD-equipped servers can turn in Web performance comparable to six or more servers.

Programmers often try to wring every bit of performance out of their target hardware. Sometimes it's better to let some amazing hardware wring the best possible performance out of the software. Wow! It's like a light bulb just went on, and I didn't have to do anything. --Eric Binary Anderson has led projects at a number of enterprise software companies and is the senior architect at IBT Financial (Bend, Ore.), an Internet-based training company. Contact him at ebinary@columnist.com.