Managing NFS and NIS, 2nd Edition - Mike Eisler [239]
The average percentage of all RPC calls of each type is the "NFS RPC mixture," and it defines the kind of work the server is being asked to do, as opposed to simply the volume of work presented to it. The RPC mixture indicates possible areas of improvement, or flags obvious bottlenecks. It is important to determine if your environment is data- or attribute-intensive, since this will likely dictate the network utilization and the type of tuning required on the client and server.
A data-intensive environment is one in which large file transfers dominate the NFS traffic. Transfers are considered large if the size of the files is over 100 MB. Examples of these environments include computer aided design and image processing. An attribute-intensive environment, on the other hand, is dominated by small file and meta-data access. The NFS clients mostly generate traffic to obtain directory contents, file attributes, and the data contents of small files. For example, in a software development environment, engineers edit relatively small source files, header files, and makefiles. The compilation and linkage process involves a large number of attribute checks that verify the modification time of the files to decide when new object files need to be rebuilt, resulting in multiple frequent small file reads and writes. Because of their nature, attribute-intensive environments will benefit greatly from aggressive caching of name-lookup information on the server, and a reduced network collision rate. On the other hand, a high-bandwidth network and a fast server with fast disks will most benefit data-intensive applications due to their dependence on data access. Studies have shown that most environments are attribute intensive. Once you have characterized your NFS workload, you will need to know how to measure server performance as seen by NFS clients.
* * *
[1] Add-on products such as the Solaris Bandwidth Manager allow you to specify the amount of network bandwidth on specified ports, allowing you to restrict the amount of network resources used by NFS. The Sun BluePrints Resource Management book published by Sun Microsystems Press provides good information on the Solaris Bandwidth Manager.
Measuring performance
The NFS RPC mixture is useful for tuning the server to handle the load placed on it, but the real measure of success is whether the clients see a faster server or not. Users may still get "server not responding" messages after some bottlenecks are eliminated because you haven't removed all of the constraints, or because something other than the server is causing performance problems.
Measuring the success of a tuning effort requires you to measure the average response time as seen by an average client. There are two schools of thought on how to determine this threshold for this value:
Use an absolute value for the "threshold of pain" in average server response time. The system begins to appear sluggish as response time approaches 40 milliseconds. As of this writing, typical NFS servers are capable of providing response times well below this threshold, in the range of one to ten milliseconds, and they keep getting faster.
Base the threshold on the performance of the server with a minimal load, such as only one client. When the server's performance exceeds twice this "ideal" response time, the server has become loaded.
It's easy to measure the average server response