On The Wire

Finding The World's Easiest Server Optimization

Scott: The last time we saw this, didn't somebody try to oil the bearings on the server's hard drive?

Bill: Bah. They weren't sheepish about adding RAM.

Scott: Seriously, this is one of those problems where there could have been a million things contributing to the server's sluggishness.

Bill: Without a little forensic analysis, one might be tempted to simply upgrade the serv er with a more powerful processor, faster hard drive, more memory or a new platform altogether.

Scott: Of course, the bottleneck also could be somewhere in the network infrastructure with its many Ethernet segments, switches and routers.

Bill: Which naturally calls for an ATM upgrade.

Scott: But before resorting to an Automatically Take your Money upgrade, we wanted to see if we could isolate the cause. We moved a workstation onto the Ethernet segment of one of the servers having the problem and analyzed from that segment.

Bill: By studying a trace of a file transfer from the server to the workstation during periods of low network activity (so we didn't have to worry so much about contention for the Ethernet), we could see which end was nonresponsive.

Scott: The first thing we noted was that the workstation (running Windows95), was communicating with the NT server using the Server Message Block (SMB) protocol over IPX.

Bill: H mmm... Maybe the Microsoft implementation of a Novell protocol was the problem.

Scott: The workstation also was requesting a file read from the server using the SMB "Read Block Multiplexed" protocol, which allows several packets' worth of data to be returned by the server for each read request. During this burst, the file transfer rate was nearly 1 MB per second, or within 20 percent of the theoretical maximum of Ethernet.

Bill: On closer examination, we noted that the workstation requested the next chunk of file close to one millisecond (ms) after having received the previous data, but it took the server from 100 ms to 150 ms to respond the workstation's request (see chart above).

Scott: Thus the workstation was doing its job well, but the server wasn't. In fact, the average file transfer rate was around 100 KB per second.

Bill: Something must have been eating up the server or it had the world's slowest hard drive.

Scott: We went to the s erver and pressed a key to bring up the desktop (since a screen saver was running). The customer was right: There were no applications running from the desktop.

Bill: Wait a minute. Did you just say "press a key?" Isn't that exactly what we alluded to at the beginning of this column?

Scott: That's right. So what do you suppose happened when we re-analyzed?

Bill: The file transfer rate then improved to more than 750 KB per second sustained!

Scott: But the instant the screen saver kicked in, it dropped back down to an anemic 100 KB per second.

Bill: So there was an "application" that ran after all--the screen saver.

Scott: When someone had to examine something on the server, naturally the screen saver stopped and performance improved...

Bill: At least for 10 minutes, after which the screen saver kicked in again.

Scott: This wasn't just any screen saver. It was the 3D Pipes, an Open Graphics Language (O penGL) screen saver...

Bill: Which chews up the CPU and grabs it for a brief time before releasing it.

Scott: Apparently an NT systems administrator decided the Pipes screen saver looked cool, and made it the default on all the NT servers.

Bill: The moral of this story is not to run those OpenGL screen savers on your NT server, no matter how cool they look.

Scott: Pick a more benign screen saver like Mystify, or better yet, a blank screen.

Bill and Scott can be reached at otw@ pmg.com. Portions of trace files from selected columns are available via Pine Mountain Group's Home Page (www.pmg.com).