Amit Chandel

1
CSC407 Software ArchitectureFall
2006Performance (III)

• Amit Chandel Greg Wilson
• amit_at_cs.toronto.edu
• gvwilson_at_cs.utoronto.ca

2
Model Revisited
3
Generalized Birth-Death Models

• A restricted class of Markov models

?1
?0
?2
?3
0
1
2
3

?1
?0
?2
?3
flow in flow out
?1P1 ?0P0
?0P0 ?2P2 ?1P1 ?1P1

P0 P1 1
4
After a Little Algebra
? i-1 -1
P0 ? ? ?i/?i1 ?i/?i1
k0 i0

i-1
Pk ? ?i/?i1 ?i/?i1 P0
i0
utilization P1 P2 1 P0
throughput ?1P1 ?2P2 ? ?kPk
queue length 0P0 1P1 2P2 ? kPk
response time queue length / throughput ? kPk / ? ?kPk
5
M/M/1 System Steady State
6
M/M/1 System Steady State
Let us solve
7
M/M/1 System Steady State
8
M/M/1 System Performance Measures

• Utilization U 1 p0 ?
• Conventional to use ? for utilization instead of
  U
• Number of customers in whole system

9
M/M/1 System Performance Measures

• Mean Response Time
• Littles Law ENs ? ETs

10
M/M/1 System Performance Measures

• Mean Wait Time in queue (Tw TQ)
• Number of jobs waiting in queue Nw
• Using Littles Law ENw ? ETw
• 
  ?2 / (1 - ?)

11
Example 1

• File server 30 requests/sec, 15 msec/request
• What is the average response time?
• What would it be if the arrival rate doubled?
• Assume requests are independent (must verify)
• Utilization ? ?ES 0.45
• So average response time is ES/(1 - ?) 0.027
  sec
• At 60 requests/sec, response time is 0.15 sec
• Doubling request rate increased response time by
  5.6!

12
Example 2

• If both the arrival rate and the service rate are
  doubled, how does the utilization, throughput,
  mean response time, and average number of jobs in
  the system change?
• Utilization (U)?
• Throughput (X)?
• Mean Response Time (ETs) ?
• Average number of jobs in the system (ENs) ?

13
Mean Value Analysis

• Markov models suffer from state explosion
• In practice, easier to calculate loads using an
  induction technique called Mean Value Analysis
• If you response times and throughputs for a
  population of N customers, its easy to calculate
  the values for N1 customers
• Iterate until either
• All customers are accounted for
• Throughputs and response times converge

14
Mean Value Analysis
Initialize ave. number of customers at device i
ñi(0) 0 For n 1, 2, 3, , calculate
Average residence time for device Ri(n)
ViSi1 ñi(n-1) Di1ni(n-1) Overall system
response time R0(n) SViRi(n) Overall
system throughput X0(n) n / R0(n)
Throughput for each device Xi(n) ViX0(n)
Utilization for each device Ui(n) SiXi(n)
Average number of customers at each device
ñi(n) X0(n)Ri(n)
15
Example
fast disk
CPU
slow disk
16
Example

• At most 2 users at any time
• Because of high demand, there are always 2 users
• Each transaction alternates between CPU and disk
• Typical transaction requires a total of 10 sec of
  CPU
• Fast disk is twice as fast as the slow one
• Transactions spread evenly across disks
• Fast disk takes average of 15 seconds to access
  files
• Slow disk takes average of 30 seconds to access
  files
• What happens if we allow 3 concurrent users?

17
Example
ñcpu(0) 0.0 customers
ñfd(0) 0.0 customers
ñsd(0) 0.0 customers
Rcpu(1) 10 1 (1 0.0) 10.00 sec
Rfd(1) 15 0.5 (1 0.0) 7.50 sec
Rsd(1) 30 0.5 (1 0.0) 15.00 sec
R0(1) 10.00 7.50 15.00 32.50 sec
X0(1) 1/32.50 0.0308 customers/sec
Xcpu(1) 1.0 0.0308 0.0308 customers/sec
Xfd(1) 0.5 0.0308 0.0154 customers/sec
Xsd(1) 0.5 0.0308 0.0154 customers/sec
18
Example
Ucpu(1) 10.00 0.0308 0.3077 (30.77)
Ufd(1) 15.00 0.0154 0.2308 (23.08)
Usd(1) 30.00 0.0154 0.4615 (46.15)
ñcpu(1) 0.0308 10.00 0.3077 customers
ñfd(1) 0.0308 7.50 0.2310 customers
ñsd(1) 0.0308 15.00 0.4620 customers

ñcpu(3) 0.8462 customers
ñfd(3) 0.5653 customers
ñsd(3) 1.5885 customers

• Its a little tedious, but thats what computers
  are for

19
Conclusion

• Measure, then model, then tune
• To tune the micro-level
• Choose the right algorithm
• Squeeze it 'til it squeaks
• To tune the macro-level
• Eliminate latency, contention, and copying
• Micro-tuning will not fix macro problems
• But fixing macro problems can make micro problems
  go away

20
When Do You Stop?

• An optimization problem on its own
• Time invested vs. likely performance improvements
• Plan A stop when you satisfy SLAs
• Or beat themalways nice to have some slack
• Plan B stop when there are no obvious targets
• Flat performance profiles are hard to improve
• Plan C stop when you run out of time
• Plan D stop when performance is "good enough"