A systematic Characterization of Application Sensitivity to Network Performance



Yüklə 0,74 Mb.
Pdf görüntüsü
səhifə32/51
tarix15.10.2018
ölçüsü0,74 Mb.
#74178
1   ...   28   29   30   31   32   33   34   35   ...   51

83
SCSI
RAID
Range(op/sec)
200-1050
500-1400
Q-model
Measured
Q-model
Measured
Slope
8.5
14.3
10.4
18.9
§
sec per op/s
Y-intercept
8.0
4.52
-6.8
-0.04
Base
8.6
7.3
4.3
4.5
¨%©
0.93
0.99
0.98
0.96
Table 5.1: SPECsfs Linear Regression Models & Accuracy
This table demonstrates linear regressions of the SFS queuing-theoretic models and measured data.
The table shows the slope of the SFS curve, (increase in response time vs load), the Y-intercept, the
base performance at 200 and 500 ops/sec, and the coefficient of determination (
¨
©
).
5.3.2
Model Accuracy
Figure 5.3 shows the accuracy of our simple queuing model compared to the measured data
for our baseline systems. The baseline systems have the minimum
ª
,
«
, and
¬
, and thus maximum
performance in all dimensions. In order to measure the slope of the SFS curves, we performed a lin-
ear regression on a range of measured data (200-1050 for the SCSI and 500-1400 for the RAID). Ta-
ble 5.1 shows that within these ranges a linear model is quite accurate; the
¨%©
values are 0.99 (SCSI)
and 0.96 (RAID).
At a qualitative level, we can see that the NFS cache sizes have a significant impact on the
shapes of both the measured and modeled systems. Below 500 ops/sec for the RAID, the SFS curve
is fairly flat because the cache is absorbing most of the requests. The SCSI system, with its small
cache, has a continuously rising curve. The slope of the RAID is much steeper than the SCSI system
for exactly the same reason—differences in cache size.
At a more quantitative level, across the entire range of throughputs the relative error of
the queuing model is at worst 24% for the SCSI and 30% for the RAID. This is reasonably accu-
rate considering the simplicity of the model, e.g., we do not model writes by-passing the file cache.
Unfortunately, the queuing model consistently under predicts the slopes of the SFS curve. Linear re-
gressions of the queuing model predict slopes of 8.5 (SCSI) and 10.4 (RAID)
§
s per op/sec. These
are substantially lower than the 14.3 and 18.9
§
s per op/sec for the measured slopes.
The shape of the inflection point is a second inaccuracy of the model. In the SCSI system,
the measured inflection point is quite muted compared to the modeled curve. The last point of the
modeled SCSI curve, which has no measured counterpart, shows a rapid rise in response time in the


84
base
modeled
slope
measured
180
380
580
780
980
1180
NFS Ops/sec
0
5
10
15
20
25
30
35
40
Response 
Time 
(msec)
SCSI
Modeled vs Measured
slope
measured
base
modeled
280
480
680
880
1080
1280
1480
1680
NFS Ops/Sec
0
5
10
15
20
25
30
35
40
Response 
Time
(msec)
RAID
Modeled vs Measured
Figure 5.3: SPECsfs Modeled vs. Measured Baseline Performance
This figure plots the modeled as well as baseline SFS curves for the SCSI system (top) as well as for
the RAID based system (bottom).
99+% utilization regime. The real system, however, will not enter into that regime. We explore the
effects of high utilization in Section 5.5.3.
In spite of the inaccurate slopes and inflection point, the queuing model is quite accurate for
most of the operating regime. Only at very high utilization does it deviate much from the measured
values. Interestingly, the
­%®
values in Table 5.1 show that the live system behaves in a linear fashion
across almost all of the operating regime, more so than the model would predict.
For the purposes of capacity planning, the queuing model may be quite acceptable because
operating at the extremes of the performance ranges is undesirable. A lightly loaded system wastes
resources, while a system operating near capacity results in unacceptable response times.


85
5.3.3
Expected Sensitivity
The model provides a concise conceptual framework; we use it to predict the impact of
changing each LogGP parameter. The delay center captures the network latency term. We thus
model an increase in
¯
as a linear increase in
°
, thereby changing the base response time. Each
±
s of added
¯
should add 2
±
s to the base response time, because each operation is a synchronous
request-response pair. An increase in
¯
should have no effect on the slope or saturation point. In
the next section, we see that our model predictions for the slope and saturation point are accurate
for a wide range of
¯
values, but not for extreme ranges. We also see that the model consistently
under-predicts the sensitivity of the base response time to
¯
.
Increasing
²
we expect changes to all three components of the SFS signature. The response
time should increase because of the client overhead encapsulated in the
°
parameter and increased
service time on the CPU. The slope should increase due to queuing delays at the CPU. The most im-
portant effect of
²
is that the saturation point may be reached sooner. Because of the increased service
time on the CPU, it will reach maximum utilization sooner. If, however, some other component of
the system were the bottleneck, we may observe a region where the saturation point is insensitive
to
²
. For our two servers, the model predicts that the CPU will be the bottleneck. We model the
relationship between the saturation point and overhead as:
³”´tµ·¶$¸%´§µº¹
²%»¼
½
³”¾¸%¿ÁÀáÄÆÅ
²
where
³£¾¸%¿
is the average CPU service time per operation previous measured in Sec-
tion 5.3.1. The coefficient of 2.4 is the average number of messages per NFS operation. We model
2 messages per operation: a request and a reply. However, as
²
is incurred on every message, we
also model 2 extra fragments per read or write due to MTU effects. Given the frequency and size of
reads and writes, the MTU effects raise the constant to 2.4. The next Section will show our model
of sensitivity to
²
to be quite accurate.
The bandwidth,
Ç
È
, is not captured well by any single parameter of the model. If we assume
that requests are uniformly distributed in time,
É
will have no effect until
Ê
ÇÌË
Ç
È
. Indeed, this is
a good test to see if requests are bursty or not. If requests are bursty then we expect that the NFS
system would be quite sensitive to changes in
É
.


Yüklə 0,74 Mb.

Dostları ilə paylaş:
1   ...   28   29   30   31   32   33   34   35   ...   51




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə