The following issues affect IIS performance:
Installation of filters that are not cache-aware.
The installation of a filter that is not HTTP-cache-aware causes IIS to completely disable caching, which results in poor performance. Old ISAPI filters that were written before IIS 6.0 can cause this behavior.
Common Gateway Interface (CGI) requests.
For performance reasons, the use of CGI applications for serving requests is not recommended under IIS. The frequent creation and deletion of CGI processes involves significant overhead. Better alternatives include the use of ISAPI application and ASP or ASP.NET scripts. Isolation is available for each of these options.
NTFS File System Setting
Under HKLM\System\CurrentControlSet\Control\FileSystem\ is NtfsDisableLastAccessUpdate (REG_DWORD) 1.
This system-global switch reduces disk I/O load and latencies by disabling the updating of the date and time stamp for the last file or directory access. This key is set to 1 by default. Clean installations of Windows Server 2008 set this key by default and you do not need to adjust it. Earlier versions of Windows operating systems did not set this key. If your server is running an earlier version of Windows or was upgraded to Windows Server 2008, you should set this key to 1.
Disabling the updates is effective when you are using large data sets (or many hosts) that contain thousands of directories. We recommend that you use IIS logging instead if you maintain this information only for Web administration.
Warning: Some applications such as incremental backup utilities rely on this update information and do not function correctly without it.
See “Performance Tuning for Networking Subsystem” earlier in this guide.
Performance Tuning for File Servers
You should select the proper hardware to satisfy the expected file server load, considering average load, peak load, capacity, growth plans, and response times. Hardware bottlenecks limit the effectiveness of software tuning. “Performance Tuning for Server Hardware” earlier in this guide provides recommendations for hardware. The sections on networking and storage subsystems also apply to file servers.
This section provides an overview of the Server Message Block (SMB) model and introduces the SMB 2.0 protocol. The SMB model consists of two entities: the client and the server.
On the client, applications perform system calls by requesting operations on remote files. These requests are handled by the redirector subsystem (rdbss.sys) and the SMB mini-redirector (mrxsmb.sys), which translate them into SMB protocol sessions and requests over TCP/IP. Starting with Windows Vista, the SMB 2.0 protocol is supported. The mrxsmb10.sys driver handles legacy SMB traffic, and the mrxsmb20.sys driver handles SMB 2.0 traffic.
On the server, SMB connections are accepted and SMB requests are processed as local file system operations through NTFS and the local storage stack. The srv.sys driver handles legacy SMB traffic, and the srv2.sys driver handles SMB 2.0 traffic. The srvnet.sys component implements the interface between networking and the file server for both SMB protocols. File system metadata and content can be cached in memory through the system cache in the kernel (ntoskrnl.exe).
Figure 6 summarizes the different layers that a user request on a client machine must pass through to perform file operations over the network on a remote SMB file server that uses SMB 2.0.
  
Figure 6. Windows SMB Components
|
