Tuni ng NT: Is It Worth Your Time?

Our Findings Generally, adjustments to NT made via its GUI tools or in the registry did not offer significant enhancements to database performance or file throughput. Regardless of the memory-optimization settings we made, we did not see significantly better throughput or average response time over the 20, 35 and 50 motors used. However, we did find that the placement of the virtual memory swap file has a notable impact on database performance. And it was no surprise that adding memory substantially increased the performance of our SQL database. To illustrate the point regarding RAM usage, we ran SQL Server on our server configured with 96 and 256 MB of RAM. As you can see in "Database Read Test" (at left), we found a dramatic increase in SQL performance when we increased the RAM from 96 MB to 256 MB . Our data set was approximately 750 MB in size. Oddly enough, we found the most dramatic impacts on NT performance were made simply by tailoring NT's run-time environment to its dedicated task. NT caters to the masses and runs many services by default. A number of these services are unnecessary for specific tasks (see "Services That Can Be Stopped," page 128). By disabling the unnecessary services, we freed almost 4 MB of RAM. Although this may not seem like much, every little bit helps. Getting Down to Business Our first bank of testing centered around NT's swap file and its location (see "Swap File Placement Test" below right). We found noticeable performance differences in our server, depending on where the swap files were located. The greatest number of database transactions per second were realized when the swap file was on our RAID 5 disk array along with the SQL Server database files. The next set of gains were realized when we configured the server to use two swap files, each on a separate external SCSI disk. Intuition dictates that the fastest performing physical disk generally will result in the best paging performance. When we ran our tests with the swap file on the RAID array, for example, the disk queue length averaged nearly zero. The higher performing RAID array, with 32 MB of cache, 9,600 RPM drives and UltraSCSI device chain, was able to service disk requests much faster than the external SCSI disks. Yet our results clearly indicate that NT benefits from the ability to distribute swap files across multiple devices. In this case, NT takes advantage of the asynchronous I/O between matched (identical make and model) disk devices. This is a huge benefit for such a critical resource (virtual memory), but this should not be viewed as a substitute for real memory. During testing, we learned an important lesson. Don't make broad assumptions about your se rver and potential bottlenecks. A system bottleneck often is not where you think it is. This is why tools like Performance Monitor are essential. By running a series of tests and changing system parameters, Performance Monitor let us quantitatively and objectively pinpoint system bottlenecks.

Other Workshops Thwarting Malicious Java Attacks By Gregory Yerxa