Keep One Eye on the Disk, the Other on the Network Interface, and Pare Down the Protocols.
When you set up your Windows NT network, you probably played around with the Performance Manager (Perfmon), an extremely powerful--and free--tool. But once you start working with it more regularly, you realize that you're faced with an embarrassment of riches: There are a lot of things that you can monitor with Perfmon. Furthermore, you want to monitor different kinds of things depending on what your Windows NT Server does. NT Servers tend to act primarily as either file servers or application servers--two very different tasks. Let's look at how you tune an NT-based file server.
The Bottleneck Battle
In a file server, you usually find bottlenecks in either the disk subsystem or the network interface. (Actually, through its indirect role in memory management--a common application server bottleneck--the disk drive has the dubious honor of being a source of bottlenecks for both file servers and application servers.)
There are a few ways you can recognize a disk bottleneck. Watch the object PhysicalDisk and the counter "percent disk time" in Perfmon. If the disk usage time gets up around 90%, you have a problem.
Realistically, though, this isn't much of a revelation: After all, most network administrators reflexively peek at the server's disk light whenever they pass by it, and, if the hard disk access light is constantly turned on, they don't need Perfmon to tell them that they're disk-bound. (By the way, none of the Perfmon counters for disk activity will work until you open a command line, type diskperf -y, press Enter, and restart the system.)
A more subtle, but just as useful, indicator is the "disk queue length," another counter in the PhysicalDisk object. The disk queue length is an artifact of NT's multitasking nature. Just as many people may want hamburgers from McDonalds simultaneously, creating a line at the counter, so can a number of NT processes all want data from the centralized Disk Manager process at any point in time, leading to a line-up for the disk.
If the line becomes too long, it's an indication that you need to expand the disk bandwidth in some way. "Too long" in this case means that if the average disk queue length has more than two processes waiting, then you've got a disk bottleneck.
When you're trying to break a disk bottleneck, the first line of attack is usually to optimize the disk cache. However, that's not an option for Windows NT administrators: NT sets its own cache size, and there's nothing you can do to change it.
Software Remedies
You have two main software options that enable you to adjust a disk bottleneck. The first is load balancing.
If you have several file servers, compare the performance numbers for them to see if one server's disk is working a lot harder than the others. If it is, you can move some data from the busier server to another one that is less busy. For example, you could move some people's home directories, or, as one particularly cynical systems administrator said to me, you could "move the games."
The other software remedy is to adjust the relative priorities of the file server and the print server. The file-server thread in Windows NT has a lower priority than the print-server thread, so you can boost the priority of the file-server thread if you want to see quicker responses to file requests.
This is, of course, something of a zero-sum gain; you'll be slowing down print-service requests when you do this. Furthermore, it doesn't really break the disk bottleneck, as the print server is somewhat disk-bound also; however, users tend to be more sensitive to file-access response times than to print-access response times.
Print-server priority, by default, is set to 2, and file-server priority, to 1; the larger the number, the higher the priority. You change the file server's priority by modifying the Registry in the current control set; in Services\Lanman\Server\Parameters, you add the value entry ThreadPriority of type DWORD and set it to 2.