Performance Testingusing Loadrunner
Upcoming SlideShare
Loading in...5
×
 

Performance Testing using Loadrunner

on

  • 1,706 views

Performance Testing using Loadrunner

Performance Testing using Loadrunner

Statistics

Views

Total Views
1,706
Views on SlideShare
1,706
Embed Views
0

Actions

Likes
1
Downloads
44
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Performance Testingusing Loadrunner Performance Testing using Loadrunner Presentation Transcript

  • Performance Testing using Loadrunner hmfive@naver.com 홍명오
  • 1. Loadrunner 2. 성능 기초 이론 3. Workload Modeling 4. Virtual User Generator 5. Monitoring 6. Controller 7. Analysis 8. 성능테스트 기법
  • Loadrunner 교육 1. Loadrunner 3
  • 1. 로드러너 소개 HP Loadrunner 필요성 성능테스트의 필요성 1. 시스템 안에 있는 성능상의 결함을 발견 2. 제한적인 시스템에서 실사용자와 유사한 시뮬레이션 3. 시스템의 자원 최적화 4. 비즈니스 프로세스에서 수행하여 잠재적인 결함 발견 JSP (Servlet) EJB 업무1 APM HTTP/S 업무2 AP 서버 VB Java PowerBuilder 4 DB 서버 DB 메임프레임
  • HP Loadrunner 소개 제품명: Loadrunner 버전: 11.5.2 제조사: HP 설치 용량: 1GB 전세계 시장 점유율: 71% Loadrunner 제품구성 - Controller - Analysis - Virtual User Generator - Load Generator 1. 로드러너 소개 Empirix Compuware 4% 4% Other 9% Segue 2% Rational 9% RadView 1% HP Loadrunner 71% Worldwide Performance Testing Market Share Distributed Environments, 2008 Source Newport Group, Inc © 2009 제품 설명 모든 환경을 지원하는 업계선두의 성능 테스트 자동화 툴 - 실제 운영 환경과 동일한 수천~수십만 명의 가상유저 (Virtual User)를 생성하여, 엔터프라이즈 시 스템에 트랜잭션을 발생시키고 그 결과를 수집, 분석 • 각각의 가상유저들은 비즈니스 트랜잭션에 대한 응답시간을 측정 • 최소의 하드웨어 Resource를 사용하여 대량의 트랜잭션 발생 - 클라이언트, 네트워크, 서버들로부터 시스템의 현황 및 성능 데이터를 측정하고 수집 5
  • 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
  • HP Loadrunner 구성 1. 로드러너 소개 제품 구성도 가상사용자 작성기 (Virtual User Generator) 자원 모니터링 서버실 RAC 부하 제어기 (Controller) DB WAS Web Server 부하 발생기 (Load Generator) 수행결과 분석 (Analysis) 7
  • HP Loadrunner 구성 1. 로드러너 소개 제품 구성도 제품 모듈 구성 내용(기능요약) 가상 사용자를 생성하기 위해 어플리케이션 비즈니스 프로세스를 레코딩하는 기능 을 수행 Virtual User Generator • 테스트 사용자 시나리오 Record • Transactions • 스크립트의 테스트 데이터 파라메터 설정 작성한 스크립트를 시나리오로 정의하고, Load Generator을 제어하는 모듈 Load Runner Controller • 가상사용자 Test scripts, Vusers 정의 (Vuser 수, Test scripts 등) • 서버 시스템 자원 모니터링 설정 • 부하 발생기 할당 Load Generator Analysis 실제로 스크립트를 실행시키는 모듈 부하테스트 결과를 그래프로 확인하고 병목현상 분석을 도와 주는 모듈 8
  • HP Loadrunner 구성 1. 로드러너 소개 Controller • • • • 테스트하기 위한 시나리오를 관리, 통제하는 프로그램 가상 사용자의 수를 정의하여 부하발생 시나리오 정의함. 테스트 수행 동안 실시간 그래프 형태로 모니터링. 모니터링 통계자료를 데이터베이스 형태로 수합하여 저장함. 테스트 모니터링 시나리오 정의 9
  • HP Loadrunner 구성 1. 로드러너 소개 Controller - Monitoring • 테스트 진행 중 성능 테스트의 대상이 되는 서버의 전체 자원 사용률, 성능관련 데이터를 수집함. • UNIX의 자원 사용율, Application의 성능을 측정하여 실시간으로 제공함. • 모든 데이터 통합 수집 및 제공함. Application 상태 모니터링 자원사용률 모니터링 10
  • HP Loadrunner 구성 1. 로드러너 소개 Virtual User Generator • End User의 업무 로직을 GUI 화면에서 마우스 클릭하면 자동적으로 Test Script가 자동으로 작성되며, 수정 및 변경이 가능하도록 Editor를 제공함. 11
  • HP Loadrunner 구성 1. 로드러너 소개 Analysis • 데이터베이스 형태로 수집 저장된 통계자료 및 그래프들을 이용하여 다양한 분석 그래프 및 데이터를 제공함. • Word, Excel, HTML 형태의 리포트를 제공함. 12
  • HP Loadrunner 구성 1. 로드러너 소개 Analysis • 성능 저하 요인을 빠르게 찾을 수 있도록 Automatic Correlation 그래프, 그래프 Merge 기능 등 다양한 기능 제공 • Word, HTML 형태의 Report 제공 : 웹 브라우저를 통하여 분석 가능 < 응답시간 > < 응답시간 : IIS, MS-SQL Windows Resources > < 응답시간, Hit/Sec, UNIX Resource, Oracle에 대한 상관관계 그래프 > 13
  • HP Loadrunner 주요기능 1. 로드러너 소개 성능테스트 적용 시기 분석 설계 BMT H/W Capacity 산정 성능 & 스트레스 테스트 시스템 (H/W, M/W, DB등) 구현 단위 기능 테스트 테스트 서비스 중 이행 통합 기능 테스트 성능 & 스트레스 테스트 시스템 Configuration 변경 및 Upgrade, 업무 추가 등에 성능 & 스트레스 테스트  성능 감시 및 모니터링 (모니터링 / 경보 / 식별 / 진단) 기능 테스트 (단위 / 통합) 스트레스 테스트 시스템 (H/W, M/W, DB등) 성능 테스트 시스템 (혹은 프로젝트) 감리 시 혹은 검수 시에도 필요!!! • • • 14 • 서비스 응답시간 가용성 이슈에 대한 성능 점검 • 현 상황에서의 시스템 점검 • 시스템 구축 변경에 성능 점검 새롭게 개발된 서비스의 오픈 최대 수용 가능한 사용자 수 산정 현 상황에서의 시스템 점검
  • 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 메임프레임
  • 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
  • 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
  • HP Loadrunner 라이선스 1. 로드러너 소개 라이선스 정책 • • • Protocol List Permanent : 기간 제한 없이 영구적으로 사용 Term : 기간 동안 사용 VUD : (Virtual user Days) 24시간만 사용. 라이선스 단위 • 프로토콜 별 가상사용자 단위 • 모니터링 요소 예> VUD : WEB 1000명. Term : WEB 100명 (8월 17일 ~ 9월 17일) 18
  • Performance Testing 2. 성능 기초 이론 19
  • 성능시험 2. 성능기초 성능시험 정의 실제 시스템이 가동되는 상황에서 일어날 수 있는 여러 가지 조건을 분석하여, 분석된 조건에 최대한 부합되도록 시스템과의 가상 거래를 일으켜 그때의 시스템의 상태를 보는 행위 컨트롤러 가상 사용자 (수백 ~ 수만명) 웹서버 Internet/ WAN App. Server 데이터 베이스 1) 성능 측정 : 성능 관점의 성능시험을 수행하여 시스템이 운영 전에 적정한 성능을 내는 지 확인 2) 결함 검출 : 성능시험을 수행하여 시스템 운영 상태에서 나타날 수 있는 문제를 사전에 확인 3) 병목 제거(튜닝) : 검출된 소프트웨어 결함에 대해 적절한 조치 4) 용량 검증/산정 : 운영 시스템의 용량이 Peak 시에 업무를 처리할 수 있는지를 확인 20
  • Transaction 2. 성능기초 Transaction: 성능테스트의 응답시간 측정의 업무 단위 영화선택 영화정보 영화선택 공연예매 아트홀소개 공영정보 공연예매 21
  • 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
  • Think Time 2. 성능기초 Think Time: 사용자 요청간의 대기시간 Request Interval : Response Time + Think Time Request Interval Response Time Think Time 사용자1 사용자2 사용자3 사용자4 시간 23
  • Concurrent User 2. 성능기초 Concurrent User: 동시 사용자 : 해당 시스템을 사용하기 위해 PC앞에 앉아 있는 사용자  Active User(Clients) 와 InActive User (Clients) 로 구성됨 Named User: 해당 시스템에 접속이 가능한 사용자 동시사용자 3명 사용자1 사용자2 사용자3 사용자4 사용자5 10분 시간 10분 24
  • 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
  • 2. 성능기초 TPS TPS ( Transaction per Second ) : 초당 처리 건수 : 사용자의 요청(Request)에 대한 처리 - TPM (Transaction Per Minute) - TPH (Transaction Per Hour) ( 1TPH = 60TPM = 3,600TPS ) TPS TPS 응답시간 사용자 26
  • 2. 성능기초 TPS Concurrent User = TPS * Request Interval 2 TPS * 10 초 = 20 명 20명 Server 1초 Container1 Container2 시간 2 TPS 27
  • 2. 성능기초 TPS Concurrent User = TPS * Request Interval TPS = Concurrent User / Request Interval 5 TPS = 5 명 / 1 초 1초 사용자1 사용자2 사용자3 사용자4 사용자5 시간 28
  • 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
  • Saturation Point 2. 성능기초 Saturation Point: TPS가 더 이상 증가되지 않는 시점: 포화 지점 Saturation Point TPS TPS 응답시간 최대 허용 동시 사용자 사용자 30 Saturation Point(포화 지점) 이후부터는 병목현상으로 인하여 TPS가 더 이상 증가 하지 않고 수평을 유지하게 되고 응답시간은 기하급수적으로 증가하게 됩니다. Saturation Point(포화 지점) 이후부터는 동시 사용자가 증가하더라도 성능이 더 이상 개선되지 않기 때문에 이때 당시의 동시사용자를 최대 허용 동시 사용자라고 표현합니다.
  • 단위성능시험 2. 성능기초 단계별 부하생성 방안 - 성능시험의 대상이 되는 개개의 업무의 최대성능을 산출 - 단위 업무별 목표 성능에 대한 부하를 5초당 1명씩 증가하여 최대 사용자까지 증가함. - 업무별 튜닝 개별 Application 별 튜닝 포인트 도출 및 가용성 검증 사용자 1000명 Ramp-UP 단계 시간 온라인 측정구간 단위 성능시험 성능시험의 대상이 되는 개개 업무의 최대 성능을 산출하기 위한 성능시험. 일반적으로 통합 시험을 위한 업무 어플리케이션 튜닝 과정과 동시에 진행됨. 31
  • 통합성능시험 2. 성능기초 단계별 부하생성 방안 - 성능시험의 대상업무를 업무가중치와 부하 시나리오를 이용해 실제 시스템이 가동되는 상황을 재현 - 모든 업무를 동시에 부하를 발생하여 1시간 동안 유지함. - 10분 동안의 응답시간, 가용성, TPS 검증. 사용자 Duration 단계 (10분) 1000명 Ramp-UP 단계 시간 온라인 측정구간 통합 성능시험 성능시험의 대상업무를 업무 가중치와 부하 시나리오를 이용해 실제 시스템이 가동되는 상황을 재현하는 성능시험. 이를 통해 목표 성능의 도달 여부를 판단할 수 있음. 32
  • 임계성능시험 2. 성능기초 단계별 부하생성 방안 - 성능시험 대상 시스템이 발휘 할 수 있는 최대 성능을 측정 - 모든 업무를 통합성능시험 1배 이상의 부하를 발생하여 1시간 동안 유지함. - 1시간 동안의 응답시간, 가용성, TPS 검증. - 용량산정 사용자 사용자 1000명 Duration 단계 (10분) 2000명 Ramp-UP 단계 Ramp-UP 단계 통합성능시험 시간 온라인 측정구간 시간 온라인 측정구간 33
  • 안정성성능시험 2. 성능기초 단계별 부하생성 방안 - 시스템이 오랫동안 거래를 발생 시켰을 때의 시스템 상황을 점검하기 위한 성능시험 - 모든 업무를 동시에 부하를 발생하여 24시간 동안 유지함. - 가용성, 자원 검증(Leak) 사용자 Duration 단계 (24시간) 1000명 Ramp-UP 단계 시간 온라인 측정구간 34
  • 가용성시험 2. 성능기초 단계별 부하생성 방안 - 모든 업무를 동시에 부하를 발생하고, 가용성의 영향에 따른 서비스 영향을 확인 - 가용성저하 시간, 응답시간, TPS 사용자 Duration 단계 1000명 Ramp-UP 단계 시간 온라인 측정구간 35
  • Loadrunner 교육 3. Workload Modeling 36
  • Workload Modeling 이란 3.Workload Modeling Workload Modeling은 시스템의 성능관리에 있어서 가장 어려운 부분 중 하나가 시스템이 사용자로부터 요청 받은 작업을 처리하는 일의 양을 통계적으로 분석하는 활동이며, 테스트 대상 시스템의 부하량을 분석하는 과정 을 Workload 분석이라 이야기 함. 성능테스트의 일반적인 목적 현재의 시스템 혹은 어플리케이션이 최대로 수용 가능한 동시단말사용자수가 몇 명인지, 혹은 목표로 정한 성능이 도출되지 않을 때 병목지점이 어딘지를 밝히고 목표성능을 획득하기 위해 무엇을 시정해야 하는지를 찾아내기 위 함. 성능테스트 과정에서 매우 중요한 부분은 목표성능을 설정하고 그러한 목표성능을 확인/측정하기 위해 향후 시스 템 운영 중에 실제로 발생할 접속사용자의 호출패턴이 어떠하냐를 분석/추정하는 과정이 반드시 필요하고, 이를 근간으로 점진적 부하를 발생시켜야 의미 있는 성능테스트 결과를 도출할 수 있습니다. 그렇지 않을 경우 성능테 스트가 자칫 스트레스테스트로 끝남. 성능시험을 진행 하기 전에 진행 순서에 맞게 정확한 분석과 세밀한 설계가 이루어 졌을 때 대상 시스템의 목표 성 능 치를 만족하기에 어려움이 없을 것으로 판단됨. Workload 분석 기본 요소 • 동시사용자 • TPS • 호출간격 • 단위업무별 호출비율(건수) 37
  • 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
  • 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
  • Peak Time 분석 3.Workload Modeling Access Log를 바탕으로 Peak Time 동안 가장 많이 호출된 업무를 바탕으로 정렬하여 사용량과 호출건수와 비 율을 산출함. 페이지 호출건수 호출건수비중 합 누적치 /Hompy/HompyWin/Home/Viw_MainTopFrame.asp 28263 8.19% 13.75% 13.75% /Hompy/HompyWin/index.asp 24353 7.05% 11.24% 24.98% /Hompy/HompyWin/Visitor/Lst_VisitorMain.asp 20431 5.92% 8.68% 33.67% /Hompy/HompyWin/Home/Viw_MainBottomFrame.asp 33174 9.61% 9.50% 43.16% 5789 1.68% 5.67% 48.84% /Hompy/HompyWin/Note/Lst_NoteMenu.asp 13633 3.95% 5.68% 54.52% /Hompy/HompyWin/Note/Lst_Note.asp 31258 9.05% 6.54% 61.06% /Hompy/HompyWin/Home/Inc_GameLevel.asp 35713 10.34% 5.73% 66.79% /Hompy/HompyWin/Note/Viw_Note.asp 17104 4.95% 3.78% 70.57% /hompy/Bgm/HompyWin/inc_BgmHompyWinExe.asp 23841 6.91% 4.08% 74.65% /Hompy/HompyWin/Visitor/Lst_VisitorTop.asp 16858 4.88% 3.23% 77.87% /Hompy/HompyWin/profile/Pop_LstNewVisit.asp 3715 1.08% 1.75% 79.62% /Hompy/HompyWin/Visitor/Exe_visit.asp 6527 1.89% 1.36% 80.98% /Hompy/HompyWin/Profile/Viw_ProfileTop.asp 5779 1.67% 1.27% 82.26% /Hompy/HompyWin/Profile/Inc_MasterQA.asp 5704 1.65% 1.10% 83.35% /Hompy/HompyWin/Profile/Exe_DelVisit.asp 5288 1.53% 0.96% 84.31% 452 0.13% 0.55% 84.86% 4392 1.27% 0.82% 85.68% /Hompy/HompyWin/Profile/Viw_ProfileMain.asp /Hompy/HompyWin/Manage/myFrnd/myFriend.asp /hompy/hompywin/Note/Lst_Note.asp 40
  • 시험데이터 처리 활용 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
  • Loadrunner 교육 4. Virtual User Generator (VuGen) 42
  • VuGen 기본 4. VuGen 실행: 시작 > 프로그램 > Loadrunner > Applications > Virtual User Generator 실행 43
  • VuGen 기본 4. VuGen 초기 화면에는 새로운 스크립트 생성 버튼과 기존 스크립트 열기 버튼이 존재합니다. 지금은 생성된 스크립트가 존재하지 않으니, 새로운 스크립트를 만들도록 하겠습니다. 44
  • 프로토콜 선택 4. VuGen 새로운 스크립트를 생성하기 위해서는 프로토콜을 선택을 해야 합니다. 프로토콜 선택은 클라이언트가 서버에 접속하기 위해서 필요한 프로토콜로 서버와 클라이언트의 통신과정을 레코딩 하기 위해서 정확한 프로토콜이 선택 되어야 합니다. 이번에는 일반적으로 가장 많이 사용되는 HTTP 프로토콜을 선택하여 생성하도록 하겠습니다. 45
  • VuGen Toolbar 4. VuGen 기본적으로 VuGen 스크립트는 다음과 같은 특성을 가지고 있습니다. Init, Action, End 입니다. 46
  • Action 4. VuGen 5. Action 추가적으로 더 생성을 할 수 있지만, 기본적으로 2가지를 제공하고 있습니다. 이 기본적인 3가지의 기능은 다음 그림과 같이 수행합니다. 스크립트가 수행이 되면 Init를 1번 수행하고, Action은 스크립트 Run-Time 옵션에 설정된 값대로 반복해서 수행이 됩니다. 그리고 Action의 반복이 완료되면 End를 수행하여 스크립트의 동작이 완료됩니다. 47
  • 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
  • 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들은 기본으로 호출됨.)
  • 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
  • Recording 4. VuGen Start Record 버튼 클릭 후 URL address 및 기타 설정하고 OK를 클릭 51
  • Recording 4. VuGen 브라우저가 URL Address에 입력된 내용과 함께 실행되며, VuGen 레코딩 설정 팝업이 함께 수행됨 52
  • Transaction 정의 4. VuGen 레코딩에 필요한 모든 액션을 브라우저에 클릭, 입력함. 자동으로 레코딩이 이루어짐. 트랜잭션 정의 Start Transaction 버튼 클릭. (브라우저에서 정의된 대상업무의 액션 수행) 트랜잭션 정의 End Transaction 버튼 클릭. 53
  • Script 4. VuGen 레코딩과정은 모든 작업들이 자동으로 처리되기 때문에 간편하게 레코딩 작업을 할 수가 있습니다. Generation Log는 레코딩 당시의 처리했던 데이터를 보관함 Regeneration 실행을 통하여 레코딩 했던 처음 상태로 복원이 가능함 54
  • Script Run 4. VuGen 스크립트 수행은 스크립트 Run 버튼을 클릭하면 레코딩된 내용이 그대로 수행됩니다. 55
  • Script Run-time Option 4. VuGen 스크립트 작성이 완료된 이후 스크립트를 보다 실제 사용자와 비슷한 액션을 취하게 하거나, 스크립트에 문제가 있을 경우 디버깅 작업을 쉽게 하기 위해서는 필요한 작업이 RunTime Setting 작업입니다. "F4" 단축키를 입력하면 보다 빠르게 Run-time Setting 창을 실행할 수 있습니다. 56
  • Script Run-time Option 4. VuGen 스크립트의 Http Code Error 제거 이미지나 JS, CSS 등의 Non-HTML 파일들은 404에러가 발생하여도 Warning만으로 로그에 표시됨. 다음과 같은 옵션 조절로 Error를 확인 할 수 있음. 57
  • 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
  • Script Run-time Option 4. VuGen 스크립트 창에서 (Run-Time Setti ng 창 종료후) 에서 오른쪽 버튼을 클릭하여 Create New Action 선택 합니다. 이름을 적당히 정의하면 아래와 같이 Action 밑에 Action2가 추가 됩니다. 59
  • 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
  • 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
  • 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
  • Script Run-time Option 4. VuGen additional attributes 는 스크립트에서 사용할 수 있는 변수를 정의하여 스크립트에 사용합니다. attibutes에 변수명과 값을 정의하면 스크립트에서 설정된 변수의 값이 Run-Time setting에 의해 변경됩니다. 이 변수를 스크립트 수정을 run-time setting만으로 쉽고 빠르게 하기 위해서 사용됩니다. strUsertype = lr_get_attrib_string("usertype"); 63
  • 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
  • Script Run-time Option 4. VuGen Network speed - Use maxinum bandwidth : Generator가 설정된 네트워크를 그대로 모두 사용함. - Use bandwidth : 옵션 설정에 따라 네트워크를 제한함. - Use custom bandwidth : 사용자 정의에 의한 네트워크를 제한함 65
  • Script Run-time Option 4. VuGen 브라우저 설정 기준 Runtime 세팅방법 1. 페이지를 방문할 때마다 : 브라우저 캐시 시뮬레이트를 선택, 페이지를 방문할 때마다 저장된 페이지의 새 버전 확인 사용, 2. Internet Explorer를 시작할 때마다 : 브라우저 캐시 시뮬레이트만 선택, 자동 브라우저 캐시 시뮬레이트만 선택 3. 사용 안 함: 브라우저 캐시 시뮬레이트를 선택 download Non-HTML resource 는 1,2,3의 경우 모두 사용합니다. 66
  • 4. VuGen Verification 문자 방식 이미지 방식 에러메세지 방식 74행 74행 Runtime Log 67 참고 Verification 전략 한 페이지 5글자이상 표시 되지 않아야 함 계속 변경되는 글자는 피해야 함 페이지에 대한 검증을 할 수 있는 글자여야 함
  • 4. VuGen Parameter 이렇게 작성된 스크립트는 구글 홈페이지에서 접속하여 "Loadrunner"를 검색하는 작업을 반복할 것 입니다. 그런데 저희가 하는 성능시험의 대부분은 동일한 검색어로 성능 시험을 진행하는 경우는 거의 없을 겁니다. 많은 사용자가 다양한 검색어도 다양한 결과를 확인 하듯이 Loadrunner 스크립트도 다양한 결과가 가능하도록 설정할 필요가 있습니다. 이 방법이 수동파라미터를 처리하는 방법입니다. 68
  • 4. VuGen Parameter 여러가지 다양한 검색어를 준비합니다. (Text 형태가 가장 좋을 것 같습니다.) 3. 스크립트에서 Text 파일을 연결합니다. Vuser메뉴 --> Parameter List(Ctrl+L) 클릭 --> New 클릭 --> Parameter 이름 정의 --> 파일 찾기 69
  • 4. VuGen Parameter Parameter type을 File로 선택하고 File을 선택합니다. 70
  • 4. VuGen Parameter 스크립트 상에서 정의한 파라미터를 변수 처리합니다. 71
  • 4. VuGen Correlation 메일 삭제나 메일 보기의 성능 시험을 진행 할 때 메일을 삭제를 반복하여 테스트를 하여야 하는데, 1번 메일을 삭제하게 되면 1번 메일이 없기 때문에 2번 메일을 삭제하고, 다음 반복에서 3번, 4번 … 테스트가 끝날 때까지 반복을 해야 합니다. 이 생기는 문제는 그때 그때 이 번호를 확인해서 삭제할 메일 번호를 서버에 전송해야지만 원활한 테스트가 이루어 질 겁니다. 이때 필요한 것이 자동 파라미터 처리 방법입니다. 72
  • 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가지 방법이 존재함.
  • Loadrunner 교육 5. Monitoring 74
  • Monitoring 5. Monitoring 모니터링 설정을 기본적은 Windows와 UNIX를 설정할 수 있고, Web Server, Web Application server, Database, ERP/CRM 등으로 나주어져 있습니다. 75
  • Monitoring 5. Monitoring Windows 설정 - Windows NT / Windows 2000 에서 Monitoring을 하려면 Server의 Administrator권한의 계정으로 Server에 Login하여야 합니다.(탐색창에서 로그인, 혹은 검색창에서 컴퓨터 검색을 통한 로그인) 1. Windows Resources 를 더블 클릭하거나 드래그앤 드롭으로 모니터링창에 생성하면 됩니다. 76
  • Monitoring 5. Monitoring 2. 모니터링창에서 오른쪽 마우스를 클릭하여 Add Measurements 를 클릭합니다. 3. Windows resources 창으로 "Add" 버튼을 클릭하고, add machine 창의 Name에 모니터링 대상 서버의 아이피 주소나 호스트 네임을 입력하면 됩니다. 77
  • Monitoring 5. Monitoring 4. 모니터링 대상서버의 입력이 완료 되었으면, Resource Measurements에 "Add" 버튼을 클릭하고 Windows Resources 창에서 Object, Counter, Instances 를 선택하고 "Add" 버튼을 클릭하면 모니터링 설정이 완료됩니다. Windows 모니터링 설정은 Windows Performance Counters와 동일합니다. 78
  • Monitoring 5. Monitoring 79
  • Monitoring 5. Monitoring 성능시험 대상이 되는 시스템의 구성요소를 정확히 파악하고 예상 병목 지점을 찾아 낼 수 있는 방안을 마련해야 하며, 각 구간별로 모니터링 설정을 통하여 서버 별 자원사용률을 감시함. - 운영체제 - 웹 서버 - 어플리케이션 서버 - 데이터베이스 80
  • Loadrunner 교육 6. Controller 81
  • Scenario 6. Controller Run Mode 1. Real-world scenario  실제 사용자와 유사한 패턴을 생성할 수 있음 2. Basic scenario  메뉴얼한 가상사용자 패턴을 생성함 82
  • Scenario 6. Controller - 가상사용자: 25명 - 트랜잭션: 6개 - 모니터링 설정: WEB, WAS, DB - Load Generator: 2대 - Ramp Up: 10초마다 1명씩 증가 - Duration: 10분 동안 유지 - Ramp Down:5초에 2명씩 중지 83
  • Scenario 6. Controller Result 세팅 Loadrunner 에서 발생하는 모든 이벤트와 데이터를 저장하는 폴더를 설정합니다 84
  • 6. Controller Running Ramp up 가상사용자가 부하발생기에 스크립트를 배포하고 init을 수행하는 단계 85
  • 6. Controller Running Run 가상사용자 스크립트의 Action 부분을 반복하여 수행하는 단계 86
  • 6. Controller Running Ramp Down 사용자가 모든 수행을 끝내고 테스트를 종료하는 단계 87
  • 3. 성능시험 방법론 Running Loadrunner 가상사용자 부하 패턴 Ramp Up Running Ramp Down 88
  • Controller 6. Controller Running User: 가상사용자의 상태별 수치 89
  • Controller 6. Controller - Trans Response Time: 각 트랜잭션별 응답시간(sec) 트랜잭션별 응답시간은 Max, Min, Avg, Std, Last의 수치를 보여줍니다. Max: 테스트중 트랜잭션의 가장 수치가 큰 응답시간. Min: 테스트중 트랜잭션의 가장 수치가 작은 응답시간. Avg: 테스트 동안의 트랜잭션의 평균 응답시간. Std: 테스트의 모든 트랜잭션 응답시간의 표준편차 Last: 테스트중의 가장 마지막으로 처리된 트랜잭션의 응답시간. 90
  • Controller 6. Controller Tran/Sec (Passed) : 성공한 트랜잭션별 초당 처리건수 (TPS) 각 트랜잭션별 초당 처리건수 입니다. 이 수치는 Workload 분석에서 설정한 개별 트랜잭션의 목표 TPS와 비교해야 되는 중요한 수치입니다. 91
  • Controller 6. Controller 사용자 그래프와 TPS 그래프를 합하여 한 그래프에서 동시에 확인이 가능함. TPS의 목표 달성여부나 병목여부를 확인 하기 위해서는 가상사용자의 증가 추이와 비교하여 한계점이 발생했는지 여부를 확인하게 됩니다. 이 때 Total Trans/sec만 보는 것 보다는 가상사용자의 그래프와 통합하여 확인하는 것이 보다 효율적입니다. 92
  • Controller 6. Controller 상세한 에러 메시지창에는 에러메세지, 발생건수, 발생한 가상사용자수, 스크립트 수, 발생한 Generator 수 등이 표시됩니다. 발생건수를 한번 더 클릭하게 되면 시간대별 에러 내용과 스크립트의 에러 라인까지 확인 가능합니다. 보통 Failed Transaction보다 Error 건수가 많은 경우가 많습니다. 이유는 한 트랜잭션에서 여러 개의 에러가 발생하는 경우가 많기 때문입니다. 93
  • Controller 6. Controller 스크립트를 로그를 확인하게 되면 스크립트 문제인지 대상시스템의 문제 구체적인 원인을 파악할 수 있습니다. 94
  • Loadrunner 교육 7. Analysis 95
  • Report 7. Analysis Analysis Summary는 성능시험 데이터의 요약리포트로 보시면 됩니다. 다음과 같은 내용이 포함 되어 있습니다. 테스트 수행시간 시나리오명 성능시험중 최대 사용자 (Max running vusers) 성능시험에 사용된 총 데이터량(Throughput), 평균 데이터량(초당 바이트량) 총 Hits 수 (HTTP Requests), 평균 초당 Hits 수 트랜잭션별 응답시간(최소, 평균, 최대, 표준편차, 90%), 성공건수, 실패건수, Stop건수 HTTP 코드별 호출건수, 초당 평균 응답시간 96
  • Report 추가 7. Analysis Loadrunner Analysis에서 그래프 추가는 "New Graph" 버튼 더블클릭. Select a graph 프레임에서 그래프를 선택하고 "Open Graph" 버튼을 클릭하면 그래프가 생성됩니다. 97
  • Analysis Report 7. Analysis Summary Report 98
  • Analysis Report 7. Analysis Total Transaction per Second 99
  • Analysis Report 7. Analysis Errors per Second (by Description) 100
  • Analysis Report 7. Analysis Average Transaction Response Time 응답시간 101
  • Analysis Report 7. 결과 분석기법 Web Page Diagnostics 102
  • Analysis Report 7. 결과 분석기법 Page Component Diagnostics 103
  • Analysis Report 7. Analysis Average Transaction Response Time 104
  • Analysis Report 7. Analysis Page Download Time Diagnostics 105
  • Analysis Report 7. Analysis Time to First Buffer Diagnostics 106
  • Granularity 7. Analysis Granularity 값을 높게 설정하면 그래프의 간격이 늘어납니다. 107
  • Merge 7. Analysis 그래프 병합 가상사용자의 그래프와 비교하여 성능 목표를 확인 하면 어플리케이션의 병목여부까지 확인 할 수 있습니다. 가상사용자 그래프를 같이 모기 위해서는 그래프를 합쳐야 합니다. 사용 메뉴로는 Merge Graphs를 클릭하시면 됩니다. 108
  • Merge 7. Analysis 109
  • Filter 7. Analysis Report 그래프에서 필요한 부분만을 추려낼 때 Filter 기능을 사용하면 됩니다. 오른쪽 마우스를 클릭하고 Set Filter를 선택합니다. 110
  • Filter 7. Analysis Filter의 여러가지 규칙중에 하나를 선택하고 Filtering할 데이터를 입력하면 됩니다. 111
  • Auto Correlation 7. Analysis Loadrunner Analysis의 Auto Correlate 기능은 수집된 모든 성능 데이터에서 기준이 되는 데이터를 설정하여 이와 비슷한 추이를 보이는 성능 데이터를 자동으로 찾아주는 기능입니다. 100% 정확하지 않고 많은 성능 데이터를 빠르게 찾기 위해서는 유용하게 사용할 수 있을 겁니다. 112
  • Web Diagnostics 7. Analysis Web Diagnostics 기능은 트랜잭션의 응답시간을 각 컨포넌트와 구간별 응답시간을 확인 할 수 있습니다. 그래프에서 Web Diagnostics 그래프를 추가하시면 됩니다. 113
  • 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
  • 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
  • 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
  • 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
  • Analysis 분석 7. 결과 분석기법 Receive Time (서버로부터 마지막 바이트를 수신하고 다운로드가 완료되기까지 경과한 시간. ) 서버에서의 컴파일된 모든 데이터들이 클라이언트로 전송 되는 시간을 Receive 시간 이라고 합니다. Receive Time Contents Web System DB Servers Web Servers App Servers DNS 118
  • Loadrunner 교육 8. 성능테스트 기법 119
  • 성능테스트 절차 적용 프로세스 8. 성능테스트 기법 분석 성능시험 요청자 요청서 검토 N N 계획서 검토 N 성능시험 요청서 성능시험 관리자 설계 이행 평가 계획서 검토 성능시험 결과확인 Y 성능시험 결과확인 Y 성능시험 테스터 요구사항 및 프로젝트 수행 계획 수립 개발자 대상업무 확인 DBA DB 정보 확인 시스템관리자 대상시스템 확인 성능시험 목표 수립 이행 절차 수립 계획 스크립트 설계 성능시험 수행 개선점 적용 개선점 적용 개선점 적용 120 성능시험 요약보고서 N 성능시험 Y 목적 달성 성능시험 결과보고서
  • 성능테스트 절차 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
  • 테스트 준비 기법 8. 성능테스트 기법 성능시험 요청서를 작성함으로써 성능시험 프로젝트가 착수됨. 1. 성능시험 목적 확인 ex) 서비스의 응답시간 가용성 이슈에 대한 성능 점검 - 서비스 최대 수용 가능한 사용자 수 산정 - 현 상황에서의 시스템 점검 - 병목 구간 점검 및 튜닝 - 새롭게 개발된 서비스의 오픈 전 성능 측정 - 시스템 구축 변경에 성능 점검 4. 어플리케이션에 대한 질문 - 개발언어: - 업무 단위 별 목록: - 사용자가 주로 사용하는 업무 순위: - 현재 성능상 이슈가 있음을 인지하고 있는 업무 목록: - 대략적인 평균응답시간: - 목표 응답시간: 2.서비스의 일반 정보에 대한 질문 - 서비스의 용도: 서비스의 기획과 설계 목적 - 서비스의 사용자: 서비스의 사용자 분석 5. 시스템 용량에 대한 질문 - 평균 동시사용자 수: - 성능시험 가능시간: 3. 시스템 환경에 대한 질문 - Architecture 정보: - Application architecture 정보: - System architecture 정보: - Data architecture 정보: - 성능시험 대상 서버 정보: - Load Balancing 정책 정보: 122
  • 테스트설계 기법 8. 성능테스트 기법 목표 성능지표 서비스의 성능시험은 요구사항의 목적에 따른 시험을 진행하는 것을 원칙으로 하고, 목적에 따른 성능시험 목표가 설정됨. 목표 설정에 있어서 정확한 근거에 의한 수치화된 목표를 정의할 수 없는 경우 다음과 같은 항목을 성능시험 목표를 설정함. 성능 평가 지표 평가 대상 설명 응답시간 클라이언트 사용자 요청을 처리하기 위해서 소요된 총 시간 TPS 서버 단위 시간당 대상 시스템에서 처리되고 있는 요청 건수 자원 사용률 서버 목표 부하 상황에서의 서버들의 자원 사용률 어플리케이션 신뢰성 서버 성능테스트 중 처리 성공률 (반대로 에러 발생률) 123
  • 테스트설계 기법 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
  • 테스트설계 기법 8. 성능테스트 기법 성능시험의 대상업무 선정 방법 요구사항에 정의 되지 않은 일반적인 상황에의 성능시험이 필요한 경우에는 시스템에서 서비스하는 모든 업무를 대상으로 선정하기에는 무리가 있을 수 있음. 일반적으로는 사용량이 많은 업무, 사용자가 많은 업무, 다른 업무 어플리케이션에 영향을 주는 업무, 업무 특성상 중요한 업무 등을 기준으로 선정함. 일반적인 통합성능시험에서의 로그를 통한 대상업무 선정 통합성능시험의 대상업무는 다음과 같은 우선 순위로 대상업무를 선정하게 됨. 1. 사용량이 많은 페이지 2. 사용자의 접속이 많은 페이지 3. 평균응답시간 높거나, 응답시간 편차가 큰 페이지 4. 크리티컬한 장애가 자주 발생되는 페이지 5. 운영상 중요한 성격을 가진 페이지 대상업무선정 = 사용량비중*50% + 호출건수*50% + a a는 기타 요구사항에 의해 테스트가 필요한 페이지 (3,4,5번 항목) 125
  • 테스트설계 기법 8. 성능테스트 기법 Web 환경하의 대상업무 선정 예 URL 호출건수 업무비율 누적치 비고 /ekp/kms/usr.list.jsp 630 40.00% 40% 지식마당 > 지식나눔터 /ekp/kms/usr.read.jsp 269 17.08% 57% 지식마당 > 지식조회 /group/svc/bbs/usr.list.jsp 165 10.48% 68% 지식마당 > Cop > 게시판 조회 /ekp/kt/epPopup.jsp 132 8.38% 76% KATE > 팝업 /group/svc/bbs/usr.read.jsp 91 5.78% 82% 지식마당 > Cop > 게시판 상세보기 /ekp/kms/rfrn.read.jsp 84 5.33% 87% 지식마당 > 스페셜지식 POPUP 조회화면 /group/cop/menu/usr.intro.jsp 79 5.02% 92% 커뮤니티 > 나의 커뮤니티 /ekp/cr/sort.list.jsp 21 1.33% 93% 지식마당 > 사규 > 게시판조회 /group/svc/bbs/usr.allList.jsp 17 1.08% 94% 지식마당 > Cop > ROOT 클릭 /ekp/cr/cr.list.jsp 14 0.89% 95% 지식마당 > 사규 /group/svc/bbs/usr.write.jsp 14 0.89% 96% 지식마당 > Cop > ROOT 클릭 > 글쓰기 /group/study/bbs/usr.list.jsp 13 0.83% 97% 지식마당 > 스터디그룹 > 게시판 조회 /ekp/kms/own.list.jsp 12 0.76% 98% 지식마당 > 나의 등록지식 /ekp/cr/item.list.jsp 12 0.76% 99% 지식마당 > 사규 > 게시판 상세조회 /ekp/qna/usr.list.jsp 11 0.70% 99% 지식마당 > 알려주세요 팝업 /ekp/cr/index.jsp 11 0.70% 126 100% 지식마당 > 사규 클릭
  • 테스트설계 기법 8. 성능테스트 기법 선정된 대상업무에 대해서 Loadrunner Controller 에서 다음과 같이 설정함. 동적 컨텐츠 호출건수 업무비율 누적치 비고 /eo/OWA/Email/readEmail.asp 1346 11.90% 30% 메일 > 메일읽기 /ezf/ezDiagram/ezkuflow.asp 1182 10.45% 40% 결재 /ezf/Lst.asp /ezf/ezMhtl.asp 961 889 8.50% 7.86% 49% 결재 > 문서대장 57% 결재 > 문서보기 /EZBGeneral/EzBrdList.asp 815 7.21% 64% 게시 > 전사게시판 > 게시물 리스트 /mail.asp /ezapr_main.asp 646 305 5.71% 2.70% 70% 메일 > 받은편지함 72% 결재 > 전자결재조회 /EARD/EzBrd_Chk.asp 275 2.43% 75% 게시판 > 알림마당 /ezf/ezCoiner/ezntainer.asp 269 2.38% 77% 결재 > 전자결재 /EZAD/EzBrd_Show/Erd_ShwList.asp 258 2.28% 79% 결재 > 공람게시판 /download.asp /Ezd/indexd.asp /Eeails.asp 220 172 140 1.95% 1.52% 1.24% 80% 게시 > 게시판 첨부파일 다운 80% 게시 > 게시판 사이트맵 80% 메일 > 메일 리스트 /PIMS/Schedule/Scheduleday.asp 134 1.19% 80% 일정 > 오늘일정 /PIMS/Task/Taskday.asp 118 1.04% 80% 일정 > 작업일정 /eof/OWA/Email/remote/interrattach.asp 113 1.00% 89% 메일 > 삭제 /ezf/ezContainer/ezSearch3.asp /ezf/ezDraft/upload.asp /ezf/createnewdoc.asp /ezrep/box/ezReportmain.asp /ezf/ank.asp 111 103 79 74 64 0.98% 0.91% 0.70% 0.65% 0.57% 90% 91% 91% 92% 92% 127 결재 > 통제함 > 검색 결재 > 파일 업로드 결재 > 새로운 문서 결재 > 보고서 결재 > 부서수신함 blank
  • 스크립팅 기법 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
  • 스크립팅 기법 8. 성능테스트 기법 Think Time은 동시사용자와 TPS 기준에 의해 Request Interval로 설정해야 함으로 Pacing Time을 적용하여 테스트 해야 함. [적용방법] 동시사용자 = TPS * Request Interval Request Interval = 동시사용자 / TPS 129
  • 스크립팅 기법 8. 성능테스트 기법 브라우저 설정 기준 Runtime 세팅 방법 브라우저 캐시를 적용  이전 호출에 이미 받은 이미지는 서버로 요청하지 않음. 페이지가 아닌 모든 요소(Component)를 다운로드 할지 여부 반복에 따른 새로운 세션의 생성 여부 반복에 따른 캐시 삭제 여부 130
  • 산출물작성 기법 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
  • 산출물작성 기법 8. 성능테스트 기법 132
  • 산출물작성 기법 8. 성능테스트 기법 트랜잭션은 추후의 재사용 및 응답시간 측정 및 가용성 측정에 있어서 정확한 대상업무의 성능측정이 되었는지는 확인 하기 위한 용도와 성능시험 이후 발생된 이슈에 대해서 보다 효과적으로 처리할 수 있도록 트랜잭션 정의서를 작성하여 스크립트와 함께 관리함. 트랜잭션정의서 내용 1. 스크립트 작성 절차 2. 트랜잭션 정의 구간 3. Verification (검증) 4. 스크립트명 5. 파라미터 처리 내용 6. Think Time 133
  • 산출물작성 기법 8. 성능테스트 기법 성능시험 요약 보고서는 성능시험의 각 차수 별 성능요약 수치와 이슈사항을 관리하게 되며, 각 차수 별 산출물이 필요함. 134
  • 산출물작성 기법 8. 성능테스트 기법 성능시험 최종 보고서는 성능시험 프로젝트의 전반적인 내용이 작성하되, 성능시험 요약, 성능 상세 결과, 이슈 사항, 개선 사항 목표 수립 여부를 통하여 향후 수행 계획을 수립함. 성능시험에 따른 결과 보고서는 다음과 같은 내용이 결과보고서에 포함되도록 합니다. 1. 성능시험 목적 2. 성능시험 방안 3. 성능시험 대상 시스템 4. Workload 분석 결과 5. 목표 성능치 정의 6. 성능시험 대상 업무 목록 7. 성능시험 시나리오 8. 성능시험 결과 135
  • 테스트 준비 기법 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
  • 테스트 준비 기법 8. 성능테스트 기법 Loadrunner 성능시험 중의 테스트가 잘 이루어지고 있는지를 확인함. 1. Load Generator의 자원사용률 - 부하 발생기에서 자원이 고갈되면 정확한 성능시험을 할 수 없음 2. Throughput (Byte Per Second) - 부하 발생기와 대상시스템간의 네트워크 트래픽 확인. (테스트 이전에 사이즈가 큰 파일을 통하여 테스트를 수행하여야 함) - 예를 들어 100M 랜 이라면 100/8 = 12.5M Loadrunner의 Throughput 이 12.5MB 이하여야 함 137
  • 테스트 기법 8. 성능테스트 기법 수집된 요구사항을 바탕으로 성능 시험을 위한 요구사항을 성능시험은 요구사항에 따른 성 능시험 방법이 분리됨. 서비스 응답시간 가용성 이슈에 대한 성능 점검 단위시험 최대 수용 가능한 사용자 수 산정 통합시험 현 상황에서의 시스템 점검 임계시험 병목 구간 점검 및 튜닝 안정성시험 새롭게 개발된 서비스의 오픈 시스템 구축 변경에 성능 점검 System Architecture Application Architecture Technical Architecture Server Configuration 138
  • 테스트 기법 8. 성능테스트 기법 Loadrunner 성능시험 중의 테스트가 잘 이루어지고 있는지를 확인함. 3. TPS (Transaction Per Second) - TPS 변화 추이를 확인 하여 임계성능(Saturation Point)의 발생 여부를 확인함. 4. Error에 따른 스크립트 확인 - 잘못된 스크립트에 의해서 발생된 에러인지를 확인함. 139
  • 테스트기법 8. 성능테스트 기법 응답시간 구간 필터 응답시간 140
  • 분석기법 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
  • 분석기법 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
  • 분석기법 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