Device Driver Tuning
Only four device drivers that ship with NT behave differently depending on
the platform they are running on. These four drivers are afd.sys, srv.sys,
nwlnknb.sys, and ntfs.sys.
afd.sys is the device driver responsible for managing Microsoft's Winsock
TCP/IP communications protocol. afd. sys performs two modifications.
1. afd.sys sets the size of the network transfer frame to 4KB if afd.sys is
running on Workstation and 64KB if this device driver is running on Server. A
larger size means that communications will usually be faster but also that
allocated buffers will have a negative impact on the system's available memory.
2. afd.sys modifies a variable according to the product type. This change
occurs where this driver sets the limit on simultaneous network file transfers
to 2 if it is running on Workstation. But afd.sys checks the Registry entry:
\hkey_local_machine\system\current
controlset\control\services\afd\parameters\maxactivetransmitfilecount for the
limit, if afd.sys is running on Server. This variation exists purely to limit
the functionality of Workstation, rather than to optimize performance.
srv.sys is the network server device driver that controls network
connections to a machine. Its check of the product type is also for
functionality limitation. About 10 of its variables are restricted to certain
values if this driver is running on a Workstation.
The most notable of these variables is SrvMaxUsers. On a Server,
SrvMaxUsers is set to an effectively infinite value. But on a workstation,
SrvMaxUsers has an upper limit of 10, allowing a maximum of 10 simultaneous
network connections to the machine. This limit applies whether the connections
are file transfers or network logons.
Unlike srv.sys, nwlnknb.sys, the NetWare network NetBIOS communications
protocol driver, queries the system type for performance-optimization purposes.
nwlnknb.sys maintains an internal cache of network routes. On Server systems,
this cache is three times larger than on workstations, apparently because a
server will need more network connections.
ntfs.sys is the file system driver for disks that are formatted with the
native NT File System (NTFS), and this driver checks the product type for
tuning. During its initialization, a call is made to MmIsThisAnNtAsSystem(), and
based on the result, ntfs.sys sets the size of 11 lookaside lists that it
creates for memory caching. Each lookaside list is dedicated to a different
temporary data structure that must be allocated during file system operations.
Again, in anticipation of more file system activity, the lists are twice as big
on large servers (according to the MmSystemSize variable), as on large
workstations.
User-Level Application Tuning
Figure 1 shows a list of the user-level components that query the system
type. These components are too numerous to allow in-depth explanation of their
behavior. However, I can highlight a few.
Winlogon checks the product type to determine which splash screen to
display, lanman.bmp (for 16-color video modes) or lanma256.bmp for Server logon,
and winnt.bmp or winnt256.bmp for Workstation logon. Explorer checks the product
type and shows a bitmap along the left side of the Start menu. The bitmap reads
Windows NT Server or Windows NT Workstation, as appropriate.
The last application in Figure 1 is windisk.exe, the NT disk administrator
program. It reads the Registry directly to determine which platform it is
executing on.
If Windisk is on a Server, it provides a Fault Tolerance menu that has
entries you can use to create striped sets with parity, and mirrored drives. On
a Workstation, Windisk does not make this menu available. This difference
explains why only Servers can create and manage fault-tolerant disks.
Several Microsoft products have setup programs that check the product type.
Notable examples are BackOffice and IIS. BackOffice refuses to install any
BackOffice suite programs, SQL Server, Exchange Server, IIS, and System
Management Server (SMS), if the product is on a Workstation.
No technical reason lies behind this limitation: Tests show that these
applications function properly if the setup program is foiled into installing
them on a Workstation.
As I mentioned earlier, the version of IIS that ships with the NT 4.0 CDs
checks the product type and installs as Peer Web Services if its setup program
detects that it is on a Workstation, and as IIS if it detects that it is on a
Server.
No Blanket Statements
Although NT Workstation and NT Server share the same bits, the few tweaks
that the system makes according to the product type can significantly affect the
performance of the systems, so that given the same workloads, one or the other
will perform better. The tuning that takes place seems to aim Workstation and
Server at different, clearly-defined workloads. However, making blanket
statements about the suitability of this tuning for all situations that can
arise in actual installations is impossible. For example, some people argue
that, with the advent of Common Gateway Interface (CGI), a Web serving NT Server
would do better to tune itself as an interactive Workstation than as a single
application Server.
NT's predefined optimizations may be suitable for many cases. However,
Microsoft was shortsighted in not giving systems administrators control over the
optimizations, rather than foisting on them one-size-fits-all solutions.