CommentCommentComment
Articles
  Windows NT News
  View Current Issue
  View Back Issues
  Search by Topic
  Search by Author
  Code Library
  Web Exclusives
  Special Reports

Hardware & Software
  Enterprise Software
  WNT Magazine Labs
  Computer Xchange

Technical Focus
  Windows 2000
  Terminal Server
  SQL Server

Resources
  Discussion Forums
  Event Calendar
  User Groups / SIGs
  Training Centers
  Career Center
  Glossary

WNT Magazine
  Subscriptions
  Advertising Info
  Editorial Calendar
  Be an Author
  Contact Our Advertisers
  International Editions

Print Newsletters
  Exchange Administrator
  Win 32 Scripting
  IIS Administrator

Email UPDATEs
  Windows NT
  Security
  Exchange Server
  SQL Server

Products & Services
  SQL Server Magazine
  WNT Article Archive CD
  Technical Videos
  Windows NT Magazine TV
  29th Street Press




Windows NT Magazine ad
Article Info
Issue: September 1997
Page: 131
Author: Sean Daily
Related Topics:
Performance
Registry

FEATURE * by Sean Daily

Set Sail for Uncharted NT Performance
Dig into a pirate's treasure of Registry gems to maximize system performance

I guess you can say that I've always questioned authority. When I hear, "Don't do that," my usual response is, "Why? What would happen if I did ?" Although my questioning nature sometimes frustrated my teachers (and perhaps contributed to a few gray hairs), such rebelliousness has its virtues. Questioning authority--in this case, Microsoft--has helped me discover new levels of system performance for Windows NT.

Mutiny on the MS Bounty
I never heeded Microsoft's decree that NT is a completely self-optimizing operating system, one that users don't need to tweak to achieve maximum performance. "Just add more expensive hardware," said Microsoft, "and the promised land of faster performance will be yours." Bah! I knew there must be ways to improve NT's performance with my existing equipment. Remembering the significant performance increases I achieved by tweaking other Microsoft operating systems, I doubted that Microsoft's developers made NT so different that they removed every possibility for the user to enhance performance. I realized that I could no longer be a mild-mannered, obedient NT user; this job clearly required a Registry pirate. With this mindset, I donned my eye patch and sword (and Registry editor), and set sail for uncharted NT performance. In this article (and in future articles), I'll log the results of my expeditions.

Pirate's Rule #1:
Default Settings Equal Milquetoast Performance
The first thing any good NT performance pirate needs to know is that default settings are usually not ideal. The good news about default settings is that they work for most users. The bad news is that they don't give everyone the best performance for a particular situation or application. After all, how can a system be truly self-optimizing if it doesn't know how you're using it? Are your applications disk bound, compute bound, or both? Does the amount of physical RAM you have far exceed your typical working set (the amount of memory a process uses or allocates), or are you running close to the edge? Do you want the highest priority to go to foreground or background tasks, or do you want execution spread evenly among all tasks? The answers to these questions significantly affect NT's performance. Furthermore, if you haven't explicitly told NT how you want the system conFigured, NT is automatically answering these questions for you. If you're like me, you'll want more involvement in the decision-making process.

Pirate's Rule #2:
The Best Buried Treasure Is in the Registry
Several Registry modifications play an important role in optimizing NT. After you understand these buried gems, you can significantly alter your system's performance. Some changes can substantially boost your system's overall speed, but inappropriate changes can decrease performance. Therefore, as I discuss each Registry modification, I'll provide enough information to help you make intelligent decisions about each change and determine which changes are appropriate for your situation. You need to be proficient in using NT's Registry editors (REGEDT32.EXE and REGEDIT.EXE) and always be prepared for disaster, which leads us to Pirate's Rule #3.

Pirate's Rule #3:
Smart Pirates Make Backups
Any modification to the system Registry, no matter how well documented or well intentioned, always involves a certain degree of risk. Any of the Registry modifications I discuss in this article can potentially damage your NT installation or make it unbootable. Therefore, you need a full system backup and an updated copy of the Emergency Repair Disk (use RDISK /S so that you get the SAM and SECURITY Registry hives in addition to the usual information that the RDISK utility backs up) before you make any changes to the Registry. I recommend that you make an additional copy of the Registry using the REGBACK.EXE utility from the Microsoft Windows NT Workstation Resource Kit or Microsoft Windows NT Server Resource Kit CD-ROMs. If your boot partition is a FAT volume accessible via an MS-DOS boot disk and the Registry becomes corrupt or damaged, you can replace the damaged version in the %SYSTEMROOT%\SYSTEM32\CONFIG folder with the uncompressed copy.

