Bài giảng Kiến trúc phần mềm - Chương: Các tiêu chí và yêu cầu về Kiến trúc phần mềm - Trần Minh Triết
Trường Đại học Khoa Học Tự Nhiên
Khoa Công Nghệ Thông Tin
Bộ môn Công Nghệ Phần Mềm
CTT526 - Kiến trúc phần mềm
Các tiêu chí và yêu cầu
về Kiến trúc phần mềm
PGS.TS. Trần Minh Triết
Version 1.0
Nội dung của bài giảng sử dụng:
Session 3: Quality Attributes
trong bộ slide Software Architecture Essential
của GS. Ian Gorton
Software Engineering Institute
Carnegie Mellon University
2
What are Quality Attributes
Often know as –ilities
Reliability
Availability
Portability
Scalability
Performance (!)
Part of a system‟s NFRs
“how” the system achieves its functional
requirements
3
Quality Attribute Specification
Architects are often told:
“My application must be fast/secure/scale”
Far too imprecise to be any use at all
Quality attributes (QAs) must be made
precise/measurable for a given system design, e.g.
“It must be possible to scale the deployment from an
initial 100 geographically dispersed user desktops to
10,000 without an increase in effort/cost for
installation and configuration.”
4
Quality Attribute Specification
QA‟s must be concrete
But what about testable?
Test scalability by installing system on 10K
desktops?
Often careful analysis of a proposed solution is all that
is possible
“It‟s all talk until the code runs”
5
Performance
Many examples of poor performance in enterprise
applications
Performance requires a:
Metric of amount of work performed in unit time
Deadline that must be met
Enterprise applications often have strict performance
requirements, e.g.
1000 transactions per second
3 second average latency for a request
6
Performance - Throughput
Measure of the amount of work an application must
perform in unit time
Transactions per second
Messages per minute
Is required throughput:
Average?
Peak?
Many system have low average but high peak
throughput requirements
7
Throughput Example
CPU %
MS T ( ms p )
3 0 0
2 5 0
2 0 0
1 5 0
1 0 0
5 0
0
0
5
1 0
# o f th r e a d s
1 5
2 0
Throughput of a message queuing system
Messages per second (msp)
Maximum
Note throughput changes as number of receiving
threads increases
8
Performance - Response Time
measure of the latency an application exhibits in
processing a request
Usually measured in (milli)seconds
Often an important metric for users
Is required response time:
Guaranteed?
Average?
E.g. 95% of responses in sub-4 seconds, and all within
10 seconds
9
Response Time
Example shows response time distribution for a
J2EE application
10
Performance - Deadlines
„something must be completed before some specified
time‟
Payroll system must complete by 2am so that
electronic transfers can be sent to bank
Weekly accounting run must complete by 6am
Monday so that figures are available to management
Deadlines often associated with batch jobs in IT
systems.
11
Something to watch for …
What is a
Transaction?
Message?
Request?
All are application specific measures.
System must achieve 100 mps throughput
BAD!!
System must achieve 100 mps peak throughput for
PaymentReceived messages
GOOD!!!
12
ICDE Performance Issues
Response time:
Overheads of trapping user events must be imperceptible
to ICDE users
Solution for ICDE client:
Decouple user event capture from storage using a queue
5. Write event
to ICDE database queue
2. Write event
1. Trap user event
to queue
4. Read event
3. Return to user thread
from queue
13
Scalability
“How well a solution to some problem will work when
the size of the problem increases.”
4 common scalability issues in IT systems:
Request load
Connections
Data size
Deployments
14
Scalability – Request Load
How does an 100 tps application behave when
simultaneous request load grows? E.g.
From 100 to 1000 requests per second?
Ideal solution, without additional hardware capacity:
as the load increases, throughput remains constant
(i.e. 100 tps), and response time per request
increases only linearly (i.e. 10 seconds).
15
Scalability – Add more hardware
…
Scale-up:
Single application instance is
executed on a multiprocessor
machine
Application
Scale-out: Application replicated on
different machines
Application
CPU
Application
Applicati
Application
16
Scalability - reality
Adding more hard ware should improve
performance:
scalability must be achieved without modifications to
application architecture
Reality as always is different!
Applications will exhibit a decrease in throughput
and a subsequent exponential increase in response
time.
increased load causes increased contention for resources
such as CPU, network and memory
each request consumes some additional resource (buffer
space, locks, and so on) in the application, and eventually
these are exhausted
17
Scalability – J2EE example
2 5 0 0
2 0 0 0
1 5 0 0
1 0 0 0
5 0 0
W A S S B
JB o s s S B
IA S S B
S S S B
W L S S B
B E S S B
0
0
2 0 0
4 0 0
6 0 0
8 0 0
1 0 0 0
1 2 0 0
N o . o f C lie n ts
I.Gorton, A Liu, Performance Evaluation of Alternative Component
Architectures for Enterprise JavaBean Applications, in IEEE Internet
Computing, vol.7, no. 3, pages 18-23, 2003.
18
Scalability - connections
What happens if number of simultaneous connections
to an application increases
If each connection consumes a resource?
Exceed maximum number of connections?
ISP example:
Each user connection spawned a new process
Virtual memory on each server exceeded at 2000
users
Needed to support 100Ks of users
Tech crash ….
19
Scalability – Data Size
How does an application behave as the data it
processes increases in size?
Chat application sees average message size
double?
Database table size grows from 1 million to 20
million rows?
Image analysis algorithm processes images of
100MB instead of 1MB?
Can application/algorithms scale to handle increased
data requirements?
20
Tải về để xem bản đầy đủ
41 trang
11800
Free
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Kiến trúc phần mềm - Chương: Các tiêu chí và yêu cầu về Kiến trúc phần mềm - Trần Minh Triết", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- bai_giang_kien_truc_phan_mem_chuong_cac_tieu_chi_va_yeu_cau.pdf
