웹기반 시스템의 성능 최적화를 위한 성능 테스트 방안

웹기반 시스템의 성능 최적화를 위한 성능 테스트 방안 박성민 psm@kr.ibm.com

Agenda • Performance Testing • What, Why, When & How? • Rational Performance Tester • Test Creation • Workload Scheduele • Execution & Analysis • Summary

Review : Performance Testing • What is : 시스템의 성능상 문제점을 찾기 위해 부하 발생 도구를 이용하여 실제 사용자의 부하를 모방하여 애플리케이션을 테스트 하는 일련의 과정 • Why do : 시스템 상에서 발생되는 문제로 인해 사용자들이 받아야 하는 서비스를 받지 못할 수 있으므로… RationalPerformance Tester PerformanceTester Agents System Under Test

Cost of Defects vs. Where Found • 프로젝트 후반으로 갈 수록 발견된 결함을 해결하는 데 더 많은 비용 및 노력 소요 • 대부분 성능 테스트는 실환경 도입 직전에 수행하는 문제 Source : Profiles of Level 5 CMMI Organizations by Donald J. Reifer

Type of Tests vs Phases • 개발 초기 ~ 후반 • Load test • 짧은 시간 동안 반복적인 결과를 얻기 용이 • 계속적인 테스트를 통해 일관된 결과를 도출할 수 있으며, 이후 테스트 결과 분석의 기준을 설정하는데 도움 • 개발 후반 • Spike test • 점진적인 부하의 증가를 통해 시스템의 가용성 산출 • Endurance test • 시스템이 수용 가능한 부하를 장기간 동안 발생시켜 시스템의 성능 분석을 통해 시스템의 robustness 검증 • Peak – Rest test • 부하의 반복적인 up & down을 통해 시스템의 여러 수치가 정상을 회복하는지 파악

Common Pitfalls for performance testing • “최대 사용자” 혹은 “최대 커넥션”을 기준으로 한 테스트 계획 • 동시 활성 사용자와 동시 접속자 혼돈 • 워크로드 분석의 중요성 과소 평가 • 테스트 시나리오의 요소들 미반영 • 시간대에 따른 부하에 대한 분석 데이터 미비 • “업계 표준”에 기준을 둔 비현실적인 기대값

Load Profile Creation • 실제 사용자로부터 actor를 정의 • 시스템 수행이 아닌 비즈니스 프로세스로부터 Use Case 추출 • 월 단위로 Use Case에서 부하량 결정 • 피크 기간을 선택하고 부하의 양을 주 – 일 – 시간 단위로 분류 • 실제 시스템의 워크로드와 유사하게 사용될 시나리오들의 부하 비율을 결정

Creating a Performance Test Build Scripts Execute & Analyze Schedule Workload • Script Creation Considerations • 테스트 레코딩, 입력 데이터의 가변화와 서버 응답의 correlation • Scheduling Considerations • 실제 사용자의 워크로드를 가능한 유사하게 emulation • Execute and Analyze Considerations • 응답 결과 분석 및 병목 지점 발견

테스트 레코딩 결과는 웹 페이지 및 이미지 등과 같이 페이지 내에 포함되는 요소들의 리스트가 계층적 구조로 표시됨 다양한 수준의 사용자에게 적합 No-Code Tests

Request GET /PlantsByWebSphere/login.jsp Response Web Browser Request Data Substitution <form method="post" action="/PlantsByWebSphere/servlet/AccountServlet?action=login&updating=false"> <input type="text" name="userid“> HTTP Server POST/PlantsByWebSphere/servlet/AccountServlet?action=login&updating=false userid= username@kr.ibm.com Datapool

Creating a Performance Test사용자 데이터 • 사용자 입력 데이터의 자동 가변화 • 테스트 레코딩 시에 사용자 입력값과 같은 데이터풀 후보를 자동으로 인식하여 에디터에 표시 • CSV 파일 형태의 데이터풀을 import 하거나 RPT 내에서 데이터풀을 생성하여 사용 가능 • 처리된 변수들은 테스트 실행 시에 가상 사용자마다 데이터풀의 값들에 의해 순차적으로 대체되어 실행되므로 사용자마다 고유한 값으로 테스트 User Name: JSmith User Name: CBryson User Name: TJones

Creating a Performance Test서버 동적 데이터 처리 • IBM RPT는 서버에서 발생시키는 동적인 값에 자동으로 대응 • HTTP 헤더에 포함되는 세션 정보 등 서버가 각 사용자에게 고유하게 부여하는 정보 등을 자동으로 저장 • 테스트 수행 시 각 사용자마다 서버가 전달한 고유한 값으로 수행 Session No. 100 Session No. 101 Session No. 102

Portal Parameterization ExampleDynamic URL identification and parameterization • URL for Job Search Page is:http://www.mdes.ms.gov/wps/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnMz0vM0Y_QjzKLN4i3dAHJgFiO-pFQgSB9b31fj_zcVP0A_YLciHJHR0VFAJIEy7w!/delta/base64xml/L0lDU0lKQ1RPN29na21DU1Evb0tvUUFBSVFnakZJQUFRaENFSVFqR0VKemdBIS80SkZpQ28wZWgxaWNvblFWR2hkLXNJYnpRQSEhLzdfMF9DSy80NjY!?PC_7_0_CK_MESCCommand=JobSeeker#null

