A 시스템 성능 테스트 작업 결과 보고서

1. A 시스템 성능 테스트 작업 결과 보고서 Powered byLoadRunner™

2. 목차 1.성능 시험의 개요 2.성능 평가 기준 3.성능 시험 진행 순서 4.테스트 사이트 구성 현황 5.Workload 모델링 – Weblog 분석 6.Workload 모델링 – Current Workload 산정 8.Workload 모델링 – Target Workload 산정 9.Performance 모델링 –테스트 대상 단위 어플리케이션 선정 10.Performance 모델링 –테스트 대상 혼합 BP 선정 11.Performance 모델링 –Resource Monitoring 항목 선정 12.Performance Test Results –단위 어플리케이션 테스트 결과 13.Performance Test Results –단위 어플리케이션 권고안 14.Performance Test Results –혼합 BP 테스트 결과및 권고안

3. 성능 시험의 개요 시험목적 • A 사이트(EMP 와 Portal)의 오픈 전 시스템 성능 측정 • 시스템에서의 병목 구간 점검 • 시스템에서 최대 수용 가능 동시단말사용자수 산정 시험범위 • 내부 성능 시험은 예상되는 최대 수용 가능 동시단말사용자에 대한 서버의 처리 능력 검증 목적 • 외부 성능 시험은 예상되는 최대 부하에 대한 네트워크 인프라의 처리 능력 검증 목적 App. Server Database Internet Firewall Web Server

4. 성능 평가 기준 가상 사용자를 이용한 부하시험 사용자 증가 시 나타나는 1,2,3차 병목 추적 Infrastructure 병목의 개선을 통한 최적화 실제 운영환경의 성능 검증/개선

5. 성능 시험 진행 순서 P1.Workload Modeling P2.Performance Modeling P3.Scripting & Execution A1) WebLog 분석 A1) 성능 테스트 환경 구축 A1) 시나리오 구현 및 Scripting A2) 시스템 사용 현황 분석 A2) Performance Model 선정 A2) Execution A3) Current Workload 산정 A3) 테스트 대상 BP 최종 선정 A3)장애 분석/수정,실행결과 분석 A4) Target Workload 산정 부하의 당위성 결과의 신뢰성 검증 변경사항 발생 실제 사용자와 유사한 패턴의 부하 생성

6. 테스트 사이트 구성 현황 L4Switch INTERNET ROUTER S/W HUB 외부 FireWall S/W HUB(100M) Internet IDS Server (Web Mail Storage) Web Server(Rep. Srv.) * 2 100 Base 100 Base FireWall Fast Ethernet Network Card Ultra SCSI FWD SCSI-/SE Ultra SCSI FWD SCSI-/SE Disk Storage REP xxx.xxx.xxx.100 MURCURY1 xxx.xxx.xxx.101 MURCURY2 xxx.xxx.xxx.102 Ultra SCSI FWD SCSI 2/SE • DMZ ZONE Dummy Hub(100M) App. Server) * 2 Integration Server(XML) Directory DB Server Fast Ethernet Network Card Fast Ethernet Network Card Fast Ethernet Network Card Fast Ethernet Network Card Ultra SCSI FWD SCSI/SE Ultra SCSI FWD SCSI/SE Ultra SCSI FWD SCSI/SE UltraSCSI FWD SCSI-2/SE

7. Workload Modeling

8. Workload Modeling – Weblog 분석 10월 23일자 웹서버 로그(Murcury1,Murcury2) 현황 분석 시간당 동적 컨텐츠 호출 건수 • Workload Basic Component 선정 • 클라이언트에 의한 동적 컨텐츠 트랜잭션 • Workload Parameter 선정 • 시간당 동적 컨텐츠 호출 건수 (TPH) • 분당 동적 컨텐츠 호출 건수 (TPM) • Peak치 초당 동적 컨텐츠 호출 건수 (TPS) • Peak치 동시 단말사용자수 • 사용자당 평균 호출 간격 분당 동적 컨텐츠 호출 건수 분당 동시단말사용자수 동적 컨텐츠 호출 건수 대비 상위 24개의 트랜잭션

9. 일일 총 호출 건수(동적 컨텐츠) 45,575건 시간당 최대 호출 건수(TPH) 3,460tph Peak시 분당 평균 호출 건수 (TPM) 57tpm (0.95tps) Peak시 분당 최대 호출 건수 (TPM max) 87tpm (1.45tps) 일일 총 방문자 수 2,373명 Peak시(11:xx) 평균 동시 단말 사용자수 32명 Peak시(11:xx) 최대 동시 단말 사용자수 36명 사용자당 평균 호출 간격 32(명)/0.95(tps)=33.7(sec) 사용자당 평균 방문 시간 T/(총방문자수/평균동시단말사용자수) 3600/(196/32)=10분 사용자당 평균 총 호출 건수 총호출건수/총방문자수 45,575/2,373=19건 Workload Modeling – Current Workload 산정 10월 23일자 Current Workload • Peak치(11:xx) 시간당 동적 컨텐츠 호출 건수 – 3,460(TPH) • Peak치(11:xx) 분당 평균 동적 컨텐츠 호출 건수 - 57(TPM) • Peak치(11:xx) 초당 평균 동적 컨텐츠 호출 건수 –0.95(TPS) • Peak치(11:xx) 동시 단말사용자수 –32명 • 사용자당 평균 호출 간격 –33.7(초) 사이트 Workload 분석 지표 사용자당 평균 호출 간격은 평균 응답시간과 평균 Think Time의 합입니다.

