A systematic Characterization of Application Sensitivity to Network Performance

86
5.4
Previous Work on NFS Performance
Due to its ubiquity as a distributed filesystem there is vast body of work on NFS. Fortu-
nately, [82] contains an excellent bibliography and summary. This section does not try to document
all previous NFS work; rather we categorize related work and introduce papers which describe pre-
vious results upon which our work builds.
NFS studies fall into roughly three categories: protocol changes, client/server enhance-
ments, and performance evaluation. Although papers contain some element of all three, often they
focus in a single area. Many NFS protocol studies explore changes to improve filesystem seman-
tics [68, 71, 77, 83], however, a few are performance oriented [38]. Enhancement studies focus on
client/server design changes rather than protocol changes [37, 100]. For example, [59] looks at write
gathering to improve performance, and a comparison of TCP vs. UDP and copy reduction techniques
are examined in [70].
Our work clearly falls into the performance analysis category, using network performance
as the dependent variable. The work in [96] takes an interesting perspective compared with ours.
Instead of examining NFS performance as a function of the network, it examines network perfor-
mance as a function of NFS load. It found that modest NFS load can severely degrade Ethernet per-
formance. With the advent of multi-gigabit switched LANs, network loading due to NFS traffic is a
minor problem compared with the days of shared 10 Mb Ethernet.
Although it deals with differences between NFS version 2 and version 3 [82], performs
much performance analysis to justify the changes. It found that a server running NFS version 3 is
roughly comparable to the same server running version 2 with NVRAM. However, little exploration
of the impact of the version 3 protocol changes is made with relation to network performance.
An extensive bottleneck analysis is presented in [108]. The book examines the peak thr-
oughputs of real-world components (e.g. CPU, disks, network) and characterizes where the satura-
tion point will be for different configurations. An interesting result of the work is that most servers
in the SPEC results are over-provisioned with disks.
Section 2.6.2 showed that perhaps the closest study in spirit to the experiments in this chap-
ter is [21]. That work was primarily concerned with NFS performance over congested ATM net-
works. They found that a high
Í
, in the 10’s of milliseconds, was quite detrimental. A trace-fed
simulation was used rather than a live system. Moreover, their custom workloads make a quantita-
tive comparison to our work difficult.
We examined the methodology of [49] in Section 2.6.4. Recall that their conclusions are

---

87
0
10
20
30
40
50
0
200
400
600
800
1000
Response Time (msec)
Î
NFS Ops/Sec
SCSI
L(usec)
10
50
100
500
1000
2000
4000
0
10
20
30
40
50
0
200
400
600
800
1000
1200
1400
1600
Response Time (msec)
Î
NFS Ops/sec
RAID
L(usec)
10
15
50
100
150
1000
4000
(a)
(b)
Figure 5.4: SPECsfs Sensitivity to Latency
This figure plots the SFS curves as a function of latency in microseconds. Measurements for the
graph on the left were taken on the SCSI system, while measurements for the graph on the right were
taken on the RAID system.
quite similar to ours: CPU overhead is a dominant factor in NFS performance. We compare their
results to ours in greater detail in Section 5.6. Some of their most interesting data, however, came
from their direct measurement of a large production system.
5.5
Sensitivity Results
Given our methodology and NFS characterization, we now quantify the effect of vary-
ing LogGP parameters. As in previous chapters, we independently vary each of the parameters in
turn and observe the resulting SFS curves. For each parameter, we attempt to explain any observed
changes to the SFS signatures based on the model developed in Section 5.3. In addition, we measure
the most appropriate sensitivity for each parameter. For latency this is change in base response time
as a function of
Ï
. For overhead, it is the change in saturation point as a function of
Ð
.
5.5.1
Latency
Historically end-to-end latency is often thought of as the critical parameter for NFS perfor-
mance [21, 80]. In terms of the LogGP model, the typical definition of latency includes both
Ï
and

---

88
Ñ
. In this section, we examine solely the
Ò
term. By focusing on latency alone, we can better quantify
the effects of the network itself, rather than mixing the effects of the network and end-system.
Response to Latency
Figure 5.4(a) shows a range of SFS curves resulting from increasing
Ò
for the SCSI system.
Likewise, Figure 5.4(b) shows the results for the RAID. The range of
Ò
has been scaled up from a
baseline of 10
Ó
s to 4 msec. For comparison, most LAN switches have latencies in the 10’s of
Ó
s.
Most IP routers, which would be used to form a campus-wide network, have latencies of about a
millisecond. Thus the range explored in Figure 5.4 is most likely what one might find in an actual
NFS network. We will explore the effect of very high WAN-class latencies in Section 5.5.2.
We have truncated the SCSI curves at the saturation point, to increase readability, but present
the full RAID data. Figure 5.4(b) shows the 4 msec RAID curve “doubling back”. Because the SFS
benchmark reports the response time vs. delivered throughput, as opposed to offered load, attempts
to exceed the saturation point can result in fewer operations per second than attempted. We will ex-
plore this effect in greater detail in the discussion of overhead.
As predicted by the queuing model, the measured data shows the primary effect of in-
creased
Ò
is to raise the base response time. Also, as predicted by the model, the slope does not
change. Modest changes in
Ò
do not affect the saturation point. However, a high
Ò
can cause the
saturation point to fall, as shown by both the 4 msec curves. The reason for the drop is that insuffi-
cient parallelism exists due to lack of client processes. We have tested this hypothesis by increasing
the number of load generator processes on the client. An unusual side effect of increasing the num-
ber of load generators is a change in the slope of the SFS curve. We therefore use the minimum
number of load generators that can saturate the system in the baseline case even if it results in lower
saturation points as we scale
Ò
.
Returning to the base response time, a key question is what the rate of the increase to
Ò
is. That is, for each
Ó
s of
Ò
added, what is the corresponding increase in response time? The next
section explores this question in greater detail.
Sensitivity to Latency
Figure 5.5 shows the sensitivity of response time as a function of
Ò
for a range of through-
puts, i.e., each line is a vertical slice though Figure 5.4. Two distinct sensitivity regions are observ-
able. Figure 5.5(a) shows the first region has a constant sensitivity of 3
Ó
s of response time for each

---