4. 1. 로드러너
소개
HP Loadrunner 필요성
성능테스트의 필요성
1. 시스템 안에 있는 성능상의 결함을 발견
2. 제한적인 시스템에서 실사용자와 유사한 시뮬레이션
3. 시스템의 자원 최적화
4. 비즈니스 프로세스에서 수행하여 잠재적인 결함 발견
JSP
(Servlet) EJB
업무1
APM
HTTP/S
업무2
AP 서버
VB
Java
PowerBuilder
4
DB 서버
DB
메임프레임
6. HP Loadrunner 소개
1. 로드러너 소개
설치 가능 OS
- Windows 7
- Windows XP Professional SP2 or SP3
- Windows Server 2003 Standard Edition/Enterprise Edition SP2
- Windows Server 2003 Standard Edition/Enterprise Edition R2 SP2
- Sun Solaris 9, 10
- HP-UX 11i
- Red Hat Linux 3, 4, 5
플랫폼
가상사용자 한 명당
메모리사용량
최소 시스템 사양
Windows
2.5 MB
2 Core
Unix
3 MB
2 Core
권장 시스템 사양
4 Core
4 GB Mem 에서
최대 가상사용자수
비고
4 Core
약 200명
(200명 이내 사용자를 권장)
Windows Platform에서는 한 PC당
200명 이내를 권장함(초과할 경우 부
하 발생기 자체의 우Overhead가 큼)
약 500명
(500명 이내 사용자를 권장)
throughput이 network bandwidth를 넘
지 않도록 하기 위해서는 한 Machine
당 1000vuser를 넘지 않는 것이 좋음
4 Core
Windows의 Network Driver 와 OS는 UNIX의 경우보다 성능이 낮아 많은 수의 Session이나 data traffic을 감당하지 못하기에 많은
수의 Vuser 용으로는 적합하지 않음.
Windows 자체에서 사용하는 Resource가 많아 OS 자체가 부담이 많음.
6
7. HP Loadrunner 구성
1. 로드러너 소개
제품 구성도
가상사용자 작성기
(Virtual User Generator)
자원 모니터링
서버실
RAC
부하 제어기
(Controller)
DB
WAS
Web Server
부하 발생기
(Load Generator)
수행결과 분석
(Analysis)
7
8. HP Loadrunner 구성
1. 로드러너 소개
제품 구성도
제품
모듈 구성
내용(기능요약)
가상 사용자를 생성하기 위해 어플리케이션 비즈니스 프로세스를 레코딩하는 기능
을 수행
Virtual User
Generator
• 테스트 사용자 시나리오 Record
• Transactions
• 스크립트의 테스트 데이터 파라메터 설정
작성한 스크립트를 시나리오로 정의하고, Load Generator을 제어하는 모듈
Load Runner
Controller
• 가상사용자 Test scripts, Vusers 정의 (Vuser 수, Test scripts 등)
• 서버 시스템 자원 모니터링 설정
• 부하 발생기 할당
Load Generator
Analysis
실제로 스크립트를 실행시키는 모듈
부하테스트 결과를 그래프로 확인하고 병목현상 분석을 도와 주는 모듈
8
9. HP Loadrunner 구성
1. 로드러너 소개
Controller
•
•
•
•
테스트하기 위한 시나리오를 관리, 통제하는 프로그램
가상 사용자의 수를 정의하여 부하발생 시나리오 정의함.
테스트 수행 동안 실시간 그래프 형태로 모니터링.
모니터링 통계자료를 데이터베이스 형태로 수합하여 저장함.
테스트 모니터링
시나리오 정의
9
10. HP Loadrunner 구성
1. 로드러너 소개
Controller - Monitoring
• 테스트 진행 중 성능 테스트의 대상이 되는 서버의 전체 자원 사용률, 성능관련 데이터를 수집함.
• UNIX의 자원 사용율, Application의 성능을 측정하여 실시간으로 제공함.
• 모든 데이터 통합 수집 및 제공함.
Application 상태 모니터링
자원사용률 모니터링
10
11. HP Loadrunner 구성
1. 로드러너 소개
Virtual User Generator
• End User의 업무 로직을 GUI 화면에서 마우스 클릭하면 자동적으로 Test Script가 자동으로 작성되며, 수정 및 변경이 가능하도록
Editor를 제공함.
11
12. HP Loadrunner 구성
1. 로드러너 소개
Analysis
• 데이터베이스 형태로 수집 저장된 통계자료 및 그래프들을 이용하여 다양한 분석 그래프 및 데이터를 제공함.
• Word, Excel, HTML 형태의 리포트를 제공함.
12
13. HP Loadrunner 구성
1. 로드러너 소개
Analysis
• 성능 저하 요인을 빠르게 찾을 수 있도록 Automatic Correlation 그래프, 그래프 Merge 기능 등 다양한 기능 제공
• Word, HTML 형태의 Report 제공 : 웹 브라우저를 통하여 분석 가능
< 응답시간 >
< 응답시간 : IIS, MS-SQL
Windows Resources >
< 응답시간, Hit/Sec, UNIX Resource,
Oracle에 대한 상관관계 그래프 >
13
14. HP Loadrunner 주요기능
1. 로드러너 소개
성능테스트 적용 시기
분석
설계
BMT
H/W Capacity 산정
성능 & 스트레스 테스트
시스템 (H/W, M/W, DB등)
구현
단위 기능
테스트
테스트
서비스 중
이행
통합 기능
테스트
성능 & 스트레스
테스트
시스템 Configuration 변경
및 Upgrade, 업무 추가 등에
성능 & 스트레스 테스트
성능 감시 및 모니터링
(모니터링 / 경보 / 식별 / 진단)
기능 테스트 (단위 / 통합)
스트레스 테스트
시스템 (H/W, M/W, DB등)
성능 테스트
시스템 (혹은 프로젝트) 감리 시 혹은 검수 시에도 필요!!!
•
•
•
14
• 서비스 응답시간 가용성 이슈에
대한 성능 점검
• 현 상황에서의 시스템 점검
• 시스템 구축 변경에 성능 점검
새롭게 개발된 서비스의 오픈
최대 수용 가능한 사용자 수 산정
현 상황에서의 시스템 점검
15. HP Loadrunner 주요기능
1. 로드러너 소개
지원 플랫폼
Web
HTTP(S)
SOAP
Winsock
FTP
DNS
SMTP
POP3
IMAP
MAPI
WAP
iMode
Voive-XML
Palm
LDAP
Real Player
MS Media
Middleware
EJB
CORBA
COM/DCOM
RMI
Jacada
Brokat
TUXEDO
Jolt
MQSeries
ERP/CRM
Baan
Oracle Apps.
SAP (mySAP.com)
Siebel
PeopleSoft
Clarify
Databases
Oracle
MS SQL
DB2
Sybase
Informix
ODBC
Legacy
3270
5250
VT100
Scripting Languages
C, Java, JavaScript, VBScript, VBA, C# and C++
패키지
어플리케이션
웹서버
인터넷
JSP
(Servlet) EJB
HTTP/S
TP
모니터
WAP
Gateway
AP 서버
VB
Java
PowerBuilder
15
DB 서버
DB
메임프레임
16. HP Loadrunner 주요기능
1. 로드러너 소개
다양한 형태의 실시간 모니터링 (데이터 통합)
Performance Monitors!!!
Controller
OS
• Win-NT, 2000
• Win-XP
• UNIX
• Linux
Java
• EJB
• JProbe
• Tower/J
• JMonitor
Virtual
Users
Network
FireWall
• CheckPoint
Load Balancer
• F5
Network
• SNMP
• Network Delay
Web Server
F/W
Web Server
• MS IIS
• iPlanet (NES)
• Apache
• Oracle 9iAS
Streaming
• Real Server
• MS Media
Server
• Client Monitors
16
AP Server
Middleware
• TUXEDO
ERP
• SAP R/3
DB Server
Database
• Oracle
• SQLServer
• DB2
• Sybase
Web App. Server
• BroadVision
• Ariba
• Allaire ColdFusion
• ATG Dynamo
• SilverStream
• iPlanet (NAS)
• BEA WebLogic Server
• GemStone/J
• WebSphere
• Fujitsu InterStage
• MS ASP
• SAP R/3
• Oracle 9iAS
• Brokat Twister
17. HP Loadrunner 주요기능
1. 로드러너 소개
다양한 형태의 실시간 모니터링 (데이터 통합)
다운로드 되는 웹 페이지의 수행시간 측정:
• DNS Lookup
• Time to connect
• Time to first buffer
• Download time
• SSL handshake time • FTP authentication
• Sub-transaction
• Client time
• Error(retry) time
Client
Server
DNS lookup
Initial connection
Establish connection
Request a page/resource
Network
Receive Ack
Send Ack
Server
Time
Send first buffer
Receive
first buffer
Send more data
Receive page/resource
Think time
< HTML, Image 다운로드 시간 >
17
18. HP Loadrunner 라이선스
1. 로드러너 소개
라이선스 정책
•
•
•
Protocol List
Permanent : 기간 제한 없이 영구적으로 사용
Term : 기간 동안 사용
VUD : (Virtual user Days) 24시간만 사용.
라이선스 단위
• 프로토콜 별 가상사용자 단위
• 모니터링 요소
예>
VUD : WEB 1000명.
Term : WEB 100명 (8월 17일 ~ 9월 17일)
18
20. 성능시험
2. 성능기초
성능시험 정의
실제 시스템이 가동되는 상황에서 일어날 수 있는 여러 가지 조건을 분석하여, 분석된 조건에 최대한
부합되도록 시스템과의 가상 거래를 일으켜 그때의 시스템의 상태를 보는 행위
컨트롤러
가상 사용자
(수백 ~ 수만명)
웹서버
Internet/
WAN
App. Server
데이터 베이스
1) 성능 측정 : 성능 관점의 성능시험을 수행하여 시스템이 운영 전에 적정한 성능을 내는 지 확인
2) 결함 검출 : 성능시험을 수행하여 시스템 운영 상태에서 나타날 수 있는 문제를 사전에 확인
3) 병목 제거(튜닝) : 검출된 소프트웨어 결함에 대해 적절한 조치
4) 용량 검증/산정 : 운영 시스템의 용량이 Peak 시에 업무를 처리할 수 있는지를 확인
20
22. Response Time
2. 성능기초
Response Time: 사용자의 요청(Request)을 처리하는 시간 : 응답시간
일반적으로 웹 환경에서의 응답시간은
Response Time = Network Time + Server Time(Web Server Time + WAS Time + DB Time) + Client Time
Response Time
사용자2
사용자3
사용자4
사용자5
시간
22
23. Think Time
2. 성능기초
Think Time: 사용자 요청간의 대기시간
Request Interval : Response Time + Think Time
Request Interval
Response Time
Think Time
사용자1
사용자2
사용자3
사용자4
시간
23
24. Concurrent User
2. 성능기초
Concurrent User: 동시 사용자 : 해당 시스템을 사용하기 위해 PC앞에 앉아 있는 사용자
Active User(Clients) 와 InActive User (Clients) 로 구성됨
Named User: 해당 시스템에 접속이 가능한 사용자
동시사용자 3명
사용자1
사용자2
사용자3
사용자4
사용자5
10분
시간
10분
24
25. Active User
2. 성능기초
Active User: Request 요청을 하여 응답을 기다리고 있는 사용자, 즉 WEB 화면에서 클릭이나 엔터를 치고
나서 화면이 나올 때 까지 기다리고 있는 사용자.
Inactive Users: 현재 Request 를 수행하지 않고 있으며, 화면의 결과를 보고 있거나 다음 버튼을 누르기
전까지의 사용자
Concurrent User = Active User + Inactive User
Active User 1명
사용자1
사용자2
사용자3
사용자4
사용자5
Active 상태
시간
25
26. 2. 성능기초
TPS
TPS ( Transaction per Second ) : 초당 처리 건수 : 사용자의 요청(Request)에 대한 처리
- TPM (Transaction Per Minute)
- TPH (Transaction Per Hour)
( 1TPH = 60TPM = 3,600TPS )
TPS
TPS
응답시간
사용자
26
27. 2. 성능기초
TPS
Concurrent User = TPS * Request Interval
2 TPS * 10 초 = 20 명
20명
Server
1초
Container1
Container2
시간
2 TPS
27
28. 2. 성능기초
TPS
Concurrent User = TPS * Request Interval
TPS = Concurrent User / Request Interval
5 TPS = 5 명 / 1 초
1초
사용자1
사용자2
사용자3
사용자4
사용자5
시간
28
29. TPS 계산방법
2. 성능기초
Concurrent User = TPS * ( Response Time + Think Time )
Active User = TPS * ( Response Time )
전체 업무의 목표는 50 TPS
동시사용자 분석 결과 300명으로 확인
Concurrent User = TPS * Request Interval
300 = 50 * Request Interval
Request Interval = 6 초
문제> 분석결과 동시사용자 240명, 목표 TPS 20을 만족하기 위해서 가장 효율적인 시나리오는?
단, 로드러너 라이선스 100명만을 보유함.
답> 240명 / 20 TPS = 12초이나 라이선스 부족으로 100명 / 20 TPS = 5초로 테스트를 진행함.
29
30. Saturation Point
2. 성능기초
Saturation Point: TPS가 더 이상 증가되지 않는 시점: 포화 지점
Saturation Point
TPS
TPS
응답시간
최대 허용 동시 사용자
사용자
30
Saturation Point(포화 지점) 이후부터는
병목현상으로 인하여 TPS가 더 이상 증가
하지 않고 수평을 유지하게 되고
응답시간은 기하급수적으로 증가하게
됩니다.
Saturation Point(포화 지점) 이후부터는
동시 사용자가 증가하더라도 성능이 더
이상 개선되지 않기 때문에 이때 당시의
동시사용자를 최대 허용 동시 사용자라고
표현합니다.
31. 단위성능시험
2. 성능기초
단계별 부하생성 방안
- 성능시험의 대상이 되는 개개의 업무의 최대성능을 산출
- 단위 업무별 목표 성능에 대한 부하를 5초당 1명씩 증가하여 최대 사용자까지 증가함.
- 업무별 튜닝
개별 Application 별 튜닝 포인트 도출 및 가용성 검증
사용자
1000명
Ramp-UP 단계
시간
온라인 측정구간
단위 성능시험
성능시험의 대상이 되는 개개 업무의 최대 성능을 산출하기 위한 성능시험. 일반적으로 통합 시험을 위한 업무 어플리케이션 튜닝
과정과 동시에 진행됨.
31
32. 통합성능시험
2. 성능기초
단계별 부하생성 방안
- 성능시험의 대상업무를 업무가중치와 부하 시나리오를 이용해 실제 시스템이 가동되는 상황을 재현
- 모든 업무를 동시에 부하를 발생하여 1시간 동안 유지함.
- 10분 동안의 응답시간, 가용성, TPS 검증.
사용자
Duration 단계 (10분)
1000명
Ramp-UP 단계
시간
온라인 측정구간
통합 성능시험
성능시험의 대상업무를 업무 가중치와 부하 시나리오를 이용해 실제 시스템이 가동되는 상황을 재현하는 성능시험. 이를 통해 목표
성능의 도달 여부를 판단할 수 있음.
32
33. 임계성능시험
2. 성능기초
단계별 부하생성 방안
- 성능시험 대상 시스템이 발휘 할 수 있는 최대 성능을 측정
- 모든 업무를 통합성능시험 1배 이상의 부하를 발생하여 1시간 동안 유지함.
- 1시간 동안의 응답시간, 가용성, TPS 검증.
- 용량산정
사용자
사용자
1000명
Duration 단계 (10분)
2000명
Ramp-UP 단계
Ramp-UP 단계
통합성능시험
시간
온라인 측정구간
시간
온라인 측정구간
33
34. 안정성성능시험
2. 성능기초
단계별 부하생성 방안
- 시스템이 오랫동안 거래를 발생 시켰을 때의 시스템 상황을 점검하기 위한 성능시험
- 모든 업무를 동시에 부하를 발생하여 24시간 동안 유지함.
- 가용성, 자원 검증(Leak)
사용자
Duration 단계 (24시간)
1000명
Ramp-UP 단계
시간
온라인 측정구간
34
35. 가용성시험
2. 성능기초
단계별 부하생성 방안
- 모든 업무를 동시에 부하를 발생하고, 가용성의 영향에 따른 서비스 영향을 확인
- 가용성저하 시간, 응답시간, TPS
사용자
Duration 단계
1000명
Ramp-UP 단계
시간
온라인 측정구간
35
37. Workload Modeling 이란
3.Workload Modeling
Workload Modeling은 시스템의 성능관리에 있어서 가장 어려운 부분 중 하나가 시스템이 사용자로부터 요청
받은 작업을 처리하는 일의 양을 통계적으로 분석하는 활동이며, 테스트 대상 시스템의 부하량을 분석하는 과정
을 Workload 분석이라 이야기 함.
성능테스트의 일반적인 목적
현재의 시스템 혹은 어플리케이션이 최대로 수용 가능한 동시단말사용자수가 몇 명인지, 혹은 목표로 정한 성능이
도출되지 않을 때 병목지점이 어딘지를 밝히고 목표성능을 획득하기 위해 무엇을 시정해야 하는지를 찾아내기 위
함.
성능테스트 과정에서 매우 중요한 부분은 목표성능을 설정하고 그러한 목표성능을 확인/측정하기 위해 향후 시스
템 운영 중에 실제로 발생할 접속사용자의 호출패턴이 어떠하냐를 분석/추정하는 과정이 반드시 필요하고, 이를
근간으로 점진적 부하를 발생시켜야 의미 있는 성능테스트 결과를 도출할 수 있습니다. 그렇지 않을 경우 성능테
스트가 자칫 스트레스테스트로 끝남.
성능시험을 진행 하기 전에 진행 순서에 맞게 정확한 분석과 세밀한 설계가 이루어 졌을 때 대상 시스템의 목표 성
능 치를 만족하기에 어려움이 없을 것으로 판단됨.
Workload 분석 기본 요소
• 동시사용자
• TPS
• 호출간격
• 단위업무별 호출비율(건수)
37
38. Log 분석
3.Workload Modeling
Log 분석을 통한 다음과 같은 데이터로 현 시스템의 부하량을 분석함.
필수항목
1. 시간당 호출건수 Peak Time 확인
2. Peak Time 분, 초당 호출건수 목표 TPS 정의
3. 10분당 동시사용자 수
4. Peak Time 어플리케이션 별 호출건수 대상업무 정의
선택항목
1. 사용자 OS/ Browser 분석
2. HTTP Code 별 호출건수 400, 500 에러 수정
3. 어플리케이션 별 응답시간 변화 추이
38
39. Peak Time 분석
3.Workload Modeling
현행 시스템의 Log을 통하여 Peak Time과 Peak Time의 동시사용자 실 사용자의 주요 업무 패턴등을 분석함.
Log 분석을 통하여 시간 별 동적 컨텐츠의 호출건수를 분석한 결과 Peak Time이 언제 인지를 확인함.
1. Peak Time
2. Peak Time 총 호출건수 (TPH)
3. Peak Time 분당 최대 호출건수 (Max TPM)
4. Peak Time 분당 평균 호출건수 (Avg TPM)
5. Peak Time 초당 최대 호출건수 (Max TPS)
6. Peak Time 초당 평균 호출건수 (Avg TPS)
7. Peak Time 최대 동시사용자 (Max Concurrent User)
8. Peak Time 평균 동시사용자 (Avg Concurrent User)
9. Peak Time 최대 호출간격 (Max Request Interval)
10. Peak Time 평균 호출간격 (Avg Request Interval)
최종 목표 결과 데이터
1. Peak Time 초당 최대 처리건수
2. Peak Time 최대 동시사용자
3. Peak Time 최대 호출간격, 평균응답시간, Think Time
※ 업무 호출간격 = 업무의 응답시간 + 사용자 think time
39
41. 시험데이터 처리 활용
3. 성능시험 방법론
시험 데이터 확보
시험 데이터는 실제 운영되는 데이터에서 이행 받아서 사용해야 실제 운영 환경에서 발생하는 여러 현상을 그대로
재현할 수 있음.
오픈이전의 개발중인 시스템의 성능시험은 향후 2-3년의 데이터 증가량을 분석하여 데이터를 확보해야 함
기본 Log Format은 아래와 같음.
2008-05-11 15:59:11 122.45.45.45 - W3SVC1 222.122.222.222 80 GET /Index.asp sel=club&strKeyword=Believe
200 0 0 1595 47 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+FunWebProducts)
대상업무
클럽통합검색
파라미터
입력데이터
설명
strKeyword
Believe , Broken …
검색어
sel
All , club …
검색옵션
41
43. VuGen 기본
4. VuGen
실행: 시작 > 프로그램 >
Loadrunner > Applications >
Virtual User Generator 실행
43
44. VuGen 기본
4. VuGen
초기 화면에는 새로운 스크립트
생성 버튼과 기존 스크립트 열기
버튼이 존재합니다.
지금은 생성된 스크립트가
존재하지 않으니, 새로운
스크립트를 만들도록 하겠습니다.
44
45. 프로토콜 선택
4. VuGen
새로운 스크립트를 생성하기
위해서는 프로토콜을 선택을 해야
합니다. 프로토콜 선택은
클라이언트가 서버에 접속하기
위해서 필요한 프로토콜로 서버와
클라이언트의 통신과정을 레코딩
하기 위해서 정확한 프로토콜이
선택 되어야 합니다.
이번에는 일반적으로 가장 많이
사용되는 HTTP 프로토콜을
선택하여 생성하도록 하겠습니다.
45
47. Action
4. VuGen
5. Action
추가적으로 더 생성을 할 수
있지만, 기본적으로 2가지를
제공하고 있습니다. 이 기본적인
3가지의 기능은 다음 그림과 같이
수행합니다. 스크립트가 수행이
되면 Init를 1번 수행하고,
Action은 스크립트 Run-Time
옵션에 설정된 값대로 반복해서
수행이 됩니다. 그리고 Action의
반복이 완료되면 End를 수행하여
스크립트의 동작이 완료됩니다.
47
48. Recording 옵션
4. VuGen
HTML 방식
페이지 단위의 스크립트
URL 방식
오브젝트 단위의 스크립트
HTML
Browser / context sensitive
Records as Web objects
"high level"
Some necessary information
not included in new request
If cached information matches
new request, VuGen records
web_submit_form()
URL
HTTP / analog
Web objects are used as
function arguments
"low level"
Contains all information necessary to complete new request
VuGen records
web_submit_data()
48
49. HTML 방식
4. VuGen
-A script describing user actions: 이 옵션은
스크립트에 링크명이 레코딩 됩니다. 즉, 다음 페이지의
링크가 URL이 아닌 링크명이 기록됩니다.
- A script containing explicit URLs only: 이 옵션은
스크립트의 URL을 레코딩합니다. 링크명과 관련 없이
URL을 레코딩이 다음 페이지로 이동합니다.
실제 페이지에 링크가 삭제되어도 스크립트에 URL이
레코딩 되어 있다면 해당 URL을 호출합니다.
- Record within the current script step: 페이지가
아닌 오브젝트들(js, swf, gif, jpg, txt …)을 호출하는
web_url 함수의 Arguments로 레코딩 합니다.
한 web_url함수로 레코딩된 모든 오브젝트를 호출할
수 있음.
* Concurrent Group 이란
동시 호출이라 생각하면 됩니다. 레코딩 당시에 2개의 오브젝트를
동시에 처리가 되었다면 web_concurrent_start(NULL),
web_concurrent_end(NULL)를 정의하여 동시 호출이 가능하도록
합니다.
참고
페이지를 web_url로 호출하게 되면 이미지와 js는 기본적으로 같이
호출하게 됩니다.
49
-Record in separate steps and use concurrent
groups: 페이지와 오브젝트를 (swf, txt…) web_url
함수로 레코딩 됩니다. 또한 Concurrent groups이
레코딩 됩니다.
- Do not record: 페이지만을 레코딩 합니다. (이미지,
js들은 기본으로 호출됨.)
50. URL 방식
4. VuGen
URL 방식은 기본적으로 모든 오브젝트를
Web_url함수로 레코딩합니다. 이미지, js, html JSP
등등 모든 오브젝트가 web_url 함수로 레코딩
됩니다.
- Create Concurrent group for resources after
thir source HTML Page: 동싱 호출 함수인
web_concurrent_start , web_concurrent_end를
사용할 지 여부를 조절합니다.
- Use web_custom_request only:
web_custom_request 함수를 사용하여 레코딩
됩니다. 실제적인 body이 내용이 레코딩이 되어
레코딩된 모든 내용을 그대로 호출할 수 있는 장점이
있습니다.
50
53. Transaction 정의
4. VuGen
레코딩에 필요한 모든 액션을
브라우저에 클릭, 입력함.
자동으로 레코딩이 이루어짐.
트랜잭션 정의 Start Transaction
버튼 클릭. (브라우저에서 정의된
대상업무의 액션 수행)
트랜잭션 정의 End Transaction
버튼 클릭.
53
54. Script
4. VuGen
레코딩과정은 모든 작업들이
자동으로 처리되기 때문에
간편하게 레코딩 작업을 할 수가
있습니다.
Generation Log는 레코딩
당시의 처리했던 데이터를 보관함
Regeneration 실행을 통하여
레코딩 했던 처음 상태로 복원이
가능함
54
56. Script Run-time Option
4. VuGen
스크립트 작성이 완료된 이후
스크립트를 보다 실제 사용자와
비슷한 액션을 취하게 하거나,
스크립트에 문제가 있을 경우
디버깅 작업을 쉽게 하기
위해서는 필요한 작업이 RunTime Setting 작업입니다.
"F4" 단축키를 입력하면 보다
빠르게 Run-time Setting 창을
실행할 수 있습니다.
56
57. Script Run-time Option
4. VuGen
스크립트의 Http Code Error 제거
이미지나 JS, CSS 등의 Non-HTML
파일들은 404에러가 발생하여도
Warning만으로 로그에 표시됨.
다음과 같은 옵션 조절로 Error를
확인 할 수 있음.
57
58. Script Run-time Option
4. VuGen
General – Run Logic 설정
RunLogic 세팅에는 Number of
iterations 값을 세팅하게 됩니다.
이 값은 Action.c 를 몇 번 반복한
것인가를 세팅하게 됩니다.
위 그림과 같이 "5"라는 숫자를
입력하게 되면 스크립트는
vuser_init.c를 1번, Action.c를
5번, Vuser_end.c를 1번 수행게
됩니다. 성능시험은 정의된
대상업무를 반복적으로
수행하였을 때의 시스템과
서비스의 상태를 확인 하는 것이
목적이기 때문에 이 반복 횟수가
얼마로 세팅되었는지가 가장
중요한 합니다. 나중
컨트롤러에서는 이 횟수를
시간이나 무제한으로 세팅하는
방법이 있고, 이 방법은
Controller 에서 자세한 설명이
포함됩니다.
58
59. Script Run-time Option
4. VuGen
스크립트 창에서 (Run-Time Setti
ng 창 종료후) 에서 오른쪽 버튼을
클릭하여 Create New Action 선택
합니다.
이름을 적당히 정의하면 아래와
같이 Action 밑에 Action2가 추가
됩니다.
59
60. Script Run-time Option
4. VuGen
Pacing 설정은 반복 이후 다음의 반복을
하기전의 Think Time을 적용하는 기능입니다.
즉! 반복 이후 일정 시간을 대기 했다 다음
반복을 진행하게 됩니다.
As Soon as the previous iteration ends:
대기시간 없이 반복함
After the previous iteration ends:
대기시간을 고정 혹은 랜덤하게 설정함.
At Fixed or random intervals, every :
반복시간을 항상 고정 혹은 랜덤하게 유지함.
(이 설정에 시간이 30초가 세팅되면 action의
1회 수행하는 동안 걸린 시간을 제외하고
남은 시간 만큼만 대기 하게 됨 )
60
61. Script Run-time Option
4. VuGen
Enable Logging: 로그 설정 여부
Log Options - Send messages only when an error
occurs : 에러가 발생할 때만 로그를 쌓는다. advanced
옵션은 로그의 크기를 설정함.
Always send messages: 항상 로그를 쌓는다.
Standard log : 일반적인 에러 메시지를 확인.
Extented log : 자세한 로그 메시지를 확인.
Parameter substitution : 파라미터 설정에 관련된
메시지를 확인 할 수 있음.
Data returned by server : 서버로부터 받은 데이터를
모두 확인 할 수 있음.
Advanced trace: 스크립트에서 발생한 모든 메시지를
전부 확인 할 수 있음.
61
62. Script Run-time Option
4. VuGen
Think Time Options은 보통 스크립트의 내용에
Lr_thinktime() 함수를 사용한 경우에만 의미가 있습니다.
Ignore think time : 스크립트의 think time을 모두
무시함.
Replay think time - as recorded : 스크립트에 기록된
think time을 사용함.
- Multiply recorded think time by : 스크립트에 설정된
think time을 수치 만큼 곱하여 사용함.
- Use random percentage of recorded think time :
최소와 최대를 설정하여 해당 퍼센트 만큼 랜덤하게
사용함.
Limit think time to : thnik time 최대 시간을 제한함.
설정된 시간을 초과 할 수 없게 됨.
62
63. Script Run-time Option
4. VuGen
additional attributes 는 스크립트에서 사용할 수
있는 변수를 정의하여 스크립트에 사용합니다.
attibutes에 변수명과 값을 정의하면 스크립트에서
설정된 변수의 값이 Run-Time setting에 의해
변경됩니다. 이 변수를 스크립트 수정을 run-time
setting만으로 쉽고 빠르게 하기 위해서 사용됩니다.
strUsertype = lr_get_attrib_string("usertype");
63
64. Script Run-time Option
4. VuGen
Error Handling
- Continue on error : 에러가 발생해도 스크립트 다음
행 실행을 계속 한다.
- Fail open transaction on lr_error_message :
- Generate snapshot on error : 에러 발생에 따른
스냅샷 처리여부
Multithreading
- process : 프로세스 방식
- thread : 쓰레드 방식
Automatic Transactions
- Defind each action as a transaction :
스크립트의 .c 파일에 따라 자동으로 트랜잭션을
정의함.
- Defind each step as a transaction : 스크립트의
호출하는 함수를 모두 트랜잭션으로 정의함.
64
65. Script Run-time Option
4. VuGen
Network speed - Use maxinum bandwidth :
Generator가 설정된 네트워크를 그대로 모두
사용함.
- Use bandwidth : 옵션 설정에
따라 네트워크를 제한함.
- Use custom bandwidth : 사용자
정의에 의한 네트워크를 제한함
65
66. Script Run-time Option
4. VuGen
브라우저 설정 기준 Runtime 세팅방법
1. 페이지를 방문할 때마다 : 브라우저 캐시
시뮬레이트를 선택, 페이지를 방문할 때마다
저장된 페이지의 새 버전 확인 사용,
2. Internet Explorer를 시작할 때마다 : 브라우저
캐시 시뮬레이트만 선택, 자동 브라우저 캐시
시뮬레이트만 선택
3. 사용 안 함: 브라우저 캐시 시뮬레이트를 선택
download Non-HTML resource 는 1,2,3의 경우
모두 사용합니다.
66
67. 4. VuGen
Verification
문자 방식
이미지 방식
에러메세지 방식
74행
74행 Runtime Log
67
참고
Verification 전략
한 페이지 5글자이상 표시 되지
않아야 함
계속 변경되는 글자는 피해야 함
페이지에 대한 검증을 할 수 있는
글자여야 함
68. 4. VuGen
Parameter
이렇게 작성된 스크립트는 구글
홈페이지에서 접속하여
"Loadrunner"를 검색하는 작업을
반복할 것 입니다. 그런데 저희가
하는 성능시험의 대부분은 동일한
검색어로 성능 시험을 진행하는
경우는 거의 없을 겁니다. 많은
사용자가 다양한 검색어도 다양한
결과를 확인 하듯이 Loadrunner
스크립트도 다양한 결과가
가능하도록 설정할 필요가 있습니다.
이 방법이 수동파라미터를 처리하는
방법입니다.
68
69. 4. VuGen
Parameter
여러가지 다양한 검색어를
준비합니다. (Text 형태가 가장 좋을
것 같습니다.)
3. 스크립트에서 Text 파일을
연결합니다.
Vuser메뉴 --> Parameter
List(Ctrl+L) 클릭 --> New 클릭 -->
Parameter 이름 정의 --> 파일 찾기
69
72. 4. VuGen
Correlation
메일 삭제나 메일 보기의 성능 시험을
진행 할 때 메일을 삭제를 반복하여
테스트를 하여야 하는데, 1번 메일을
삭제하게 되면 1번 메일이 없기
때문에 2번 메일을 삭제하고, 다음
반복에서 3번, 4번 … 테스트가 끝날
때까지 반복을 해야 합니다.
이 생기는 문제는 그때 그때 이
번호를 확인해서 삭제할 메일 번호를
서버에 전송해야지만 원활한
테스트가 이루어 질 겁니다. 이때
필요한 것이 자동 파라미터 처리
방법입니다.
72
73. Correlation
4. VuGen
web_reg_save_param("param1", "LB=select_arrange=headnum&desc=asc&no=",
"RB="", "Ord=2", LAST);
lr_start_transaction("게시물목록");
web_url("zboard.php",
"URL=http://guru.mireene.com/bbs/zboard.php?id=Testing&page=1&sn1=
&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc",
"TargetFrame=",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t8.inf",
"Mode=HTML",
<a
href="view.php?id=Testing&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arr
ange=headnum&desc=asc&no=5" >test3</a> <font class=zv3_comment></font></td>
73
Web_reg_save_param
파라미터명
왼쪽 글자
오른쪽 글자
순번
참고
Auto Correlation 2가지 방법이
존재함.
75. Monitoring
5. Monitoring
모니터링 설정을 기본적은
Windows와 UNIX를 설정할 수
있고, Web Server, Web
Application
server, Database, ERP/CRM
등으로 나주어져 있습니다.
75
76. Monitoring
5. Monitoring
Windows 설정
- Windows NT / Windows 2000 에서
Monitoring을 하려면 Server의
Administrator권한의 계정으로
Server에 Login하여야
합니다.(탐색창에서 로그인, 혹은
검색창에서 컴퓨터 검색을 통한
로그인)
1. Windows Resources 를 더블
클릭하거나 드래그앤 드롭으로
모니터링창에 생성하면 됩니다.
76
77. Monitoring
5. Monitoring
2. 모니터링창에서 오른쪽 마우스를
클릭하여 Add Measurements 를
클릭합니다.
3. Windows resources 창으로
"Add" 버튼을 클릭하고, add
machine 창의 Name에 모니터링
대상 서버의 아이피 주소나 호스트
네임을 입력하면 됩니다.
77
78. Monitoring
5. Monitoring
4. 모니터링 대상서버의 입력이 완료
되었으면, Resource Measurements에 "Add" 버튼을
클릭하고 Windows Resources 창에서
Object, Counter, Instances 를 선택하고 "Add" 버튼을
클릭하면 모니터링 설정이 완료됩니다.
Windows 모니터링 설정은 Windows Performance
Counters와 동일합니다.
78
80. Monitoring
5. Monitoring
성능시험 대상이 되는 시스템의 구성요소를 정확히 파악하고 예상 병목 지점을 찾아 낼 수 있는 방안을 마련해야
하며, 각 구간별로 모니터링 설정을 통하여 서버 별 자원사용률을 감시함.
- 운영체제
- 웹 서버
- 어플리케이션 서버
- 데이터베이스
80
90. Controller
6. Controller
- Trans Response Time: 각 트랜잭션별 응답시간(sec)
트랜잭션별 응답시간은 Max, Min, Avg, Std, Last의 수치를 보여줍니다.
Max: 테스트중 트랜잭션의 가장 수치가 큰 응답시간.
Min: 테스트중 트랜잭션의 가장 수치가 작은 응답시간.
Avg: 테스트 동안의 트랜잭션의 평균 응답시간.
Std: 테스트의 모든 트랜잭션 응답시간의 표준편차
Last: 테스트중의 가장 마지막으로 처리된 트랜잭션의 응답시간.
90
92. Controller
6. Controller
사용자 그래프와 TPS 그래프를
합하여 한 그래프에서 동시에 확인이
가능함.
TPS의 목표 달성여부나 병목여부를
확인 하기 위해서는 가상사용자의
증가 추이와 비교하여 한계점이
발생했는지 여부를 확인하게 됩니다.
이 때 Total Trans/sec만 보는 것
보다는 가상사용자의 그래프와
통합하여 확인하는 것이 보다
효율적입니다.
92
93. Controller
6. Controller
상세한 에러 메시지창에는 에러메세지, 발생건수, 발생한
가상사용자수, 스크립트 수, 발생한 Generator 수 등이 표시됩니다.
발생건수를 한번 더 클릭하게 되면 시간대별 에러 내용과 스크립트의
에러 라인까지 확인 가능합니다.
보통 Failed Transaction보다 Error 건수가 많은 경우가 많습니다.
이유는 한 트랜잭션에서 여러 개의 에러가 발생하는 경우가 많기
때문입니다.
93
96. Report
7. Analysis
Analysis Summary는 성능시험
데이터의 요약리포트로 보시면
됩니다. 다음과 같은 내용이 포함
되어 있습니다.
테스트 수행시간
시나리오명
성능시험중 최대 사용자 (Max
running vusers)
성능시험에 사용된 총
데이터량(Throughput), 평균
데이터량(초당 바이트량)
총 Hits 수 (HTTP Requests), 평균
초당 Hits 수
트랜잭션별 응답시간(최소, 평균,
최대, 표준편차, 90%), 성공건수,
실패건수, Stop건수
HTTP 코드별 호출건수, 초당 평균
응답시간
96
97. Report 추가
7. Analysis
Loadrunner Analysis에서 그래프
추가는 "New Graph" 버튼
더블클릭.
Select a graph 프레임에서
그래프를 선택하고 "Open
Graph" 버튼을 클릭하면
그래프가 생성됩니다.
97
108. Merge
7. Analysis
그래프 병합
가상사용자의 그래프와 비교하여
성능 목표를 확인 하면
어플리케이션의 병목여부까지
확인 할 수 있습니다.
가상사용자 그래프를 같이 모기
위해서는 그래프를 합쳐야 합니다.
사용 메뉴로는 Merge Graphs를
클릭하시면 됩니다.
108
112. Auto Correlation
7. Analysis
Loadrunner Analysis의 Auto
Correlate 기능은 수집된 모든
성능 데이터에서 기준이 되는
데이터를 설정하여 이와 비슷한
추이를 보이는 성능 데이터를
자동으로 찾아주는
기능입니다. 100% 정확하지 않고
많은 성능 데이터를 빠르게 찾기
위해서는 유용하게 사용할 수
있을 겁니다.
112
113. Web Diagnostics
7. Analysis
Web Diagnostics 기능은
트랜잭션의 응답시간을 각
컨포넌트와 구간별 응답시간을
확인 할 수 있습니다.
그래프에서 Web Diagnostics
그래프를 추가하시면 됩니다.
113
114. Web Diagnostics
7. Analysis
DNS Resolution Time: DNS 이름을 IP 주소로 확인하는 데
필요한 시간.
Connection Time: 지정된 URL을 서비스하는 웹 서버와
처음으로 연결을 설정하는 데 필요한 시간.
SSL Handshaking Time: 클라이언트 공개 키 전송, 서버
인증서 전송 및 부분 선택적인 기타 단계를 포함하여 SSL
연결에 걸린 시간.
First Buffer: 초기 HTTP 요청(대개 GET) 시간부터 첫 번째
버퍼가 웹 서버로부터 정상적으로 수신되기까지 경과한
시간.
Receive Time(Download Time): 서버로부터 마지막 바
이트를 수신하고 다운로드가 완료되기까지 경과한 시간.
Client Time: 브라우저 판단 시간이나 기타 클라이언트 관
련 지연으로 인해 클라이언트 컴퓨터에 요청이 표시되는
동안 경과한 평균 시간.
Error Time: HTTP 요청이 송신된 시점부터 오류 메시지(HTT
P 오류만 해당)가 반환된 시점까지 경과한 평균 시간.
Web Diagnostics 그래프를 통하여 응답시간이 증가된 원
인을 확인할 수 있고, 어느 부분에서 응답시간이 증가되고
있는지를 확인 할 수 있습니다.
- First Buffer 시간이 증가되면 서버의 처리가 지연될 가능
성이 매우 높습니다. (서버 튜닝 필요)
- Receive 시간이 높게 측정 되었다면 이미지나 페이지의
데이터량이 많아 지연될 가능성이 매무 높습니다. (UI 튜닝
필요.)
- Connection 시간이 높게 측정되었다면 L4나 웹서버에
문제가 있을 가능성이 높습니다. (L4, 웹서버 확인 필요)
114
115. Analysis 분석
7. 결과 분석기법
DNS Time (DNS 이름을 IP 주소로 확인하는 데 필요한 시간.)
일반적인 사용자는 웹 사이트에 접속을 하기 위해서는 도메인 네임을 브라우저에 작성하여 웹 사이트를 접
속하게 됩니다. 이 과정에서 도메인 네임이 IP Address로 변경되는 시간이 DNS Resolution 시간입니다.
http://www.btoclub.co
.kr
211.115.72.227
Web System
DNS Time
DB Servers
Web Servers
App Servers
DNS
115
116. Analysis 분석
7. 결과 분석기법
Connection Time (지정된 URL을 서비스하는 웹 서버와 처음으로 연결을 설정하는데 필요한 시간.)
사용자가 요청한 도메인 네임이 IP Address로 변경이 되었으면 이 IP Address와 해당 Port로 접속을 시도합니다.
이 시간이 서버에 접속하는 Connection 시간입니다.
Connection Time
211.115.72.227 : 80
Web System
DB Servers
Web Servers
App Servers
DNS
116
117. Analysis 분석
7. 결과 분석기법
Server Time (초기 HTTP 요청시간부터 첫 번째 버퍼가 웹 서버로부터 정상적으로 수신되기까지 경과한 시간.)
사용자의 브라우저와 서버와의 연결이 완료 된 이후 사용자는 서버에 필요한 정보는 URL(index.jsp)로 호출을
하게 됩니다. 이 때 호출을 시도하는 시간부터 index.jsp가 컴파일 되고 index.jsp 데이터는 클라이언트로 전송하
는데 이때 클라이언트가 처음으로 받은 데이터까지의 시간을 Server 시간 (First Buffer 시간)이라고 합니다.
Server Time
Index.jsp
Web System
Contents
DB Servers
Web Servers
DNS
Contents
Contents
Contents
Contents
117
App Servers
118. Analysis 분석
7. 결과 분석기법
Receive Time (서버로부터 마지막 바이트를 수신하고 다운로드가 완료되기까지 경과한 시간. )
서버에서의 컴파일된 모든 데이터들이 클라이언트로 전송 되는 시간을 Receive 시간 이라고 합니다.
Receive Time
Contents
Web System
DB Servers
Web Servers
App Servers
DNS
118
120. 성능테스트 절차
적용 프로세스
8. 성능테스트 기법
분석
성능시험 요청자
요청서
검토
N
N
계획서
검토
N
성능시험
요청서
성능시험 관리자
설계
이행
평가
계획서
검토
성능시험
결과확인
Y
성능시험
결과확인
Y
성능시험 테스터
요구사항 및
프로젝트 수행
계획 수립
개발자
대상업무
확인
DBA
DB 정보
확인
시스템관리자
대상시스템
확인
성능시험
목표 수립
이행 절차
수립 계획
스크립트
설계
성능시험
수행
개선점
적용
개선점
적용
개선점
적용
120
성능시험
요약보고서
N
성능시험 Y
목적 달성
성능시험
결과보고서
121. 성능테스트 절차
P1 분석
8. 성능테스트 기법
P2 준비
P3 테스트
P4 보고
A1. 요구 사항 분석
A2. 테스트 계획 수립
A1. 성능 목표 수립
A2. 이행 절차 수립 계획
A3. 스크립트 설계
A1. 이행 준비
A2. 성능시험 실행
A1. 결과 보고
Key Operation
Key Operation
Key Operation
Key Operation
A1. 요구 사항 분석
T1. 요구 사항 수집
T2. 요구 사항 정의
T3. 현행 시스템 설명
A1.성능 목표 수립
T1.현행 성능 치 산정
T2.목표 성능 치 산정
A1.이행 준비
T1.성능시험 시간 계획
T2.시스템인프라 구성점검
T3.성능시험 최종점검
A1. 테스트 분석 결과 보고
A2. 테스트 계획 수립
T1.적용 기술 검토
T2.일정 계획 수립
T3.투입 자원 계획 수립
A2.이행절차 수립 계획
T1.성능 측정 대상 선정
T2.성능 측정 절차 계획
T3.성능 측정 조건 계획
T4.자원 감시 기술 검토
A2.성능시험 이행
T1. 단위성능시험
T2. 통합성능시험
T3. 임계성능시험
T4. 안정성시험
A3.스크립트 설계
T1.시험 성공 기준 설명
T2.시험 데이터 설명
T3.시험 도구 설명
T4.스크립트 작성
121
122. 테스트 준비 기법
8. 성능테스트 기법
성능시험 요청서를 작성함으로써 성능시험 프로젝트가 착수됨.
1. 성능시험 목적 확인
ex) 서비스의 응답시간 가용성 이슈에 대한 성능 점검
- 서비스 최대 수용 가능한 사용자 수 산정
- 현 상황에서의 시스템 점검
- 병목 구간 점검 및 튜닝
- 새롭게 개발된 서비스의 오픈 전 성능 측정
- 시스템 구축 변경에 성능 점검
4. 어플리케이션에 대한 질문
- 개발언어:
- 업무 단위 별 목록:
- 사용자가 주로 사용하는 업무 순위:
- 현재 성능상 이슈가 있음을 인지하고 있는 업무
목록:
- 대략적인 평균응답시간:
- 목표 응답시간:
2.서비스의 일반 정보에 대한 질문
- 서비스의 용도: 서비스의 기획과 설계 목적
- 서비스의 사용자: 서비스의 사용자 분석
5. 시스템 용량에 대한 질문
- 평균 동시사용자 수:
- 성능시험 가능시간:
3. 시스템 환경에 대한 질문
- Architecture 정보:
- Application architecture 정보:
- System architecture 정보:
- Data architecture 정보:
- 성능시험 대상 서버 정보:
- Load Balancing 정책 정보:
122
123. 테스트설계 기법
8. 성능테스트 기법
목표 성능지표
서비스의 성능시험은 요구사항의 목적에 따른 시험을 진행하는 것을 원칙으로 하고, 목적에 따른 성능시험 목표가
설정됨.
목표 설정에 있어서 정확한 근거에 의한 수치화된 목표를 정의할 수 없는 경우 다음과 같은 항목을 성능시험 목표를
설정함.
성능 평가 지표
평가 대상
설명
응답시간
클라이언트
사용자 요청을 처리하기 위해서 소요된 총 시간
TPS
서버
단위 시간당 대상 시스템에서 처리되고 있는 요청 건수
자원 사용률
서버
목표 부하 상황에서의 서버들의 자원 사용률
어플리케이션 신뢰성
서버
성능테스트 중 처리 성공률 (반대로 에러 발생률)
123
124. 테스트설계 기법
8. 성능테스트 기법
시스템이 사용자로부터 요청 받은 작업을 처리하는 일의 양을 통계적으로 분석하는 활동. 즉 시스템의
Workload 분석을 하는 활동임. 성능시험의 요구사항과 Workload 분석을 통한 성능시험 목표가 수립
됨.
Log 분석 필수 항목
1.시간당 호출건수 Peak Time 확인
2.Peak Time 분당 호출건수
3.Peak Time 초당 호출건수
4.10분당 동시사용자 수
5.응답시간 분포도
6.초당 응답시간 호출건수
7.Peak Time 어플리케이션 별 호출건수 대상업무 정의
8.Peak Time 어플리케이션 별 사용량(응답시간 * 실행시간)
대상업무 정의
Log 분석 선택 항목
1.사용자 OS/ Browser 분석
2.HTTP Code 별 호출건수 400, 500 에러 수정
3.어플리케이션 별 응답시간 변화 추이
성능목표 설정을 위한 기본 데이터
1. Peak Time
2. Peak Time 총 호출건수 (TPH)
3. Peak Time 분당 최대 호출건수 (Max TPM)
4. Peak Time 분당 평균 호출건수 (Avg TPM)
5. Peak Time 초당 최대 호출건수 (Max TPS)
6. Peak Time 초당 평균 호출건수 (Avg TPS)
7. Peak Time 최대 동시사용자 (Max Concurrent User)
8. Peak Time 평균 동시사용자 (Avg Concurrent User)
9. Peak Time 최대 호출간격 (Max Request Interval)
10. Peak Time 평균 호출간격 (Avg Request Interval)
결과
1. Peak Time 초당 최대 처리건수: 9.2 TPS
2. Peak Time 최대 동시사용자:300명
3. Peak Time 최대 호출간격, 평균응답시간, Think Time:
32초
124
125. 테스트설계 기법
8. 성능테스트 기법
성능시험의 대상업무 선정 방법
요구사항에 정의 되지 않은 일반적인 상황에의 성능시험이 필요한 경우에는 시스템에서 서비스하는 모든
업무를 대상으로 선정하기에는 무리가 있을 수 있음.
일반적으로는 사용량이 많은 업무, 사용자가 많은 업무, 다른 업무 어플리케이션에 영향을 주는 업무, 업무
특성상 중요한 업무 등을 기준으로 선정함.
일반적인 통합성능시험에서의 로그를 통한
대상업무 선정
통합성능시험의 대상업무는 다음과 같은 우선
순위로 대상업무를 선정하게 됨.
1. 사용량이 많은 페이지
2. 사용자의 접속이 많은 페이지
3. 평균응답시간 높거나, 응답시간 편차가 큰
페이지
4. 크리티컬한 장애가 자주 발생되는 페이지
5. 운영상 중요한 성격을 가진 페이지
대상업무선정 = 사용량비중*50% +
호출건수*50% + a
a는 기타 요구사항에 의해 테스트가 필요한
페이지 (3,4,5번 항목)
125
128. 스크립팅 기법
8. 성능테스트 기법
스크립트를 검증 할 수 있는 Verification 전략
웹 서비스에서 발생하는 에러(Http Code 4xx, 5xx)는 보통의 경우 안내페이지로 리다이렉션 되는
경우나 정확한 컨텐츠가 표시되었는지에 대한 정확히 파악할 수 있는 검증이 필요함.
1. 문자 확인
web_reg_find ("Text=즐거운 하루를",LAST);
web_reg_find ("Text=한국HP",LAST);
2. 이미지로 확인
web_image_check ("BTOFooter","SRC=/b_footLine.gif", LAST);
3. Http Code로 확인
HttpCode = web_get_int_property(HTTP_INFO_RETURN_CODE);
128
129. 스크립팅 기법
8. 성능테스트 기법
Think Time은 동시사용자와 TPS 기준에 의해 Request Interval로 설정해야 함으로 Pacing Time을 적용하여 테스트
해야 함.
[적용방법]
동시사용자 = TPS * Request Interval
Request Interval = 동시사용자 / TPS
129
130. 스크립팅 기법
8. 성능테스트 기법
브라우저 설정 기준 Runtime 세팅 방법
브라우저 캐시를 적용
이전 호출에 이미 받은 이미지는 서버로
요청하지 않음.
페이지가 아닌 모든 요소(Component)를
다운로드 할지 여부
반복에 따른 새로운 세션의 생성 여부
반복에 따른 캐시 삭제 여부
130
131. 산출물작성 기법
8. 성능테스트 기법
성능시험 계획서 작성
1. 성능시험 개요 정의
1.1 성능시험 목적 정의
1.2 일정 계획 정의
1.3 투입자원계획 (인력 및 환경)
1.4 성능시험 범위 설정
3. 성능시험 계획
3.1 성능 목표 수립
3.2 대상업무 정의
3.3 성능시험 절차 계획
3.4 자원감시 계획
2. 성능시험 대상시스템 분석
2.1 대상시스템 성능치 산출
2.2 대상업무 분석 결과 확인
2.3 대상시스템 자원 사용률 분석
2.4 실사용자 응답시간 분석
2.5 시험 환경 구성
2.6 시험환경 서버 사양 확인
2.7 데이터 흐름 분석
2.8 DB Schema / Table 분석
131
133. 산출물작성 기법
8. 성능테스트 기법
트랜잭션은 추후의 재사용 및 응답시간 측정 및 가용성 측정에 있어서 정확한 대상업무의 성능측정이 되었는지는
확인 하기 위한 용도와 성능시험 이후 발생된 이슈에 대해서 보다 효과적으로 처리할 수 있도록 트랜잭션 정의서를
작성하여 스크립트와 함께 관리함.
트랜잭션정의서 내용
1. 스크립트 작성 절차
2. 트랜잭션 정의 구간
3. Verification (검증)
4. 스크립트명
5. 파라미터 처리 내용
6. Think Time
133
134. 산출물작성 기법
8. 성능테스트 기법
성능시험 요약 보고서는 성능시험의 각 차수 별 성능요약 수치와 이슈사항을 관리하게 되며, 각 차수 별 산출물이
필요함.
134
135. 산출물작성 기법
8. 성능테스트 기법
성능시험 최종 보고서는 성능시험 프로젝트의 전반적인 내용이 작성하되, 성능시험 요약, 성능 상세
결과, 이슈 사항, 개선 사항 목표 수립 여부를 통하여 향후 수행 계획을 수립함.
성능시험에 따른 결과 보고서는 다음과 같은 내용이 결과보고서에 포함되도록 합니다.
1. 성능시험 목적
2. 성능시험 방안
3. 성능시험 대상 시스템
4. Workload 분석 결과
5. 목표 성능치 정의
6. 성능시험 대상 업무 목록
7. 성능시험 시나리오
8. 성능시험 결과
135
136. 테스트 준비 기법
8. 성능테스트 기법
Loadrunner 성능테스트 사전 유의사항
1.
Script 작성
- 충분한 Parameter Data DB 에서 Caching 이 일어 나지 않도록 한다
2.
부하 발생기 별 적절한 사용자 분배
- 하나의 부하 발생기 CPU 사용률이 80% 이상을 넘지 않도록 유의
3. Network 대역폭 관리
- 네트워크 검증 테스트를 통하여 네트워크 대역폭을 사전에 확인해야 함.
- NIC Utilization 이 70% 이상 사용하지 않도록 관리
4. Load Balancing
- 테스트 이전 L4의 로드밸런싱 정책에 따른 부하 분산을 확인 해야 함.
- 다양한 IP 대역이 필요하면 IP Spoofing Option 을 활용한다.
136
137. 테스트 준비 기법
8. 성능테스트 기법
Loadrunner 성능시험 중의 테스트가 잘 이루어지고 있는지를 확인함.
1. Load Generator의 자원사용률
- 부하 발생기에서 자원이 고갈되면 정확한 성능시험을 할 수 없음
2. Throughput (Byte Per Second)
- 부하 발생기와 대상시스템간의 네트워크 트래픽 확인. (테스트 이전에 사이즈가 큰 파일을 통하여 테스트를
수행하여야 함)
- 예를 들어 100M 랜 이라면 100/8 = 12.5M Loadrunner의 Throughput 이 12.5MB 이하여야 함
137
138. 테스트 기법
8. 성능테스트 기법
수집된 요구사항을 바탕으로 성능 시험을 위한 요구사항을 성능시험은 요구사항에 따른 성
능시험 방법이 분리됨.
서비스 응답시간 가용성 이슈에 대한 성능 점검
단위시험
최대 수용 가능한 사용자 수 산정
통합시험
현 상황에서의 시스템 점검
임계시험
병목 구간 점검 및 튜닝
안정성시험
새롭게 개발된 서비스의 오픈
시스템 구축 변경에 성능 점검
System Architecture
Application Architecture
Technical Architecture
Server Configuration
138
139. 테스트 기법
8. 성능테스트 기법
Loadrunner 성능시험 중의 테스트가 잘 이루어지고 있는지를 확인함.
3. TPS (Transaction Per Second)
- TPS 변화 추이를 확인 하여 임계성능(Saturation Point)의 발생 여부를 확인함.
4. Error에 따른 스크립트 확인
- 잘못된 스크립트에 의해서 발생된 에러인지를 확인함.
139
141. 분석기법
8. 성능테스트 기법
시작
Web Page
Diagnostics
Average Transaction
Response Time
Summary Report
Transaction per
Second
초당처리
건수 만족?
응답시간
만족?
Y
N
Component
Diagnostics
Y
Download Time
Diagnostics
System Resource
N
에러
발생 ?
N
Time to First Buffer
Diagnostics
Y
끝
Errors per Second
(by Description)
141
142. 분석기법
8. 성능테스트 기법
1. DNS Time 증가되는 경우
DNS 요청을 최적화
2. Connection Time 증가 현상
Keep-Alive 옵션 사용
Keep-Alive timeout 최적화
※ 만약 사용자가 많아서 Connection 이 잘 이루어 지지 않는 경우 이 설정을 5초 정도로 짧게 주는 것도 서버의 리소스를 보다
효율적으로 사용할 수 있음.
Keep-Alive on
평균응답시간: 0.116초
Keep-Alive off
평균응답시간: 0.357초
142
143. 분석기법
8. 성능테스트 기법
3. Receive Time 증가 현상
HTTP 요청 수 줄이기
만료기한 사용 - 캐시
Gzip 사용 - 압축
Component 최소화
4. Server Time 증가 현상
Web Diagnostics 확인
WAS, DB 분석
Diagnostics 사용
SELECT DISTINCT role_name FROM wf_user_roles WHERE
user_name = : ? OR ( user_name = ( SELECT name FROM
wf_local_roles wlr , fnd_user fusr WHERE fusr.person_party_id =
wlr.orig_system_id AND wlr.orig_system = ? AND fusr.user_name
= : ? AND ROWNUM < ? ) ) AND role_name <> user_name
143