10. Workload Modeling – Target Workload 산정 Target Workload 산정 Peak치 동시단말 사용자수 –200 명 • Little’s Law ( 동시단말 사용자수 = TPS * 사용자호출간격) 적용 • TPS = 200(명) / 33.7(초) = 5.93 (TPS) 부하 목표인 200명에 해당되는 TPS 수치 5.93 TPS 200 동시 단말 사용자수는 Active User 와 In-Active User를 포함한 일반적인 의미의 동시 접속자 수 입니다.

11. Performance Modeling

12. Performance Modeling –테스트 대상 단위 어플리케이션 선정 호출 건수를 기준으로 상위 80%를 차지하는 단위 어플리케이션 단위 어플리케이션의 최대 성능을 구하기 위해서 Think Time을 0초로 설정하였습니다.

13. Performance Modeling –혼합 Business Process 선정 사용자의 Business Process에 따른 업무 선정 BP마다 설정된 think Time 30초는 사용자당 평균호출간격 33.7초를 환산하여 적용하였고 실제 테스트시에는 L/R의 “use random percentage of recorded think time”옵션을 사용하여 (50%~150%)의 범위를 가집니다.

14. Performance Modeling – Resource Monitoring 항목 선정 Resource Monitoring 항목

15. Performance Test Results 단위 어플리케이션 테스트

16. Performance Test Results - 단위 어플리케이션 테스트 결과 단위 어플리케이션 성능 모델 도표

17. Performance Test Results - 단위 어플리케이션 테스트 결과 해당 사이트의 최대 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 !

18. Performance Test Results - 단위 어플리케이션 권고안 튜닝 대상 어플리케이션 리스트 • 사이트의 Performance를 개선 시킬 때 튜닝 우선 고려 대상이 되는 어플리케이션 리스트 • 순위별로 Performance에 대한 영향도가 큼 - 예를 들어 매각물건의 경우 1.5TPS를 3.0TPS로 개선 시킬 경우 최대 동시단말사용자수는 305명으로 증가될 수 있음 • DB 서버의 CPU Resource에 대한 영향도가 큰 어플리케이션 리스트

19. Performance Test Results 혼합 BP 테스트

20. Performance Test Results - 혼합 BP 테스트 결과 혼합 BP 테스트 결과 최대 동시단말 사용자 수 : 202 명 최대 TPS : 6.719 (TPS) 혼합 BP 테스트 튜닝 권고안

21. Performance Test Results - 혼합 BP 테스트 결과 TPS (Transaction Per Seconds) 사용자가 187명이상 접속함에 따라 각 트랜잭션의 응답시간이 급속히 증가함을 알 수 있다. 이는 DB 서버의 CPU Resource 가 Saturation됨에 따라 발생하는 현상으로 파악되었다.

22. Performance Test Results - 혼합 BP 테스트 결과 Average Transaction Response Time – Running Vusers 사용자가 187명이상 접속함에 따라 각 트랜잭션의 응답시간이 급속히 증가함을 알 수 있다. 이는 DB 서버의 CPU Resource 가 Saturation됨에 따라 발생하는 현상으로 파악되었다.

23. Performance Test Results - 혼합 BP 테스트 결과 Transaction Response Time Under Load 사용자가 증가함에 따른 응답시간의 증가 추이를 확인해 보면 앞선 단위 어플리케이션 테스트에서 튜닝 대상이었던 공매공고가 낮은 성능 때문에 응답시간의 급등 현상을 보이고 있음을 확인할 수 있다.

24. Performance Test Results - 혼합 BP 테스트 결과 Throughput 해당 사이트의 최대 Throughput은 750,000(bytes per second)로서 이를 bit per second로 환산해 보면 6,000,000(bits per second)이다. 이는 가상 사용자가 접속 할때 마다 이미지들을 매번 다운로드 받는 시나리오의 특성상 높게 측정이 되었지만 현재의 E1라인으로는 턱없이 부족할 것으로 예상된다. 정확한 분석은 차후 사이트 오픈후 BandWidth의 증가 추이를 보고 확인해야 할 것으로 보인다.

25. Performance Test Results - 혼합 BP 테스트 결과 DB Server CPU Resources – Running Vusers 사용자가 187명이상 접속함에 따라 DB 서버의 CPU 사용율이 100% Saturation되었음을 알 수 있다.

26. Performance Test Results - 혼합 BP 테스트 결과 DB Server Run Queue Size – Running Vusers DB 서버의 Run Queue 사이즈가 사용자가 증가함에 따라 급격히 증가함을 알 수 있다.

27. Performance Test Results - 혼합 BP 테스트 결과 WebServer (Mucury1,Murcury2) Load Balancing Status Murcury1과 Murcury2의 80port Connection 비율이 48:52로 연결됨을 확인 Murcury2의 CPU 사용율이 Murcury1에 비해 높게 측정 Load Balancing 기능이 적절히 수행됨을 확인 80 포트 접속자수 CPU 사용율