You can also restore a damaged Registry by using the option to "Press spacebar now to invoke Hardware Profile/Last Known Good menu" during NT's boot process, or by using NT Setup's option to "Repair a damaged Windows NT installation" (which uses the information stored on the Emergency Repair Disk to restore the system Registry). However, the ultimate method of performing Registry backups and restores is to use a utility designed specifically for that purpose, such as the ConfigSafe NT utility from imagine LAN. This handy utility lets you make multiple backups of your system Registry and dynamically restore your choice of versions if a problem occurs. One final utility toolkit to consider is the set of NT tools available at the NT Internals Web site (http://www.ntinternals.com and http://www.winternals.com). The NTRecover utility is handy for doing dead-system recovery when your system won't boot at all; another handy utility is NTFrob, which gives you an amazing level of control over just about every aspect of NT's file cache.

Pirate's Rule #4:
The Proof Is in the Benchmark
One final rule to keep in mind: Do not conclude that a change is effective or worthwhile until you've proved it with a benchmark. To determine the effect of a particular change, use a benchmarking utility to gain both before and after pictures of system performance. Also, remember to make only one change at a time; then, reboot the system and test. Otherwise, you won't be able to pinpoint the source of a performance improvement or degradation. I recommend two complementary benchmarking utilities that serve different purposes. U Software's Bench32 is a very effective NT and Windows 95 utility that measures CPU, memory, disk, and video performance and compares them to a baseline system. BAPCo's SYSmark for Windows NT 4.0 is a real-world application benchmark utility. Rather than measuring raw throughput for I/O subsystems, this utility measures the performance of several business applications, such as Microsoft's Word, Excel, and PowerPoint. (For more information about these two benchmark utilities, visit the U Software and BAPCo Web sites.)

First Stop: The Paging File
Let's begin our voyage by examining one of the most important contributing factors to an NT system's overall performance: the disk subsystem. NT heavily uses the paging file to swap program code and data from memory to disk and back. NT's use of the paging file is significant even on systems with large amounts of installed memory. Don't fall into the trap of believing that just because your system has lots of available RAM, the paging file goes unused. It doesn't. Although use of the paging file will certainly decrease, NT will continue to use the paging file to swap system code, user code, and data between memory and disk. Therefore, how well NT performs paging on a system is extremely important. Even systems with fast CPUs and lots of memory will suffer from a non-optimized paging file.

The steps for increasing paging file performance are simple but effective. First, in the Virtual Memory box on the Performance tab of the System applet in Control Panel, click Change to display the paging file configuration window. Set the initial and maximum sizes of the paging file to the same value. Matching these sizes reduces the inevitable and performance-hampering file fragmentation that occurs to a dynamically resizable paging file (one with a different initial and maximum size) as the system grows and shrinks the file. The maximum value needs to be large enough to easily accommodate the largest memory footprint your system will achieve; you definitely don't want your system running out of paging-file space in mid-operation. To get a sense of the maximum memory usage on your system, load all the applications you typically run, launch NT Task Manager, and check the Peak Commit Charge value on the Performance tab.

Next, spread the paging file across as many physical disks as possible, rather than placing it on one disk. This approach distributes the load across multiple independent drives and improves paging file performance. To further maximize paging file performance, place the paging file on a dedicated disk partition (preferably a separate physical disk) and set the initial and maximum paging file sizes to the size of the partition. This setup eliminates the problem of paging file fragmentation and optimizes paging performance. However, you need to format the volume as FAT and not NTFS (for more information about these two file systems, see "NTFS vs. FAT," October 1996), for two reasons: FAT is significantly faster than NTFS on smaller (under 2GB) volumes, and the NTFS file system places a second copy of the MFT (Master File Table) in the middle of your hard disk. This placement breaks your paging file into two pieces and prevents it from occupying one contiguous block of disk space. Finally, to enhance performance even further, place your dedicated paging file on a stripe set volume made up of two or more equally sized partitions on separate physical disks. Ideally, choose SCSI drives because SCSI is typically much faster for multidrive volumes such as stripe sets, mirror sets, and stripe sets with parity. You'll be amazed at the performance differences you achieve during paging file access with this setup compared with placing the paging file on a volume containing the NT operating system or applications. The performance increase is especially significant on NT systems that experience a high amount of paging file usage. However, if you have limited disk resources and you must share the disk that contains the paging file with other data, be sure to place the paging file on the least busy disk in your system.

Stop Paging the Executive
NT doesn't limit paging activity to only user applications and data: NT may page out portions of itself to disk during system operation. On systems with sufficient RAM (at least 16MB more than the average total working set of the system, including the operating system, user applications, and data), disabling NT's ability to page the Windows NT Executive to disk can enhance performance. To force this behavior, you need to find the following Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management. The DisablePagingExecutive value tells NT whether it can page system drivers and code to disk when they're not in use. The default value is 0 (allow paging); if you change the value to 1, all drivers and the NT kernel remain in RAM at all times. If you make this change, be sure your system has plenty of available memory after you load the system and user applications; otherwise, application performance will suffer. On systems with plenty of RAM, this change reduces NT's paging operations and helps improve performance.

Cashing In on Cache Priorities
Another useful disk-related performance tweak relates to NT's prioritization of the file system cache. NT constantly juggles memory used for the file system cache and memory used for running processes (services and applications). On NT Server computers, you can change this prioritization by editing the properties of the Server service on the Services tab in Control Panel's Network applet.

Screen 1 shows the Server configuration dialog box. Depending on the Optimization setting, NT either minimizes the memory used for the file cache (Minimize Memory Used), balances the distribution of memory between the cache and the running processes (Balance), favors the use of memory for the system file cache (Maximize Throughput for File Sharing), or favors the use of memory for applications (Maximize Throughput for Network Applications). In a future article, I'll detail the effects these settings have on the system and look at another problem concerning this entry.

Although this procedure works fine for NT Server, what about NT Workstation? If you attempt to conFigure the Server service on an NT Workstation, you get a message that you cannot conFigure the service. Should you accept this statement? Heck, no! You can conFigure NT Workstation with the same entries as NT Server; however, you must manually edit the Registry. The following Registry values control the file system cache prioritization: LargeSystemCache in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement and Size in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters.

Microsoft's documentation states that configuring the Server service affects only the LargeSystemCache value. However, examining the Registry during Server configuration reveals that both values change. Table 1 summarizes Server configuration options and the corresponding LargeSystemCache and Size values. The default values are the settings for the Minimize Memory Used option, which minimizes the memory NT allocates to the system cache and the working set of processes.

If you have plenty of RAM on your system and want to realize significant increases in disk performance, try changing the Registry values to the settings for the Balance or Maximize Throughput for File Sharing options. The Balance option balances memory usage between the file system cache and the process working sets, but it uses a larger file system cache than the cache it uses with the default setting. Maximize Throughput for File Sharing prioritizes the cache over the working set of processes; consequently, it may not be the best setting for workstations.

On some systems, I've seen disk performance increase from 5 percent to 50 percent after making one of these changes. However, you'll need to experiment with different LargeSystemCache and Size values and benchmark results before and after the change to find the best settings for your system. In most cases, you'll find that the Balance settings give the best overall performance.

On NT systems with insufficient amounts of free physical memory, setting LargeSystemCache to a non-zero value usually increases paging file activity because memory usage is prioritized in favor of the system cache rather than system processes. If applications need additional memory, the extra memory usually comes from the paging file. The resulting increase in paging file activity typically reduces overall system performance.

Turbocharging NTFS
If you're using NTFS on your system, several changes can help you increase the file system's speed. The first and most basic setting is one that NTFS chooses automatically when you format a new NTFS partition: the volume's cluster size (NTFS allocates disk storage in units known as clusters). Typically, NTFS selects the volume's cluster size (measured in bytes) from a list of defaults that relate to the volume's total capacity. Table 2 lists the default cluster sizes for ranges of volume size.

Usually, the default cluster size provides good performance; however, reformatting the volume with a different cluster size can enhance performance in some environments. Unfortunately, to change cluster size, you must back up the entire volume to tape (or to another volume), reformat the volume with the new cluster size, and then restore the data. You can use NT's Disk Administrator utility, as shown in Screen 2, or use the FORMAT command from the NT command prompt to specify the cluster size when you format NTFS volumes. The syntax for the FORMAT command is

FORMAT <drive>: /FS:NTFS /A:<size>

where drive is the drive letter of the drive to format, and size is the cluster size to use on the new volume (512, 1024, 2048, 4096, 8192, 16K, 32K, or 64K). This setting overrides the default cluster size. (At cluster sizes above 4096, NTFS does not support some features, such as NTFS compression and virus checking.) A third method for specifying cluster size is to double-click My Computer on the desktop, right-click the volume, and select Format. When the Format dialog box appears, simply change Allocation Unit Size to a value from the drop-down list.

Changing a volume's cluster size may be appropriate depending on the type of files on the volume. For example, a volume with a large number of small files may perform better with a small cluster size, whereas a volume with a few very large files may perform better with a large cluster size. Be sure to benchmark each cluster size scenario with lengthy file I/O operations, using files of different sizes if possible (Bench32 lets you test disks with files from 1MB to 20MB in size). If you experiment with different cluster sizes, start small: Move up or down one cluster size at a time and then retest. Once you find the cluster size that yields the best performance for the average file size to be stored on the volume, you can restore the data to the volume.

NTFS is a sophisticated file system, and features such as the extended attributes that NTFS files use to support NT permissions increase overhead to your system. Certain default NTFS behaviors can unnecessarily reduce your system's performance. One such behavior is the automatic generation of 8.3 DOS-style filenames for all files stored on NTFS volumes. Because NTFS must generate an 8.3-style name for each new file created on the volume, write operations with such names take longer than write operations that use only long filenames. If your network doesn't include any DOS or Windows 3.x clients, you can disable this automatic feature. In the Registry, change the value of NtfsDisable8dot3NameCreation to 1 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem.

Several points are important to keep in mind about this procedure. First, be sure that your network does not now contain (and will not contain in the future) any systems that use DOS, Windows 3.x, or Windows for Workgroups 3.x. These systems cannot use NTFS files without 8.3-style names. Second, be aware that changing this Registry value affects only future files stored on the volume. Existing files retain their 8.3 version names until you remove the files from the volume. If you want to start with a clean slate, set the Registry value to 1, move all the files to another volume or tape, and then move them back to the original volume.

As long as we're in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem, I'll point out another file system-related setting that can improve NTFS performance. The NtfsDisableLastAccessUpdate entry controls whether NTFS updates the LastAccess time/date stamp on directories as NTFS traverses the directory structure. Disabling updates can also reduce NTFS overhead, without significantly impairing functionality. The default value is 0 (NTFS updates directory time/date stamps); change the value to 1 to disable updates. If you don't see the NtfsDisableLastAccessUpdate entry, you can manually add it as a REG_DWORD type with value 1. However, if you add this entry, be very careful to spell the name correctly, including capitalization.

Here's one last item on disk performance optimization: Whenever possible, keep the amount of free space on a physical disk at 40 percent or more. When the amount of free space drops below 40 percent, the disk takes significantly more time to find free space to write data. Although you can mitigate this effect by regularly using a disk defragmentation tool (e.g., Executive Software's Diskeeper or Symantec's SpeedDisk utility in Norton Utilities for Windows NT), you'll still experience a significant performance hit on a crowded disk.

X Marks the Spot
As with all system-tuning modifications, I highly recommend that you first try the modifications I've described in this article on non-production machines before you change your network servers and workstations. Occasionally, you may find hidden ramifications that affect particular applications. By testing the modifications first, you reduce the possibility of any unpleasant surprises. Finally, remember to benchmark system performance before and after each system modification so that you can quantify the performance effects of each change. You might also want to consider doing each benchmark twice or (even better) doing the tests on two different systems. This tactic gives you a more objective test and helps reduce the possibility that some software or hardware peculiarity will interfere with the accuracy of your tests.

Contact Info

ConfigSafe NT
imagine LAN * 800-372-9776 Web: http://www.imagine-lan.com/ Email: sales@imagelan.com

Bench32
U Software
Web: http://www.usoftware.com
Email: usoft@usoftware.com

SYSmark for Windows NT 4.0
BAPCo * 408-988-7654 or 800-321-0457
Web: http://www.bapco.com
Email: cramco@interpath.com

Windows NT Magazine ad
Duke Communications   Windows NT Magazine | SQL Server Magazine | Solutions Shopper | 29th Street Press | NEWS/400 | Selling AS/400 Solutions | Business Finance Magazine
Bugs, comments, suggestions | Legal & privacy notices | Advertising
© 1999 Duke Communications International, Inc. All rights reserved.