A systematic Characterization of Application Sensitivity to Network Performance

80
resents the best average response time obtainable from the system. The base will be determined by
a host of factors, including the network, the speed of the CPU, the size of the file cache, the amount
of Non-Volatile RAM (NVRAM), and the speed of the disks.
As load on the server increases, there will be a region where there is a linear relationship
between throughput and response time. The slope signifies how well the server responds to increas-
ing load; a low slope implies the clients cannot perceive a more loaded server, while a high slope
implies noticeable delays as we add load. The slope will be affected by queuing effects in the net-
work, at the server CPU, the server disks and the client CPU. However, a much more important role
in the determination of the slope is the changing miss rate in the server file cache.
As the load further increases, a bottleneck in the system will limit the maximum through-
put at the saturation point. The nature of the bottleneck will determine if the point is reached sud-
denly, resulting in a pronounced inflection, or gradually. Example bottlenecks include an insufficient
number of clients, lack of network bandwidth, the speed and number of CPUs on the server, and an
insufficient number of server disks.
SPECsfs is designed to isolate server performance. The benchmark therefore takes care to
avoid client interactions to the extent they influence the accuracy of the load placed on the server. For
example, differences in client file cache management make it difficult for the benchmark to control
both the size and nature of the server load. The load generators thus call RPC procedures directly,
bypassing the client filesystem and file cache. The results of this study therefore are primarily from
the server perspective. Average response time results on production systems will depend on the type
of workload (e.g. attribute vs. bandwidth intensive) and size of the client caches. See [44] for an
examination of the effects of client caches on server load.
Using SPECsfs as a workload is quite novel in an academic setting. One factor limiting
previous work was the scale on which the benchmark must be run in order to obtain meaningful
results. For example, an insufficient number of disks would limit our understanding of CPU bottle-
necks. Also, industry reported results are for very large systems, often beyond the range of a dedi-
cated academic testbed. For example, at the completion of this study, one of our testbeds immediately
went into production use.
From our “grey-box” perspective, SPECsfs is quite useful because it fixes all the NFS para-
metric inputs but one: the server load. We can thus restrict the parameter space primarily to the net-
work. At the same time, our choice of SPECsfs clearly limits our understanding of NFS in several
ways; it is attribute intensive and it does not model the client well. Practically, however, our choice
allows us to interpret industrial data published on SPEC’s website in the framework presented in this

---

81
CPU
λ
1
λ
1
Disk
Disk
Disk
λ
3
hit
miss
NFS
Cache
P
P
M/M/1
λ
2
Exit
M/M/m
Response Time
Delay
Fixed 
D
Figure 5.2: SPECsfs Analytic Model
This figure shows the simple analytic model used to validate the NFS results. The model assumes a
poisson arrival rate of
ƒ…„
requests per second. The model then uses a fixed delay center to model
the network, an M/M/1 queue to model to CPU, a splitter to captures NFS cache effects, and finally
an M/M/m queue to model the disk subsystem. The parameters for each component were determined
by empirical measurement.
paper. We perform a brief analysis of industrial data in Section 5.6.
5.3
SPECsfs Analytic Model
In this section we build a simple analytic model of the entire NFS system, focused on the
server portion of the system. The goal of the model is to provide a framework for understanding the
effects of changes in
†
,
‡
and
ˆ
on the SFS results curve. We then compare the predictions of the
model against two measured SFS curves. If the model and experimental data agree, we can have
reasonable confidence in both. Significant differences between the two would show where either
the model fails to describe the system, or where the system is mis-configured and thus not operat-
ing “correctly”. In either case, more investigation may be needed to resolve the discrepancy. We
conclude the section with predictions on the sensitivity of the system to network parameters.
5.3.1
Model Construction
Figure 5.2 shows the queuing network we use to model an NFS server, adopting the simple
techniques described in [57, 65]. The model consists of a CPU, disks, NFS cache, and a delay center.
Our model ignores queuing delays in the controllers and I/O bus; they can easily support the load
placed on them given the small nature of most requests.
We assume that the arrival rate follows a Poisson process with a rate of
ƒ‰„
requests per

---

82
second. Because the departure rate must equal the arrival rate, the departure rate is also
Š…‹
.
The CPU is the simplest component of the system. We model it as an M/M/1 queue. We
derived the average service time, including all sub-systems (e.g. TCP/IP protocol stacks, and the
local filesystem, UFS) from experimental measurement. For the SCSI based system, the measured
average service time was 900
Œ
s per operation. The RAID system has a lower average service time
of 650
Œ
s. We provide a detailed investigation the components of the service time in Section 5.5.3.
Most NFS operations have the potential to be satisfied by an in-memory cache. Only 7% of
the SFS 2.0 mix are writes and these must bypass the cache—NFS version 2 semantics require that
they exist in stable storage before the write completes. The 64 MB of NVRAM in the RAID can
cache writes, however. The file cache size, and corresponding miss rate, are critical to determining
the base response time as well as the slope of the SFS curve. However, the SFS strategy of increasing
the data set size per op/sec places an upper limit on the effectiveness of a cache.
We model the NFS caches (both in-memory and NVRAM) as a splitter. The probability of
a hit is given as
Ž2’‘
and of a miss as
F“”–•0•˜—š™˜›œŽ2’‘
. On a hit, the request is satisfied and leaves
the system. Because the data set accessed by SFS increases with the load,
Ž2ž‘
is a function of
Š
‹
.
We use a simple approach to computing

Ž2ž‘
. We take the main memory size plus the NVRAM size
and divide it by the accessed data set size. In terms of our model, the splitting a Poisson stream
results in two Poisson streams,
Š$Ÿ
and
Š¡ 
. The rate of requests going to the disks is easily derived
as
Š
 
—¢7“£–•¤•¥Š
‹
The disks are modeled by an M/M/m queue where m is equal to the number of disks. We
have empirically observed using the
iostat
command an unloaded average service time of 12 ms
for the IBM drives. We use the same value to model the Seagate drives.
We fold the remaining components into a fixed delay center with a delay of
¦
. These
components include the overhead in the client operating system, fixed costs in the server, and the
network latency. The use of fixed delay greatly simplifies the model, allowing us to focus on the
important elements of the server. We can still obtain reasonable accuracy using a fixed delay center,
however. We empirically observed a
¦
of 3.4 msec. This fixed delay parameter was obtained by
observing a small request rate of 300 op/sec on the RAID system. At that rate, the entire workload
fits into memory, so nearly all disk requests have been eliminated.

---