성능 시험 방법론 발표 자료 LoadRunner™ Powered by
Download
Report
Transcript 성능 시험 방법론 발표 자료 LoadRunner™ Powered by
Powered by
LoadRunner™
성능 시험 방법론 발표 자료
목차
“Bringing Success to e-Business”
1.성능 시험의 개요
2.성능 평가 기준
3.성능 시험 진행 순서
- P1. 테스트 계획 수립
- P2. Workload Modeling
- P3. 테스트 스크립트 작성
- P4. 테스트 수행 및 결과 보고
성능 시험의 개요
“Bringing Success to e-Business”
시험목적
모 포털 사이트의 시스템 성능 측정
모 포털 사이트에서의 병목 구간 점검 및 튜닝
모 포털 사이트에서의 최대 수용 가능 동시단말사용자에 대한 검증
시험범위
단위 성능 시험은 예상되는 개별 업무 프로그램에 대한 최대 성능 및 문제점 발견 목적
통합 성능 시험은 예상되는 최대 수용 가능 동시단말사용자에 대한 성능 목표 검증 목적
Internet
Firewall
Web Server
App. Server
Database
성능 평가 기준
“Bringing Success to e-Business”
Scalability
다수의 사용자가 접속했을 때, Performance와
functionality를 모두 만족할 것인지?
계속 증가하는 사용자를 언제까지 대응할 수 있을까?
시스템 증설 시 가장 효과적인 투자 부분은?
Infrastructure
가상 사용자를 이용한 부하시험
사용자 증가 시 나타나는 1,2,3차 병목 추적
현재 Infrastructure는 최적화 되어있는지?
현재 Infrastructure내에 병목 구간은 없는지?
Infrastructure 병목의 개선을 통한 최적화
ISP와 같은 외부 서비스가 약속한 성능을 지키고 있는지?
실제 운영환경의 성능 검증/개선
Performance
Application 혹은 Infrastructure의 변경이 성능에 어떠한
영향을 줄 것인지?
사용자 증가 시 나타날 장애 유형과 대처 방안은?
실제 운영 환경에서 사이트의 성능은 어떨 것인지?
성능 시험 진행 순서
“Bringing Success to e-Business”
실제 사용자와 유사한 패턴의 부하 생성
P1.분석
P2. 설계
P3. 이행
P4. 평가
1. 요구 사항 분석
1. 단위 테스트
1. 종합 평가
2. 프로젝트 수행계획 수립
1. 성능 목표 수립
.
2. 이행 절차 계획 수립
2. 통합 테스트
2. 결과 보고
3. 현행 시스템 분석
3. 자원 감시 계획 수립
3. 튜닝
4. 스크립트 작성
변경사항 발생
성능 목표 만
족 여부
“Bringing Success to e-Business”
P1.분
석
P1. 분석
“Bringing Success to e-Business”
1. 요구 사항 분석
신규 사이트
시스템 설계 당시 산정된 동시사용자 수 및 성능(TPS,응답시간)을 만족하는가?
현 개발중인 시스템은 최적화가 제대로 되어 있는가?
기존 사이트
다수의 사용자(현재 대비 4배)가 접속 하였을 때 성능 상의 이슈 사항은 없는가?
계속 증가하는 사용자를 언제까지 대응할 수 있을까?
시스템 증설 시 가장 효과적인 투자 부분은 어디인가?
개편(통합) 사이트
개편 전 시스템의 성능을 제대로 수행해 내는가?
통합 전 시스템들의 사용자를 통합 이후 제대로 수용할 수 있는가?
P1. 분석
“Bringing Success to e-Business”
1. 요구 사항 분석 - 성능 테스트 범위
모든 부하 발생은 내부 망에서 행하는 것을 원칙으로 하며 ISP Router에서 1차 Firewall 구간은 부하 테스트 대상에서
제외합니다.
<WAS Server1>
<DB Server1>
<WAS Server2>
<DB Server2>
WAP G/W
<WEB Server1>
Internet
<WEB Server2>
L4 Switch
SMSS
Load Generator
( Load Runner Controller & Injector )
부하 TEST 구간
P1. 분석
“Bringing Success to e-Business”
1. 요구 사항 분석 – 개념적인 목표 정의
성능 목표 상황(현재 대비 4배의 부하환경) 하에서 아래에 나열된 조건들을 만족할 수 있는지를 검증합니다.
■ 모 포털 서비스
- 4배 부하 환경에서의 개별 어플리케이션별 Max TPS (JSP , Servlet) 목표치 수용 여부
- 4배 부하 환경에서의 전체 시스템 Max TPS 목표치 수용 여부
- 응답시간이 3초 이상 소요되는 개별 어플리케이션 선별
해당 시스템의 임계 상황 하에서의 최대 수용가능 사용자수와 병목 지점을 밝혀 내고 그 시점을 예측합니다.
■ 모 포털 서비스
- 임계 상황 하에서의 전체 시스템 Max TPS 산출
- 임계 상황 하에서의 최대 수용가능 사용자 수 산출
- 임계 상황 하에서의 병목 지점 도출
- 임계 상황 발생 시점을 예측하여 제시
TPS(transactions per seconds)는 단위시간당 처리된 업무 건수를 의미합니다.
Max TPS는 각 어플리케이션이 최대로 발휘 할 수 있는 고유한 성능 수치로서 성능 튜닝의 기준으로 활용되는 항목입니다.
P1. 분석
“Bringing Success to e-Business”
3.현행 시스템 분석 – Weblog 분석
시간당 동적 컨텐츠 호출 건수
Peak 일자의 Access log을 분석하여 해당 시스템의 Workload을 분석합니다.
Workload Basic Component 선정
클라이언트가 호출한 동적 어플리케이션(JSP,Servlet) 트랜잭션
Workload Parameter 선정
분당 동적 컨텐츠 호출 건수
시간당 동적 컨텐츠 호출 건수 (TPH)
분당 동적 컨텐츠 호출 건수 (TPM)
Peak치 초당 동적 컨텐츠 호출 건수 (TPS)
동시단말사용자수
Peak치 동시 단말사용자수 (N 명)
사용자당 평균 호출 간격 (t 초)
Weblog 분석을 통한 Workload Modeling은 Performnace theory중 Response Time Law에 기반하고 있습니다.
Response Time Law는 N(동시사용자수) = TPS *(R(응답시간)+T(Think Time))입니다.
P1. 분석
“Bringing Success to e-Business”
3.현행 시스템 분석 – Weblog 분석
2월 14일자 모 포털 서비스 현황
시간당 동적 컨텐츠 호출 현황
분당 동적 컨텐츠 호출 현황
HTML, *.gif, *.txt, *.js 등과 같이 웹 서버가 직접 프로세싱 하는 단순한 정적 컨텐츠(Static Contents)를 제외한 JSP, Servlet , asp 에
대한 HTTP 요청을 의미합니다.
P1. 분석
“Bringing Success to e-Business”
3.현행 시스템 분석 – Weblog 분석
2월 14일자 모 포털 서비스 현황
모 포털 동시 사용자 현황
모 포털 시간당 고유 IP 현황
동시 사용자수는 Active User 와 In-Active User를 포함한 일반적인 의미의 동시 접속자 수 입니다
P1. 분석
“Bringing Success to e-Business”
3.현행 시스템 분석 – 시스템 분석
3월 3일자 모 포털 시스템 현황
모 포털 Web Server 1 CPU 사용현황
모 포털 Web Server 2 CPU 사용현황
P1. 분석
“Bringing Success to e-Business”
3.현행 시스템 분석 – 시스템 분석
3월 3일자 모 포털 시스템 현황
모 포털 WAS Server 1 CPU 사용현황
모 포털 WAS Server 2 CPU 사용현황
“Bringing Success to e-Business”
P2.설
계
P2. 설계
“Bringing Success to e-Business”
1. 성능 목표 수립 - Current Workload 산정
2월 14일자 Current Workload
Peak치(11:xx) 시간당 동적 컨텐츠 호출 건수 :
42,010 (tph)
Peak치(11:xx) 분당 평균 동적 컨텐츠 호출 건수 도출 :
444.250 (tpm)
Peak치(11:xx) 초당 평균 동적 컨텐츠 호출 건수 도출 :
7.404 (tps)
Peak치(11:xx) 초당 최대 동적 컨텐츠 호출 건수 도출 :
8.434 (tps)
Peak치(11:xx) 평균 동시 단말사용자수 도출 :
173명
Peak치(11:xx) 최대 동시 단말사용자수 도출 :
194명
사용자당 평균 호출 간격 도출
:
23 초
사용자당 최대 호출 간격 도출
:
24 초
P2. 설계
“Bringing Success to e-Business”
1. 성능 목표 수립 - Target Workload 산정 (Current 대비 4배 부하환경)
Peak치 동시단말 사용자수 – 776 명 (현재 동시단말사용자수(194) * 4)
Response Time Law ( 동시단말 사용자수 = TPS * 사용자호출간격) 적용
TPS = 776 (명) / 23 (초) = 33.7(TPS) 산출
33.7
1. 동시 단말 사용자수는 Active User 와 In-Active User를 포함한 일반적인 의미의 동시 접속자 수 입니다
2. 사용자 호출 간격은 응답시간과 Think Time의 합입니다.
P2. 설계
“Bringing Success to e-Business”
1. 성능 목표 수립 - Target Workload 산정 (임계 테스트 부하 환경)
임계 테스트의 경우 Current Workload 대비 4배,8배,16배 부하 환경을 생성하여 이들 환경 하에서 목표 성능치인 TPS를
만족하는지 여부에 따라 임계 상황을 정의합니다.
구분
현 부하치
1차 테스트 부하치
(현 부하치 4배)
2차 테스트 부하치
(현 부하치 16배)
TPS
가상사용자수(명)
예상 동시접속자수(명)
호출간격(초)/ Think
Time
8.434
194
194
33.736
776
776
135
776
3,104
23/20
23/20
5.75/5
부하를 증가시키는 방법에는 가상사용자수를 증가시키는 방법과 호출간격 중 Think time을 줄이는 방법이 있습니다.
Think Time을 줄이는 방법은 HTTP Session 오브젝트를 많이 쓰는 시스템 환경에서는 가급적 자제하는 게 낫습니다.
P2. Workload Modeling
“Bringing Success to e-Business”
2. 이행 절차 계획 수립 - 성능 측정 대상 선정
•클라이언트의 호출 건수를 기준으로 상위 90%을 차지하는 단위 어플리케이션 선정
• 선정된 단위 어플리케이션에 대한 업무별 가중치 적용
테스트 항목
/web/address/warn_pop_mi_send.jsp
/web/address/address_index.jsp
/web/address/address_add_pop.jsp
/web/address/_address_add_pop.jsp
/web/accounts/sub_day_calendar.jsp
/web/accounts/account_house.jsp
/web/index.jsp
/web/schedule/memos_main.jsp
/web/address/address_modify.jsp
/web/schedule/schedule_calendar.jsp
/web/schedule/anniv_calendar.jsp
/web/diary/Diary_list.jsp
/web/address/group_modify1.jsp
/web/address/warn_pop_del.jsp
/web/schedule/memoday_view2.jsp
/web/schedule/week_view.jsp
/web/schedule/_schedule_register.jsp
/web/myfile/myfile_list.jsp
/web/schedule/_anniversary_register.jsp
/exchange/get_list.jsp
/exchange/buddy.jsp
/exchange/grp_buddy.jsp
/exchange/group.jsp
메뉴명
메신저 보내기
주소록 메인 화면
주소록 빠른 추가 화면
주소록 빠른 추가 처리
일별일정 달력
가계부 메인 화면
마이다이어리 메인 화면
메모 메인 화면
(일정/기념일/할일 하단의
메모 리스트 목록)
주소록 수정 화면
월별일정 달력
기념일 달력
일기장 목록
그룹 수정
주소록 삭제 여부 팝업
년별 기념일 조회
주별 일정
일정 등록 처리
문서 관리 메인의 문서
목록 리스트
기념일 등록 처리
Peak시 한
시간동안의
호출건수
1709
1626
605
522
299
275
240
0.156
0.149
0.055
0.048
0.027
0.025
0.022
210
0.019
190
149
129
117
111
84
79
74
70
0.017
0.014
0.012
0.011
0.010
0.008
0.007
0.007
0.006
65
64
1800
969
550
286
비율
0.006
0.006
0.165
0.089
0.050
0.026
모 포털 업무별 가중치 현황
P2. Workload Modeling
“Bringing Success to e-Business”
2. 이행 절차 계획 수립 - 성능 측정 절차 계획
단위 어플리케이션 테스트
호출 건수 상위 90%를 차지하는 어플리케이션들을 Think time 없이 saturation될 때 까지 부하를 주어 해당 어플리케이션의
Max TPS를 산출한다.
통합 테스트
아래 기술된 어플리케이션들을 웹 로그 분석을 통해 추출된 업무 가중치와 Think Time을 반영하여 목표 사용자까지 부하를 주어
해당 어플리케이션의 응답시간과 Max Total TPS를 산출한다.
P2. Workload Modeling
“Bringing Success to e-Business”
2. 이행 절차 계획 수립 - 성능 측정 절차 계획
테스트 항목
/web/address/warn_pop_mi_send.jsp
/web/address/address_index.jsp
/web/address/address_add_pop.jsp
/web/address/_address_add_pop.jsp
/web/accounts/sub_day_calendar.jsp
/web/accounts/account_house.jsp
/web/index.jsp
/web/schedule/memos_main.jsp
/web/address/address_modify.jsp
/web/schedule/schedule_calendar.jsp
/web/schedule/anniv_calendar.jsp
/web/accounts/_account_edit_prc.jsp
/web/diary/Diary_list.jsp
/web/address/group_modify1.jsp
/web/address/warn_pop_del.jsp
/web/schedule/memoday_view2.jsp
/web/schedule/week_view.jsp
/web/schedule/_schedule_register.jsp
/web/myfile/myfile_list.jsp
/web/schedule/_anniversary_register.jsp
/exchange/get_list.jsp
/exchange/buddy.jsp
/exchange/grp_buddy.jsp
/exchange/group.jsp
메뉴명
메신저 보내기
주소록 메인 화면
주소록 빠른 추가 화면
주소록 빠른 추가 처리
일별일정 달력
가계부 메인 화면
마이다이어리 메인 화면
메모 메인 화면
주소록 수정 화면
월별일정 달력
기념일 달력
일일 출납 등록
일기장 목록
그룹 수정
주소록 삭제 여부 팝업
년별 기념일 조회
주별 일정
일정 등록 처리
문서 관리 메인의 문서
목록 리스트
기념일 등록 처리
Peak시 한
시간동안의
호출건수
1709
1626
605
522
299
275
240
210
190
149
129
117
117
111
84
79
74
70
65
64
1800
969
550
286
비율
0.156
0.149
0.055
0.048
0.027
0.025
0.022
0.019
0.017
0.014
0.012
0.011
0.011
0.010
0.008
0.007
0.007
0.006
0.006
0.006
0.165
0.089
0.050
0.026
목표
사용자
수
108
103
38
33
19
17
15
13
12
9
8
7
7
7
5
5
5
4
4
4
114
61
35
18
가상 사용자
증가 단위
가상 사용자
증가 주기
지속
시간
Think
Time
30명
20초
10분
20초
P2. 설계
“Bringing Success to e-Business”
2. 이행 절차 계획 수립 – 자원 감시 기술 검토
• 각 시스템별 중요 성능 모니터링 항목 설정
항목
시스템
네트워크
웹사이트 성능
응용 프로그램
WAN(ISP)
구간별 Delay
Time
웹 서버
웹 어플리케이션 서버
데이터베이스 서버
CPU,Memory,Paging
Network Delay Time
CPU,Memory,Paging
CPU,Memory,Paging
Execute Thread Count
JDBC Connection Pool
JVM Heap Size
Server Prcocess Count
Network Sub-Path Time
Transactions Per Seconds
Throughput
Transaction Response Time
HTTP Port(80) Established Count
SSL Port(443) Established Count
“Bringing Success to e-Business”
P3.이
행
P3. 이행
“Bringing Success to e-Business”
1. 네트워크 테스트 수행 결과
테스트 대상 시스템 간의 네트워크 구간 점검(네트워크 혼잡도,듀플렉스 모드)을 위해 1M 사이즈의 파일 다운로드를 통한 FTP
테스트를 진행합니다.
구분
IP Address
Test1
Test2
Test3
192.168.196.55
11001K
12010K
12010K
192.168.196.56
12010K
12010K
12086K
192.168.196.59
11083K
11083K
11545K
192.168.196.60
10616K
11545K
11497K
192.168.196.96
11555K
11927K
11889K
192.168.196.97
11519K
10534K
11927K
192.168.196.98
11328K
11681K
11681K
192.168.196.99
11681K
11362K
11717K
DB 1
192.168.196.42
10261K
10902K
10902K
DB 2
192.168.196.43
7929K
8678K
7551K
WEB Server
A 서비스
WAS Server
WEB Server
B 서비스
WAS Server
DB
이론적으로 100M BPS 이더넷의 경우 최대 Throughput은 100M / 8 = 12.5M Bytes/sec 이지만 , 운영중인 시스템의 경우 패킷 충돌(collision)
및 재전송(retransmission) 에 따른 손실 때문에 스위치 네트워크의 경우 8M Bytes/sec 정도를 지표로 삼고 있습니다.
P3. 이행
“Bringing Success to e-Business”
2. 단위 테스트 수행 결과
테스트 명
1.공매공고(listItemInfo)
2.매각물건(listitem)
3.매각물건(view itm_real)
4.홈페이지(index)
5.파워검색(searchItemByDetailInfo)
6.입찰임박물건(listImpendingBidItem)
7.주소검색(searchZipAddress_01)
8.물건정보view Item_bond
예상
A rriva l
A rriva l Ra te R( Ra tio) T ( T P S ) Rm a x ( Re
Ra te/ T
q/ s ec)
0.14
0.14Rmax
0.005
297
0.083
16.25
288
0.080 0.13
1.5 0.13Rmax 0.053
0.08
180
0.050
18.5 0.08Rmax 0.003
0.05
116
0.032
2.75 0.05Rmax 0.012
109
0.030 0.05
8 0.05Rmax 0.004
Hit C ount
161
55
53
9.공매공고(listKamcoAucNotice)
10.새로운공고new AucNotice
11.FAQ보기View FAQ
48
45
44
12.LISTFAQListFAQ
13.새로운공고-view AucNotice
14.ID중복확인checkDuplicateUserId
15.공매일정listItemInfoBySched
43
43
33
60
16.통합공고listAucNotice
17.회원가입w elcomeRegisterForm
18.회원가입동의createUserForm
26
24
22
19.부가정보listDocForm
20.파워검색searchItem
21.새로운물건listNew Item
22.로그인폼loginForm
21
21
19
19
23.이용약관contractPersonalUser
24.로그인login
17
16
Sum
0.045
0.015
0.015
0.489
0.07
0.03
0.02
0.02
28
60
19.5
0.07Rmax
0.03Rmax
0.02Rmax
0.02Rmax
0.002
0.000
0.001
0.005
R/ T
0.0086
0.0867
0.0043
0.0182
JAVA EXCEPTION ERROR
0.0063
0.0025
0.0005
0.0010
8명일때 DB 서버 95% FULL
웹 서버 CPU 사용율 70%
웹 서버 CPU 사용율 100%
웹 서버 CPU 사용율 90%
0.0080
0.0050
0.0008
8명일때 DB 서버 CPU 사용율 100%
6명일때 DB 서버 CPU 사용율 100%
WEB 서버 CPU 사용율 80%
0.0010
0.0008
0.0003
0.0004
DB 서버 , WEB 서버CPU 사용율 90%
웹 서버 다운 - 세션 FULL
웹 서버 CPU 사용율 - 94%
웹 서버 CPU 사용율 - 90%
0.0011
0.0004
0.0004
DB 서버 CPU 사용율 100%
웹 서버 CPU 사용율 90%
웹 서버 CPU 사용율 80%
0.0003
0.0005
0.0025
0.0004
웹 서버 CPU 사용율 90%
웹 서버 CPU 사용율 90%
DB 서버 CPU 사용율 100%
웹 서버 CPU 사용율 90%
웹 서버 CPU 사용율 - 70%
DB 서버 CPU 사용율 100%
0.013
0.013 0.02
0.012 0.02
0.012 0.02
2.5
4 0.02Rmax
24 0.02Rmax
19.5 0.02Rmax
0.012 0.02
0.009 0.02
0.017 0.01
0.007 0.01
24 0.02Rmax
67 0.02Rmax
22.5 0.01Rmax
9 0.01Rmax
0.000
0.000
0.001
0.001
0.007 0.01
0.006 0.01
0.006 0.01
0.006 0.01
0.005 0.01
0.005 0.01
0.005 0.01
22.5 0.01Rmax
23.5 0.01Rmax
32 0.01Rmax
19 0.01Rmax
4 0.01Rmax
25.5 0.01Rmax
24 0.01Rmax
0.000
0.000
0.000
0.004 0.01
3.5 0.01Rmax
0.001
0.0004
0.0029
0.79
0.79Rmax
0.095
0.1535
0.003
0.001
0.001
0.000
0.001
0.000
0.000
비고
CPU 100% FULL
P3. 이행
“Bringing Success to e-Business”
2. 단위 테스트 수행 결과
해당 사이트의 최대 TPS (Rmax) 산정
(예상 Ratio/최대 Throughput의 합)< Ratio 적용
0.1535Rmax < 1
Rmax < 6.515(req/sec)
해당 사이트의 최대 동시단말사용자 산정
동시단말사용자 = TPS * 사용자호출간격 적용
6.515(req/sec) * 33.7(sec) = 219명
최대 동시단말 사용자 수 : 219 명
최대 TPS :
6.515 (TPS)
Target Workload
OK !
P3. 이행
“Bringing Success to e-Business”
3. 통합 테스트 수행 결과
수행환경
성능수치
시스템
사용율
구분
가상사용자수(명)
현 peak 부하에 대한 비율(%)
브라우저 캐쉬 사용여부
Think Time
서비스 최대 TPS
기념일등록처리
응답시간 3초 이
일일출납등록
상 어플리케이
션
일정등록처리
최대
Web1
평균
최소
Web Server
최대
Web2
평균
최소
최대
WAS1
평균
최소
WAS Server
최대
WAS2
평균
최소
최대
DB Server
DB1
평균
최소
테스트 결과
776
400%
예
20초
31.25(tps)
3.701
2.522
5.791
13
5.292
1.75
12.083
5.346
2.25
91.033
62
30.133
79.333
54.983
37.333
69.299
33.904
16.813
P3. 이행
“Bringing Success to e-Business”
3. 통합 테스트 수행 결과
Total TPS 그래프를 통하여 해당 시스템이 테스트 목표 환경 하에서 saturation point없이 정상적으로 운영될 수 있음을 알 수
있습니다.
P3. 이행
“Bringing Success to e-Business”
3. 통합 테스트 수행 결과
평균 응답시간 그래프를 통하여 해당 시스템의 APP중 일정등록처리,기념일등록처리,일일출납등록 등이 응답시간 기준치를
초과함을 알 수 있습니다.
P3. 이행
“Bringing Success to e-Business”
3. 통합 테스트 수행 결과
UNIX Rrsource 그래프를 통하여 해당 시스템 Resource가 테스트 목표 환경 하에서 saturation point없이 정상적으로 운영될
수 있음을 알 수 있습니다.
P3. 이행
“Bringing Success to e-Business”
3. 통합 테스트 수행 결과
Weblogic (JMX) 그래프를 통하여 해당 시스템의 Weblogic 구성환경이 테스트 목표 환경 하에서 Queuing없이 정상적으로
운영될 수 있음을 알 수 있습니다.
P3. 이행
“Bringing Success to e-Business”
3. 통합 테스트 수행 결과
테스트 일자의 Weblog을 분석하여 테스트 목표 하의 부하 테스트가 제대로 수행 되었음을 확인 할 수 있습니다.
테스트당시 access 로그 현황
(현 peak치 기준 4배)
P3. 이행
“Bringing Success to e-Business”
3. 통합 테스트 수행 결과
테스트 일자의 Weblog을 분석하여 테스트 목표 하의 부하 테스트가 제대로 수행 되었음을 확인 할 수 있습니다.
테스트당시 access 로그 현황
(현 peak치 기준 4배)
3월 15일자 로그 현황
P3. 이행
“Bringing Success to e-Business”
4. 임계 테스트 수행 결과
수행환경
성능수치
시스템
사용율
구분
가상사용자수(명)
현 peak 부하에 대한 비율(%)
브라우저 캐쉬 사용여부
Think Time
서비스 최대 TPS
최대
Web1
평균
최소
Web Server
최대
Web2
평균
최소
최대
WAS1
평균
최소
WAS Server
최대
WAS2
평균
최소
최대
DB Server
DB1
평균
테스트 결과
776
1000%
예
5초
77 (tps)
11.667
6.192
1.75
10.917
3.659
1.333
99.9
92.088
50.867
99.633
93.585
56.333
45.394
24.396
P3. 이행
“Bringing Success to e-Business”
4. 임계 테스트 수행 결과
Total TPS 그래프를 통하여 해당 시스템이 Current Workload 대비 10배 부하 환경에서 saturation 이 발생하였음을 확인 할 수
있습니다.
P3. 이행
“Bringing Success to e-Business”
4. 임계 테스트 수행 결과
평균 응답시간 그래프를 통하여 해당 시스템의 APP중 기념일등록처리,일일출납등록 등이 시스템 성능을 크게 영향을 받음을
확인 할 수 있습니다.
P3. 이행
“Bringing Success to e-Business”
4. 임계 테스트 수행 결과
UNIX Resource 그래프를 통하여 해당 시스템 Resource가 Current Workload 대비 10배 부하 환경에서 saturation 됨을 확인
할 수 있습니다.
P3. 이행
“Bringing Success to e-Business”
4. 임계 테스트 수행 결과
Weblogic (JMX) 그래프를 통하여 해당 시스템의 Weblogic 구성환경이 Current Workload 대비 10배 부하 환경에서
Queueing됨을 확인 할 수 있습니다.
P3. 이행
“Bringing Success to e-Business”
5. Capacity Planning 예측 결과
아래 그래프는 해당 시스템의 Weblog을 주기적으로 분석하여 이를 회귀 분석을 통해 생성된 Capacity Planning 예측 결과입니다.
Month
TPS
2
8.53
3
11.47
4
12.82
5
17.38
6
19.52
2003년
7
8
21.67 23.81
9
25.96
10
28.10
11
30.25
12
32.40
현 시스템 구성 하에서 위의
예측 결과를 반영해 볼 때 올
년말 까지는 추가 시스템을 도입
할 필요가 없는 것으로 판단
됩니다.