The Midas Touch
If the software remedies don't work, then the only alternative is to buy some hardware. Getting faster disk hardware partially boils down to what you'd expect: buy disks with faster (smaller) seek times and better (bigger) data-transfer rates.
Cheap multigigabyte drives are widely advertised with data-transfer rates of 4MB per second (MBps) and up, so that's a beginning. And be sure to use 32-bit, bus-mastering disk adapters. I see a surprisingly large number of 16-bit disk adapters in the servers that I run across when consulting. Slow adapters are a real "no-no."
While the low price of IDE drives makes them tempting, buy a SCSI drive instead due to the greater flexibility that it offers and its ability to do asynchronous disk I/O. All IDEs and many SCSI systems that include more than one physical hard disk cannot perform simultaneous I/O on those disks, believe it or not. If you make simultaneous requests of multiple drives, they'll be handled one at a time, rather than letting the drives all seek at the same time.
On the other hand, SCSI host adapters that support asynchronous I/O can keep all your disk drives busy at the same time. You should look for that feature when buying host adapters (most SCSI adapters don't support asynchronous I/O, and no IDEs do under Windows NT).
If you have a host adapter that supports asynchronous I/O, then exploit that power with stripe sets. Use the Disk Administrator to create a stripe set across a number of drives. As a stripe set distributes a disk's data across several drives, reading the data can be quite fast, working all of the physical drives on the stripe set in parallel.
The Network Interface
Although most of the process of tuning file servers lies in the disks, some of it can be achieved with the network interface. As with disks, many improvements come from better hardware--32-bit bus mastering boards and faster underlying networks. But there are some software tweaks available as well.
Look in Perfmon in the Server object "Bytes Total/sec" and compare that amount to the rated medium speed (10 megabits per second (Mbps) or 100Mbps for Ethernet, 4Mbps or 16Mbps for Token Ring). If your server's total network throughput is anywhere near the network medium's speed, then you're working the network too hard, feeding it more data than it can transport. Is it possible to segment the network, add a router or two, or perhaps shift some workstations to another segment?
On an Ethernet, even a network throughput of about 0.8MBps is worrisome, as Ethernets tend to become collision-ridden at the two-thirds utilization mark. Token Rings can reach the speed of the networking medium (0.5MBps or 2MBps, depending on the type) without a loss in performance. And, in the extreme, you can always go to the faster version of Ethernet (100Mbps) or Token Ring (16Mbps).
Trim a Few Protocols
Another way to streamline the network end of a server is to trim extra unnecessary protocols. Do you need to keep NetBEUI on your system?
Running NetBEUI in combination with NWLINK on a network that really only needs NWLINK generates extra network traffic and forces the server software to do twice as much work. It has to respond to both the meaningful NWLINK messages and the extra NetBEUI chatter. If possible, you should choose one protocol--NetBEUI, TCP/IP, or NWLINK--and use only that for the file server. I use TCP/IP on some of the file servers at my firm and get excellent results from it.
Rearranging network bindings can sometimes provide better throughput. Click on the Bindings button in the Network applet of the Control Panel, select NetBIOS, and choose the order in which to bind the transport protocols to it. NetBIOS is the network binding interface that the Windows NT file-server software sits atop.
However, Windows NT ships with three protocols--NetBEUI, TCP/IP, and NWLINK--that all have NetBIOS interfaces on them so they can provide services to the server software. Thus, the server software has "too many options," slowing down the process of serving the files (hence, the earlier recommendation to remove protocols). If you can't exclude a protocol, then you can use the binding order to establish which protocol has first crack at the server requests.
And, finally, a few file-server tuning odds and ends:
- If you are using TCP/IP and the Windows Internet Name System (WINS), then binding the NetBIOS to TCP/IP will greatly reduce system broadcasts.
- If you are using Windows for Workgroups (WFW) workstations and TCP/ IP, be absolutely sure that you have installed the version of WFW that is on the NT CD-ROM, or at least the update files. They will radically affect TCP/IP performance.
- Interrupt Request 10 (IRQ10) has a slightly higher system priority than the more commonly used IRQ5 does, so employ it for your boards when possible.
There is no generally accepted benchmark for network performance that is both generic--runs on all networks--and nontrivial. My tests with TCP/IP drivers on Ethernet and Token Ring cards show that if you can enable shared RAM on your network cards, then you should. Use it as much as possible. This does not apply to bus-mastering EISA, Peripheral Component Interconnect (PCI), and Micro Channel cards; shared RAM doesn't seem to improve their performance.