|
NFS Clients: How We Tested
Nine NFS (Network File System) clients were installed on identical Micron Pentium 166 machines running Microsoft Corp. Windows NT 4.0 with Service Pack 3. Performance testing involved running four instances of our test application, simultaneously reading and writing various file sizes for 30 minutes, against a Sun Microsystems Solaris 2.5.1 server. Files sizes of 1, 10, 100 and 1,024 KB were tested. During testing, each client spent 80 percent of its time reading existing files, 7 percent of the time creating files and 13 percent of its time overwriting existing files. For each testing period, the client and the NFS server were isolated from the rest of the network on their own 10-Mbps Eth
ernet segment.
Unfortunately, during our testing numerous clients crashed or blue-screened. WRQ Reflection and Network Computing Devices Marathon both had problems with the performance testing when their adaptive network settings were enabled. Adaptive network settings allow the client to "tune" client read and write sizes with the server during intense file operations. After determining that adaptive network settings were at fault, all clients with these settings were tested without the option enabled. Esker Tun NFS and Century TERM Professional experienced more severe problems and never completed our testing.
NFS Servers: How We Tested
To test these NFS servers, we connected our Micron Pentium Pro 200 machines, running Microsoft Corp. Windows NT Server 4.0 with Service Pack 3, to the 100-Mbps network at our University of Wisconsin
lab in Madison. Hewle
tt-Packard Co. Unix workstations, connected via 10-Mbps switched ports, were used as clients. A Sun Microsystems SPARC 20 system running Solaris 2.5.1 was also tested as a reference.
To approximate a busy NFS-based setup, we used 25 client machines broken up into five groups. Our test assigned each group a file size of 1, 10, 50 or 500 KB. During our 30-minute tests, each client spent 80 percent of its time reading existing files, 7 percent of its time creating files and 13 percent of its time overwriting existing files. In addition, directory attribute checking also was tested, mimicking normal applications. After completing the test, the outcomes for each of the client groups were averaged from the total score of each client.
To Cache Or Not To Cache
A s Intergraph Software Solutions' DiskShare showed us, file caching is a very important issue to be aware
of when thinking about the implementation of an NFS (Network File System) client and server pool. With some thought, these troubled waters can be navigated and a level of security from data loss can be balanced with speed. With DiskShare, we learned that a large gain in performance can be realized when you enable write caching. However, this gain can be offset by data loss if a machine is suddenly turned off or crashes.
We used NFS version 2 in our performance testing, since the majority of NFS installations still use this version. According to RFC 1094, NFS version 2 servers are not supposed to return from a write command until the file has been stored on stable storage. This stable storage is most commonly a hard drive, but it can also include methods, such as cache backed up by a battery, where even if the machine crashes, the data will be secure.
NFS version 3 has an unstable write when the server is permitted to cache its data. Due to the vastly improved quality of computers and networks since t
he NFS version 2 stand
ard was written, allowing file caching can be very advantageous. However, if your clients are expecting that their data is safe and available to others when they complete their write, not having this can be hazardous to your application's health.
|
RSS
