Before you drop big bucks for a faster Web server, try tweaking

As the visit odometer for your World Wide Web site starts turning over faster, your
server performance may bog down.

But that doesn't mean you have to rush out and buy a bigger server with a faster
processor. Try tweaking first.

On government networks with multiple Web servers, there's a lot you can do to empty the
sludge out of the circuits. Make the fix now if you can, because overloaded machines will
deny service to visitors and cause network failures.

Upgrade Web server software. This is especially important for software more than two
years old. Newer server packages take advantage of the "keep-alive" option in
the Hypertext Transport Protocol 1.1.

HTTP 1.1 lets a browser keep open a connection to the server for multiple requests,
which avoids the TCP/IP startup and shutdown operations between requests.

If most visitors tend to view multiple pages on your server, you could squeeze out up
to 10 times as much performance this way.

Another new feature in some Web packages is support for batch requests multiplexed over
one TCP/IP connection. This speeds connections even more, putting a lot of new life in
your old hardware.

Run benchmark tests on your Web server software. Some Web servers don't take full
advantage of multithreaded operations. They may perform fine at moderate loads but bog
down significantly as load increases.

Unfortunately, testing Web server software isn't as easy as testing raw CPU
performance. To do it, you must have a test server and one or more client machines in a
controlled setting.

The most unbiased Web benchmark suite is probably SpecWeb96 from the Standard
Performance Evaluation Corp. of Manassas, Va. The SpecWeb96 test measures server
performance handling HTTP requests for static Web pages. It sends requests from client
machines, then measures the response time for each request.

The assigned score represents the maximum benchmark operations per second.

If you benchmark several server software packages on the same machine, you may be
surprised to learn that it's not the processor that's the bottleneck--it's the software.
SPECWeb96 costs $800 on CD-ROM. Visit http://www.specbench.org/osg/web96/.

A cheaper approach is WebStone, a Web server benchmark test originally developed by
Silicon Graphics Inc. You can download a copy at http://www.sgi.com/Products/WebFORCE/WebStone/
to test servers running Unix or Microsoft Windows NT.

In some ways, WebStone is more flexible than SpecWeb 96. You can change some parameters
and modify the code and workload. But that's also WebStone's weak point. When you hear
WebStone numbers quoted, you don't always know the configuration details that produced
them. In contrast, SpecWeb96 imposes strict rules and full configuration disclosure.

Bump up the RAM. When a server runs several processes simultaneously, it needs a lot of
RAM space to play in. A busy machine should have at least 64M, preferably more. Sometimes
when it's running fast and furious, a server will keep client connections for a while even
when the clients are finished. Extra RAM gives you more margin to tolerate such mistakes.

Check the disk subsystem. A collection of disks and the hardware that connects them to
the host can be a hidden bottleneck. The Unix iostat command lets you check input and
output status.

You can also consult the system activity report to see whether response time is
degrading. Defragmenting, fine-tuning or even replacing the disk subsystem will distribute
the data more evenly over available disks and improve response time greatly.

For Sun Microsystems Inc. servers, read a good book called Sun Performance and Tuning:
Sparc and Solaris. Visit http://www.sun.com/smi/ssoftpress/books/Cockcroft/Cockcroft.html.

If there's a search engine on your main Web server, consider moving it to a
supplemental machine. Perhaps you're not sure how much processing time the search engine
eats up. Turn on your system accounting report and keep daily and monthly accounting
summaries.

If visitors use your search function a lot, this may be eating up more processor cycles
than the Web server itself. The accounting tools let you measure CPU time, RAM and disk
input-output, indicating how many searches per second the system can actually support.

Increase the bandwidth of your Internet connection. Each day brings more competition
for bandwidth from things like UseNet, e-mail and news services with push functions.

Consult your network's monitoring tools to see how close to capacity you're running,
and use a packet sniffer to see just how much of the traffic is coming from your Web
server and how much from other sources. If you're nearly full, your Net connection is the
first place to upgrade.

Any of these problems alone will slow down the response time you see on your network.
Taken together, they give the impression that you absolutely must buy new hardware. Fix
them all, and you could prolong the life of a Web server you thought was headed for the
scrap heap.

Shawn P. McCarthy is a computer journalist, webmaster and Internet programmer for GCN's
parent, Cahners Publishing Co. E-mail him at smccarthy@cahners.com.