Download Why performance modeling

Section 02. Basic engineering of performance.
http://msdn.microsoft.com/en-us/library/ms998512.aspx
Whatever we design, build or provide as a service must be
able to perform. We must be able to
■ measure and manage performance
■ predict and anticipate quality of performance
■ as an application architect
● balance performance with scale
● balance performance with
♦ manageability, security, maintainability
■ as a service provider
● inject more performance if need be
● negotiate performance as a commodity
Performance Management
Issue is risk management. How much risk can you take?
Performance
risk
Performance vs QoS
Qos (Maintainability, scalability, security, availability)
needs to be balanced with performance requirement.
Also balance needs to be achieved among Qos components:
Maintainability
Scale
Performance
Security
Availability
Some paradox: For very large systems like Internet
relations among components may not follow the usual
rules.
Performance consideration
Reactive
Proactive
Reactive: After the design, after the fact. Doesn’t usually
work well and it may be expensive to fix.
Proactive: Think about performance while designing, while
specifying architecture. Focus optimization. Focus on
reducing needs to tuning and redesign.
Elements of Performance Engineering.
Performance metrics and objectives: What do you want to
measure? What should they be? High, low? Optimization
issues.
Performance objectives:
■ Response time: Minimize
t0
System
t0  R
Minimize R
Componenti
Component j
Ri
Rj
Minimize R  Ri  R j (Total Response time)
■ Throughput (Goodput): Maximize
X
System
Maximize X
■ Resource Utilization: Maximize
Maximize U 
Busy _ time
Total _ time
System
Sk
Si
X
Sj
Ideally each Utilization component U i , U j , U k should be
large, but this is not possible to achieve since each
component is directly proportional to the system
throughput X
U k  XDk
Dk  Total service time received at Sk
■ Workload: Maximize
It’s the amount of energy output of a system (as by a car
measured in hp unit) over time. It’s the total number of
clients, transaction data volume, etc. supported by the
system.
A typical problem. Load Balancing. Maximize total work
load across a system with concurrent set of servers.
System over concurrent
servers
Sk
Si
X
Sj
Total workload W  Wk should be maximized by
k
appropriate load-sharing scheme.
System size and performance: Scalability issue. If a system
works at a performance level pn when the load is n , how
dp
does the function n behaves with increasing n? If it
dn
decreases, how badly does it decrease?
Useful key scalability considerations.
■ Coupling and cohesion: loose coupling but high
cohesion (distributed systems vis-à-vis multiprocessors)
■ Communication: Transport mechanism & protocols
(TDP/UDP), round-trip, congestion, buffer-overflow
■ Concurrency: transactions (batch, interactive), locks,
threads, queuing, deadlock
■ Resource Management: Allocation, creation, destruction,
pooling
■ Caching: per user, per application, data relevancy
■ State Management: per user, per application, persistency,
location
Metrics and cost
■ Actual measurements obtained from running
performance tests. Performance tests include system-related
metrics like CPU, memory, disk I/O, network I/O and
resource utilization levels. Performance metrics include
application-performance counters and timing data.
■ What are the key components? What do they do? What
are your contingent plans in case something goes wrong?
■ What are the cost of services under a given workload?