Performance Testing
First, it is taken
as a given that benchmarks suck. There is no "End all" of benchmarking
software, nor even a valid "suite" that give truly useful results.
This is especially true in networking,
client/server environments. In serving files an infinite number of
things can change from benchmark run to benchmark run.
BUT, we must use benchmarking in times when things seem to be performing poorly. I will further illustrate with a true example.
I work for a Civil Engineering
firm called "Construction Engineering Services". We moved from a
peer-to-peer network over to a Linux file server over 2 years ago.
At the time, my distribution of choice was slackware. The server
had the following specs
Slackware Linux 3.4, running 2.0.34 kernel
P233MMX
Asus AT mainboard
Server case with 1 redundant power supply
2 5400 RPM IBM Deskstar Ultra Wide Harddrives (4 gig apiece)
3Com 905B network card
cheasy ISA video, no monitor and a borrowed keyboard'
Hamster on a treadmill was a HP Powerwise 1100 (big battery)
No outside access, at all.
Network is 100Mbit, 3Com Superstack II hub, 16 port
This specific office is somewhat unique in that all the employees
have a high level of understanding of filesystems, printing, etc.
A certein level of performance was expected. There is no file system
security. There are no permissions, everyone has free range over
the entireity of the server. Primary, OK, only application at the
time was Autocad R13. Autocad R13 was/is notorious for being a cheap
hack of ACAD 12. File read performance on a local hard drive is what
it was designed for, and that barely worked. Upper file size limit
before acad corrupted things was roughly 3 -5 MB. Local reads, on
a completely SCSI system are easily in the .5MB/s range. Oddly enough,
it opening a 3 MB file would require waiting 20-30 seconds. In order
to make everybody happy, it was necesary to duplicate this performance
on the server.
File opens of a 3MB standard file, with no Xrefs,
no blocks, just lines, took greater than 4-10 minutes to open. This
was very unacceptable. Typical transfer rates while opening an acad
file were in the 8-20K/s range. This is bad.
The first thing I did was suspect the clients, the clients are all Windows NT 4.0 Workstations, Service Pack 3. At the time most of them were PPRO 200s on Tyan mainboards with that same 3Com 905B network card, matrox milleniums, 64-128 MB ram. Regressing to Service Pack 2 and SP1, and no SP, was of no use. Performance was best with SP3. For benchmarking, I used standard NT Performance Monitor running on the workstations. FTP File transfers were very fast easily in the 2-3 MB/s range, so I began focussing only on SAMBA. I established a Novell Netware 4.11 server, to try to locate the problem, but it also showed identical poor performance.
Around this time, things are desperate, I start a new network with a cheap hub, a 486, and NE2000 network cards. performance improves maybe 20% in acad, but more importantly transfers appear more stable, and much consistent. Adding TCP options to samba helped considerably the most important one appeared to be one called SO_SNDBUF=8192. Throughout all this the SAMBA community was offering advice. Around this time other people began reporting problems with the 3com 905b. At the office we now use intel nics.
The server was brought down over christmas break, and upgraded from Slackware 3.4 to RedHat 6.0 The above config file is for RedHat 6.0. Other upgrades included a replacing the old 4.5 gig Raid1 array with new 9GB 10,000 RPM SCSI IBM drives. These afford a large increase in noise, and heat. Both of which make the server look cooler.
Transport is TCP/IP only. No IPX/SPX, at all.
Most clients have been upgraded to Intel EtherExpress Pro100 NICS.
PRINTING
We have 2 printers online.
1. Hewlett Packard DesignJet 600, size D Plotter. It has 2 feeds, 1 is roll of vellum drafting paper, the other is manual feed Sheets of paper. Plotter has 12MB of memmory, and is telnet configurable. it has an actual IP, and appears as one of the printers shared by the linux box.
2. Hewlett Packard laserjet 1100. attached to linux box's parrallel port.
both printers work flawlessly. Printing is the single most important task of the server.
The implemented print commands are LPR and LPQ. The commands required
to print will vary from distribution to distribution. These commands
work under Red Hat 6.0