Tuni ng NT: Is It Worth Your Time?

Our next bank of testing examined the performance differences between FAT (File Allocation Table) and NTFS (NT File System). The accepted rule of thumb has been that FAT is much faster than NTFS for smaller volumes (less than 2 GB), but our testing showed that in some cases there is a negligible performance difference. FAT was only slightly faster than NTFS on disk reads and writes. We tested throughput on 500-MB and 1-GB volumes. In both instances, we used 1-KB and 64-KB files with the Dynameasure file services test. Additionally, we adjusted the allocation unit on our 1-GB NTFS volume from 4 KB to 64 KB. Regardless of the configuration changes, there were no perceptible performance differences. If performance has been the only thing holding you back from NTFS, we suggest you make the switch. Remember, your mileage will still vary due to a number of factors. For example, file size, drive type, block sizes used by your RAID controller, disk configuration (RAID 0, 1, 3, 5), the amount of RAM on the RAID controller and network congestion all affect throughput. Another area of NT tuning we explored was server performance parameters (used for adjusting memory usage), found in the Services tab of the Network Control Panel. NT offers four choices for tuning server performance: Minimize Memory Used, Balance, Maximize Throughput for File Sharing and Maximize Throughput for Network Applications. To determine how each of these settings affects file transfers, we turned to Dynameasure. We measured throughput using a maximum of 30 motors on eight physical machines. Our data set was a 154-MB file using a 0 think time for each motor. Results can be seen in "Bidirectional File Throughput Te st" below. We were surprised by our results. After retesting a number of times, we found little variance in our figures. It is interesting to note, however, that the setting for Maximize Throughput for File Sharing provided the slowest performance with 30 motors. Hide and Seek Our first tests stayed within the safe confines of what can be tuned via the NT GUI. Our next set of tests examined the hidden world of the NT registry. The effect these tests had on system performance can be seen in "Registry Modification Test" below. Note that the setting for Maximum Throughput for the File Sharing was used as a benchmark. One word of caution: Modifying the registry can be dangerous. Perform a full backup of your server--including the registry--before making changes. Our first registry setting test examined the impact of disabling the automatic creation of 8.3-style file naming for NTFS volumes. Although we did not find this offered significant gains over our baseline setting, which had 20 motors, it did offer increases with 35 and 50 motors; the average response time decreased significantly and throughput was a little less. To disable automatic creation of 8.3 naming, change the HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ FileSystem\ NtfsDisable8dot3NameCreation key from 0 to 1. Our second bank of registry modifications dealt with increasing the number of buffers used by the NT network redirector. If more buffers are available to the redirector, network performance should increase. However, substantial performance increases were not to be found. To make this change, go to the following registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManWorkstation\Parameters and add an entry for MaxCmds (type REG_DWORD). You will also need to add a MaxThreads (type REG_DWORD) entry. Be sure to use the same value as MaxCmds. Permissible values for each are in the range of 0 to 255, with a default of 15. We found that this setting also decreased server response time, but not to the ext ent the 8.3 file name creation setting did. In addition to the do-it-yourself tips we've provided, third-party products are available that claim to provide NT performance enhancements. One of these, MCSB Technology's AutoPilot P/SA works by reprioritizing NT thread execution. We installed AutoPilot on our server and found only a slight increase in performance in our database read test (see "MCSB Database Read Test" below). We also found an increase in both throughput and a reduction in response time when AutoPilot was active. On the mixed "Database Read/Write Test," (below), AutoPilot did not noticeably increase performance. MCSB indicated to us that its product does enhance performance for an application whose threads are essentially performing the same series of tasks, such as Microsoft SQL Server. But adjustment to the scheduling of these threads has little effect on the workload as a whole. You are more likely to see an increase in performance in a n application like Exchange or other complex messaging/groupware systems. Jay Milne can be reached at jmilne@nwc.com.

Other Workshops Thwarting Malicious Java Attacks By Gregory Yerxa