Part 1 | Part 2
Previously, I explained how inefficiencies in an NTFS can slow down a system and suggested a few ways Windows administrators can format
Disable last access date
As most administrators know, the NTFS was created with security in mind. Of course, some NTFS security features are more important than others. One security feature that you might be able to live without is the mechanism that updates the date and time a file was most recently accessed. Although this type of information can sometimes be handy, refreshing a file's last access date and time stamp does consume I/O cycles. If you aren't worried about knowing the last time that files on a volume were accessed, you can disable this feature to give NTFS performance a minor boost.
Before I continue, I should clarify that the information for when a file was last accessed is completely separate from the info that may appear in the Windows Security log. The date and time information that I'm about to show you how to disable resides at the file system level, so you can still audit file access through Windows even if you disable this information.
With that said, you can format NTFS to disable this mechanism by opening a Command Prompt window and entering the following command:
FSUTIL behavior set disablelastaccess 1
In this day and age, antivirus programs are essential. In almost every environment, going without antivirus protection is simply too risky. Unfortunately, the process of scanning for viruses has a direct impact on disk volume performance.
You can't really get away with not having antivirus protection, so the next most logical step is to minimize the impact that antivirus software has on system performance. Since some antivirus applications have a much larger impact on system performance than others, the best place to start would be to do some performance testing using several different antivirus products.
While testing antivirus products, keep in mind that the product that has the least impact on system performance may not necessarily be the best solution. I say this because while most of the antivirus products out there have basically the same capabilities when it comes to detecting and removing viruses, some applications do a better job than others of detecting things like spyware and adware. This is important because your performance tests are going to be completely invalidated if you have to run a separate antispyware program.
Antispyware programs often have just as much of an impact on NT file system performance as antivirus programs do. From a performance standpoint, you'll usually be better off running a single antivirus application with built-in antispyware protection than running separate applications. Of course, I am only looking at the issue from a performance standpoint. In the real world, you have to consider which solution gives you the best protection against malware.
There are two different schools of thought in regard to disk compression and NTFS performance. My personal opinion is that compression generally hurts NTFS, since it adds a degree of overhead to the system. Reading a compressed file involves reading the file and decompressing it. If the file is saved, then the recompression process essentially re-creates the file. Therefore, my recommendation is not to compress NTFS volumes if you are interested in performance.
As I mentioned before, though, some people believe that compression can actually improve NTFS performance. While there might be a plausible argument for this in certain situations, I generally tend to disagree. Nevertheless, I wanted to share this opposing viewpoint so you could make up your own mind.
The argument that I have heard most often from people who believe that compressing a volume improves NTFS performance is that the files on the volume consume fewer clusters once they are compressed. In turn, Windows is able to read the files more quickly than it would if the files were not compressed because it takes less time to read a small file than a large file.
The main reason I disagree with this viewpoint is because it essentially ignores the decompression process that occurs when files are accessed. Unfortunately, I don't have any benchmark data to share with you that proves that one method is faster than the other. One thing I can tell you for sure though is that the decompression process can be CPU intensive. Therefore, if your computer is already low on CPU resources, then reading compressed files will almost certainly take longer than reading non-compressed files. After all, you're creating an additional workload for a CPU that is already struggling to keep up.
As you can see, when it comes to optimizing new technology file system performance, often you can find performance gains in unlikely places. Features that were originally designed to help improve system security often hamper performance. The key for admins is to find a good balance between performance and system security.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.
This was first published in March 2008