SPEC System File Server (SFS) 2.0 measures NFS file server throughput and response time. It is a one test benchmark suite consisting of 097.LADDIS. It contains an updated workload that was developed based on a survey of more than 1,000 NFS servers in different application environments. The workload is larger and the response-time threshold is lower than those used in SFS 1.1, due to advances in server technologies. Because of these and other changes, you cannot compare SPEC SFS 2.0 results to SFS 1.1 or SFS 1 results.
In addition to general code improvemenets, SPEC SFS 2.0 includes these enhancements
Measures results for both NFS Version 2 and 3
Adds support for TCP (either TCP or UDP can be used as the network transport)
Operation mix more closely matches real-world NFS workloads
Improved interface to accomodate both accomplished and novice users
Two reference points are considered when reporting 097.LADDIS:
NFS operation throughput--The peak number of NFS operations the target server can complete in a given number of milliseconds. The larger the number of operations an NFS server can support, the more users it can serve.
Response time--The average time needed for an NFS client to receive a reply from a target server in response to an NFS request. The response time of an NFS server is the client's perception of how fast the server is.
LADDIS is designed so that its workload can be incrementally increased until the target server performance falls below a certain level. That point is defined as an average response time exceeding 50ms. This restriction is applied when deriving the maximum throughput in NFS operations per second for which the response time does not exceed 50 ms.
If throughput continues to increase with the workload, the throughput figure at 50 ms is reported. In many cases, throughput will start to fall off at a response time below the 50 ms limit. In these cases, the tables in this chapter report the response time at the point of maximum throughput.
The SPEC SFS 2.0 (0.97 LADDIS)benchmark is a synthetic NFS workload based on an application abstraction, an NFS operation mix, and an NFS operation request rate. The workload generated by the benchmark emulates an intensive software development environment at the NFS protocol level. The LADDIS benchmark makes direct RPC calls to the server, eliminating any variation in NFS client implementation. This makes it easier to control the operation mix and workload, especially for comparing results between vendors. However, this also hides the benefits of special client implementations, such as the cache file system client.
Table A-7 shows the NFS operations mix. These percentages indicate the relative number of calls made to each operation.
Table A-7 NFS Operations Mix by Call
NFS Operation |
Percent Mix |
---|---|
Lookup |
34 |
Read |
22 |
Write |
15 |
GetAttr |
13 |
ReadLink |
8 |
ReadDir |
3 |
Create |
2 |
Remove |
1 |
Statfs |
1 |
SetAttr |
1 |
The LADDIS benchmark for NFS file systems uses an operation mix that is 15 percent write operations. If your NFS clients generate only one to two percent write operations, LADDIS underestimates your performance. The greater the similarity between the operation mixes, the more reliable the maximum throughput in NFS operations is as a reference.
Running the benchmark requires the server being benchmarked to have at least two NFS clients (the NFS load generators), and one or more isolated networks. The ability to support multiple networks is important because a single network may become saturated before the server maximum performance point is reached. One client is designated as the LADDIS Prime Load Generator. The Prime Load Generator controls the execution of the LADDIS load generating code on all load-generating clients. It typically controls the benchmark. In this capacity, it is responsible for collecting throughput and response time data at each of the workload points and for generating results.
To improve response time, configure your NFS server with the NVRAM-NVSIMM Prestoserve NFS accelerator. NVSIMMs provide storage directly in the high-speed memory subsystem. Using NVSIMMs results in considerably lower latency and reduces the number of disks required to attain a given level of performance.
Since there are extra data copies in and out of the NVSIMM, the ultimate peak throughput is reduced. Because NFS loads rarely sustain peak throughput, the better response time using the NVSIMMs is preferable. For information on the Prestoserve NFS accelerator, see "Prestoserve NFS Accelerator" in Chapter 4, Configuring the Server and the Client to Maximize NFS Performance.
Sun Microsystems has run SPEC SFS 2.0 benchmarks on the Sun Enterprise 3000-6000 family of servers. The benchmarks were run with NFS Version 2 and NFS Version 3. Table A-8 shows the results with Version 2. Table A-9 shows the results with Version 3.
Table A-8 SPEC SFS 2.0 Results With Version 2
System |
Number of CPUs |
Result |
Overall Response Time |
---|---|---|---|
Sun Enterprise 3000 |
6 |
11806 |
5.1 |
Sun Enterprise 4000 |
12 |
20406 |
6.7 |
Sun Enterprise 6000 |
18 |
25639 |
9.9 |
Table A-9 SPEC SFS 2.0 Results With Version 3
System |
Number of CPUs |
Result |
Overall Response Time |
---|---|---|---|
Sun Enterprise 3000 |
6 |
5903 |
5.4 |
Sun Enterprise 4000 |
12 |
10592 |
5.6 |