Performance Tester CaptureAutomatic Data Parameterization Reduces Test Maintenance • RPT가 자동으로 동적인 URL을 변수화하여 이후의 테스트 실행의 성공을 보장 • 동적인 URL이 재생성 되더라도 테스트를 수정할 필요가 없으므로 많은 시간을 절약할 수 있음 접근한 페이지 자동 변수 처리된 동적 URL

Workload Analysis • 워크로드 분석 – 테스트 환경에서 테스트 대상 아이템들이 수행해야 하는 부하 조건을 정의하는 것 • 목적 : 성능적인 리스크를 보다 정확하게 찾기 위해 실제 워크로드와 유사하게 부하를 설계하는 것 • 시스템 컴포넌트, 사용자, 목적과 목표, 이전 결과 및 벤치마크 데이터 등의 통계 자료 수집을 통한 Workload analysis document 작성 • 성능 테스트의 목적 정의 • 워크로드 정의 • Critical business functions • User characteristics • Data access pattern • 측정 기준 선택 : 응답 시간, throughput 등

Other Workload Considerations • Workload interval : 테스트가 수행하는 시간대 • Peak Usage • Normal Day • Test Variables : 테스트 수행 조건 • Various User Load (flat / increasing) • Realistic Variable Data • Different Configurations • User job roles : 사용자의 종류 • Identify groups • Identify percent of total workload • User work profile : 사용자가 수행하는 태스크 • Identify use cases, tasks, and transactions • Determine frequency and order of tasks

Controller SUT Agent Creating a Performance Test워크로드 스케줄 • 정밀한 워크로드 모델 구현 가능 • Selector • Loop, Delay • User Load options • Think Time & etc • 다양한 시나리오의 스케줄 작성 • 코드가 필요없는 비주얼 스케줄 에디터 • Delay 등과 같은 다양한 coordinator 제공 • 적은 메모리와 CPU 사용량 기반의 보다 정확한 대규모 부하 생성 가능 • 테스트 수행 중에 부하 추가 가능

Real Time Monitoring • 테스트 실행 중 및 실행 후에 분석을 위한 다양한 차트 및 테이블 기반의 리포트 제공 • 페이지 응답 시간, 페이지 요소 별 응답 시간, 테스트 성공 실패 여부 로그 제공 등

부하 생성시 시스템 측의 자원 상황을 응답 시간 데이터와 연계해서 표시로 보다 다각적인 분석 Performance & Resource Statistic Report Overlay

Further Analysis • 성능 테스트의 결과 분석 • 페이지, 페이지 요소 등의 응답 시간 • 트랜잭션, throughput 등 • 서버의 자원 사용률 등 시스템 수준의 튜닝 • 애플리케이션에서 발생된 문제 분석? • 실제 운영 시점에서 발생되는 성능 관련 문제?

Performance Problem Identification During Test • 성능 테스트는 병목 구간을 찾아낸다. • 다음 찾아야 하는 문제 : 어디서 왜 병목이 발생하는가? • Root Cause Analysis 기능으로 문제를 밝힐 수 있는 도구를 제공 RPT의 페이지 성능 리포트는 웹 페이지 당 평균 응답 시간을 보여준다. Highest bar = Performance Problem

Response Time Breakdown 응답 시간 데이터는 tier와 트랜잭션 컴포넌트(JDBC, JSP, Servlet 등) 단위로 분할 • Feature: • 페이지 응답 시간을 세부적인 단위로 분할하여 분석이 가능 • Benefit: • 분할된 데이터 분석하여 병목이 발생한 페이지에 대해 가장 문제가 되는(느린) 컴포넌트를 찾을 수 있음.

Deep Diagnostic Data 실행 결과에서 모든 메쏘드에 대한 응답 시간 확인 가능 생성된 UML 시퀀스 다이어그램으로 시간 정보를 포함하는 클래스 관계를 보여줌. • 성능 향상을 위한 테스터와 개발자 간의 협업 근거 자료로 사용 • WebSphere와 Weblogic 서버에서 구동되는 J2EE 애플리케이션에 적용 가능

Performance Problem Identification from IT Operations IT CAM Dashboard Red Box = 성능 문제 • IT 운영자는 가동되고 있는 시스템의 성능 문제를 통보 받음 • 다음 찾아야 하는 문제 : 어디서 어떤 문제가 발생했는가? • Tivoli의 모니터링 도구인 ITCAM과 RPT의 Root Cause Analysis기능이 문제를 밝힐 수 있는 도구를 제공

IBM Tivoli Monitoring Data Import • Use Case: • ITCAM for WebSphere와 같은 Monitoring 도구가 운영 중 발생된 성능상의 문제를 통보 • IT 운영자는 시스템 상에서의 문제 분석 후, 개발 및 QA 담당자에게 장애를 통보하고 RPT에서 관련 데이터를 import 하여 분석하도록 함 • 애플리케이션 부분에서의 문제를 분석할 수 있어 운영팀과 개발팀의 협업 가능

Summarizing performance testing with RPT • Phase에 따른… • 발견된 결함을 해결하는 데 드는 비용 • 성능 테스트의 종류 • Rational Performance Tester • 테스트 생성 시 고려 사항 • Data driven & data correlation • 스케줄 디자인 • 워크로드 분석 • 테스트 수행 및 결과 분석 • 개발 시점 및 운영 시점의 결과 분석

Thank You

웹기반 시스템의 성능 최적화를 위한 성능 테스트 방안