ݺߣ

ݺߣShare a Scribd company logo

오픈 소스 도구를 활용한 성능 테스트 방법 및 사례

•Download as PPTX, PDF•
•
MinWoo Byeon
MinWoo Byeon

JMeter를 이용한 성능 테스트 사례입니다.

1 of 49
Downloaded 910 times
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례 JMeter를 이용한 성능 테스트 변민우 minwoo@estsoft.com
발표자는? • 변 민 우 (minwoo@estsoft.com) • http://minu.kr • 현재, (주)이스트소프트 • 테스트 자동화 업무 담당 • 테스트 자동화 & 성능 테스트 • C#, Python, AutoIt, JavaScript, … 2 / 49
새로운 프로젝트의 시작 • 새로운 웹 서비스 프로젝트(검색 사이트)의 시작 • 웹 서비스 테스트 경험 無 • 성능 테스트에 대한 고민  • 오픈 소스 성능 테스트 도구의 활용 - JMeter 3 / 49
공짜! 성능 테스트 도구 부하를 발생 할 수 있는 도구를 찾아 보자!
무료 성능 테스트 도구 5 / 49
Grinder • http://grinder.sourceforge.net/ • “The Grinder, a Java Load Testing Framework” • Java Process와 Thread로 Virtual User 생성 • Jython 기반 스크립트 작성 (Java + Python) 6 / 49
nGrinder • http://www.nhnopensource.org/ngrinder • Grinder 사용의 불편함을 해소 • Web Based GUI 통합 (실행/결과/관리) • 스크립트 편집/부하 시나리오 관리 • 테스트 실행 결과 보고서 출력 • 성능 테스트 이력 관리 • … 7 / 49
그 외에도… • www.opensourcetesting.org/performance.php • Allmon, Apache JMeter, benerator, CLIF, ContiPerf, curl-loader, D- ITG, DBMonster, Deluge, Dieseltest, Faban, FunkLoad, FWPTT, Grinder, GrinderStone, Hammerhead2, Hamm erora, httperf, http_load, Iperf, IxoraRMS, j- hawk, Jchav, Jcrawler, loadUI, Lobo, MessAdmin, mston e, Multi- Mechanize, Ntime, OpenSTA, OpenWebLoad, Ostinato , p-unit, PandoraFMS, postal, Pylot, Raw Load Tester, Seagull, Siege, Sipp, SLAMD, Soap- Stone, stress_driver, TestMaker, TPTEST, Tsung, Valgri nd, LoadSim, Web Ploygraph, WebLOAD 8 / 49
어떤 걸로 할까? • Apache JMeter • 최근까지도 꾸준한 Release • 자세한 매뉴얼과 많은 검색 결과 9 / 49
JMeter에 대해 알아보자 JMeter의 특징과 주요 기능
JMeter 소개 • Java로 개발된 오픈 소스 성능(부하) 테스트 도구 • Multi Thread 기반의 부하 발생 도구 • 다양한 서버 지원: HTTP(S), FTP, SOAP, JDBC, SMTP, … • 부하 응답 결과 분석 (통계 및 그래프) • Graphical UI • Console UI  자동화에 유용 11 / 49
JMeter 동작 방식 JMeter Thread 1 Server Sampler Thread 2 (Request) Thread 3 Thread 4 Listener (Response) Thread 5 … Thread N 12 / 49
JMeter Plugins JMeter를 더 아름답게(?) 해줘요!
JMeter Plugins • 뭔가 99% 부족한 기능들  • JMeter Plugins http://code.google.com/p/jmeter-plugins/ • 더욱 정교한 부하 시나리오! • 더욱 다양하고 깔끔한 그래프! 14 / 49
JMeter Plugins – Threads 15 / 49
JMeter Plugins – Listeners • Response Times Over Time 16 / 49
JMeter Plugins – Listeners • Transactions Per Seconds 17 / 49
JMeter Plugins – Listeners • Response Times Distribution 18 / 49
이제 성능 테스트 해요! JMeter! 우리는 이렇게 사용했습니다.
성능 테스트 요청 사항 • 테스트1) 메인 페이지 동시 접속 성능 테스트 “메인 페이지 동시접속 몇 명까지 가능하겠니?” • 테스트2) 검색 페이지(모듈 별) 부하 테스트 “웹 페이지 검색 성능이 200TPS 이상 나와 줘야 하는데…” • 테스트3) 타 검색 사이트 응답시간 비교 “다른 검색 사이트에 비해 평균적으로 우리는 어때?” 20 / 49
동시접속은 몇 명 가능? • “초당 N명이 동시 접속 가능한 지 테스트 해 봐!” • 테스트 시나리오 1) 페이지 내 모든 요청(HTML, CSS, JS, IMG)을 기록해서 2) N개의 스레드를 만들어서 돌리고 3) 요청은 잘 받아 오는지, 서버에 이상은 없는지 확인 하자. 21 / 49
동시접속은 몇 명 가능? 22 / 49
이 테스트 방식의 문제점 • 페이지 내 모든 요청을 여러 스레드에서 발생하는 방식은… • 스레드의 순차적인 요청으로 인해 특정 응답이 느려질 경우 측정 된 전체 결과에 영향을 미침  신뢰성⇩ • 다수 서버 중 어디에서 문제가 발생하는지 파악하기 어려움. • 실제 환경과 동일한 부하를 발생하기 어려움. • 다수의 고성능 서버로 구성된 서비스에 부하를 주기 23 / 49 어려움.
성능을 평가할 다른 접근법? • 정적 파일(PNG, GIF, CSS, JS, …) 응답 시간은 아주 빠름. • 주로 DB 연결이 필요한 요청에서 성능 문제가 발생. • 각 서버는 기능별로 분리되어 있음. • 부하가 있을 때 전체 성능은 가장 느린 응답에 영향을 받음. • 모든 요청들을 잘 쪼개고 나눠서 서버/기능 별로 부하를 발생해서 부분 성능부터 점검 (bottom-up) 24 / 49
메인 페이지 성능 테스트 결과 • Static 서버에서 오랜 시간 부하 발생 할 경우  Fail • 로그인 URL 부하 발생  Fail (10TPS) • 비로그인 상황에서 메인 URL 부하 발생  Pass (300TPS) • 로그인 상황에서 메인 URL 부하 발생  Fail (100TPS) • Request A  Pass (500TPS) • Request B  Fail (Timeout) • Request C  Fail (Connection Refused) 25 / 49 (이 결과는 예제일 뿐 실제 테스트 결과와는 관련이 없습니다.)
검색 결과 페이지 성능은? • “검색 성능은 200TPS 만족해야 해. 잘 되나 테스트 해 줘” • 테스트 시나리오 1) 100만개의 실제 검색어 목록을 가지고 2) 검색 결과 페이지 URL에 검색어 쿼리와 함께 요청. 3) 30TPS부터 시작해서 200TPS 까지 서서히 늘려 보자. 26 / 49
검색 페이지 성능은? 27 / 49
검색 페이지 성능은? 28 / 49
스레드 개수와 TPS의 관계 • 스레드 개수 “N”이 TPS를 의미하지는 않는다. • 스레드는 응답을 받아 온 다음 바로 또 다른 요청을 한다. • 응답 시간이 0.1초일 경우 한 스레드는 초당 10개 요청. • 실제 TPS는 “스레드 개수 / 응답 시간”이 된다. • 스레드 10개, 평균 응답시간이 0.1초일 경우 10 / 0.1s = 100 TPS (초당 100개의 요청이 수행 됨) • TPS는 평균 응답시간에 의존적 29 / 49
스레드 개수와 TPS의 관계 • 평균 응답시간 0.06초 http://naver.com, 스레드 5개 30 / 49
발생 부하를 조절하는 방법 • Constant Throughput Timer • 한 스레드에서 1분 동안 보낼 수 있는 요청 수를 조절. • 스레드 개수로 TPS를 조절할 수 있음. 31 / 49
부하 발생은 잘 될까? (엔진) [JMeter] • Thread & Throughput • [웹 서버] Connections per second [엔진] Requests per second 32 / 49
성능 개선 확인 Before vs. After 33 / 49
타 사이트 평균 응답시간 비교 • “타 사이트와 평균 검색 응답시간을 비교 해 보자” • 테스트 시나리오 1) 검색어 목록 준비 2) 각 검색 사이트 별 HTTP Request 등록 3) 검색어를 차례대로 읽어와서 사이트 별 요청을 보냄. (부하는 필요하지 않기 때문에 스레드 1개) 34 / 49
타 사이트 평균 응답시간 비교 35 / 49
응답시간 비교 결과 36 / 49
타 사이트 평균 응답시간 비교 • JMeter 없이 테스트 하려면?  PROGRAMMING 37 / 49
JMeter 로그 활용 • CSV, XML 형식으로 저장되기 때문에 재가공에 용이. • 모듈 별 단위 성능 테스트 후 응답 분석에 활용. 38 / 49
JMeter의 다른 기능? 잘 쓰면 유용한 JMeter의 기능들
Distributed Testing • 부하 발생 장비의 물리적 한계(CPU, Memory, Network, …) • 2~3Ghz CPU에서 300~600개의 스레드 실행 가능 (테스트 특성에 따라 달라짐) • 더 많은 부하를 발생하기 위해 다수 PC를 사용 40 / 49
Recording Tests • 브라우저에서 발생하는 모든 Request를 JMeter에 기록. • JMeter에서 Proxy Server를 실행. • Browser에서 Proxy Server로 연결 하도록 옵션 설정. 41 / 49
Access Log Sampler • Web Server의 Access Log 파일을 이용하여 실제 서버 트래픽과 유사하게 부하를 발생할 수 있다. 42 / 49
Servers Performance Monitoring 43 / 49
JMeter 요약
JMeter 요약 • JMeter는 부하를 발생 하는 오픈 소스 도구. • 외부 플러그-인을 사용하여 기능 확장 가능. • 단위 성능 테스트 활용에 적합. • 더 많은 부하를 발생하기 위한 분산 테스트 지원. • 부하 장비 및 서버 자원 모니터링. (CPU, MEM, I/O, …) • 프록시 서버를 이용한 레코딩 기능. • 상용 도구 못지 않게 활용 할 수 있음. 45 / 49
JMeter 직접 해볼까요 Demo.
JMeter Demo • DokuWiki의 페이지 뷰 성능을 측정해 보자. • 임의로 1만개의 페이지를 미리 생성. • URL: test.minu.kr/doku.php?id={PAGE_NAME} • 부하는 20TPS ~ 150TPS까지 서서히 증가. 47 / 49
마치며Ħ
오늘의 세미나 끝! • 감사합니다! • 발표자료 만드느라 늦은 밤까지 고생한 저에게 박수를 보냅니다.  • minwoo@estsoft.com 메일 주셔도 됩니다  49 / 49

More Related Content

오픈 소스 도구를 활용한 성능 테스트 방법 및 사례

  • 1. 오픈 소스 도구를 활용한 성능 테스트 방법 및 사례 JMeter를 이용한 성능 테스트 변민우 minwoo@estsoft.com
  • 2. 발표자는? • 변 민 우 (minwoo@estsoft.com) • http://minu.kr • 현재, (주)이스트소프트 • 테스트 자동화 업무 담당 • 테스트 자동화 & 성능 테스트 • C#, Python, AutoIt, JavaScript, … 2 / 49
  • 3. 새로운 프로젝트의 시작 • 새로운 웹 서비스 프로젝트(검색 사이트)의 시작 • 웹 서비스 테스트 경험 無 • 성능 테스트에 대한 고민  • 오픈 소스 성능 테스트 도구의 활용 - JMeter 3 / 49
  • 4. 공짜! 성능 테스트 도구 부하를 발생 할 수 있는 도구를 찾아 보자!
  • 5. 무료 성능 테스트 도구 5 / 49
  • 6. Grinder • http://grinder.sourceforge.net/ • “The Grinder, a Java Load Testing Framework” • Java Process와 Thread로 Virtual User 생성 • Jython 기반 스크립트 작성 (Java + Python) 6 / 49
  • 7. nGrinder • http://www.nhnopensource.org/ngrinder • Grinder 사용의 불편함을 해소 • Web Based GUI 통합 (실행/결과/관리) • 스크립트 편집/부하 시나리오 관리 • 테스트 실행 결과 보고서 출력 • 성능 테스트 이력 관리 • … 7 / 49
  • 8. 그 외에도… • www.opensourcetesting.org/performance.php • Allmon, Apache JMeter, benerator, CLIF, ContiPerf, curl-loader, D- ITG, DBMonster, Deluge, Dieseltest, Faban, FunkLoad, FWPTT, Grinder, GrinderStone, Hammerhead2, Hamm erora, httperf, http_load, Iperf, IxoraRMS, j- hawk, Jchav, Jcrawler, loadUI, Lobo, MessAdmin, mston e, Multi- Mechanize, Ntime, OpenSTA, OpenWebLoad, Ostinato , p-unit, PandoraFMS, postal, Pylot, Raw Load Tester, Seagull, Siege, Sipp, SLAMD, Soap- Stone, stress_driver, TestMaker, TPTEST, Tsung, Valgri nd, LoadSim, Web Ploygraph, WebLOAD 8 / 49
  • 9. 어떤 걸로 할까? • Apache JMeter • 최근까지도 꾸준한 Release • 자세한 매뉴얼과 많은 검색 결과 9 / 49
  • 10. JMeter에 대해 알아보자 JMeter의 특징과 주요 기능
  • 11. JMeter 소개 • Java로 개발된 오픈 소스 성능(부하) 테스트 도구 • Multi Thread 기반의 부하 발생 도구 • 다양한 서버 지원: HTTP(S), FTP, SOAP, JDBC, SMTP, … • 부하 응답 결과 분석 (통계 및 그래프) • Graphical UI • Console UI  자동화에 유용 11 / 49
  • 12. JMeter 동작 방식 JMeter Thread 1 Server Sampler Thread 2 (Request) Thread 3 Thread 4 Listener (Response) Thread 5 … Thread N 12 / 49
  • 13. JMeter Plugins JMeter를 더 아름답게(?) 해줘요!
  • 14. JMeter Plugins • 뭔가 99% 부족한 기능들  • JMeter Plugins http://code.google.com/p/jmeter-plugins/ • 더욱 정교한 부하 시나리오! • 더욱 다양하고 깔끔한 그래프! 14 / 49
  • 15. JMeter Plugins – Threads 15 / 49
  • 16. JMeter Plugins – Listeners • Response Times Over Time 16 / 49
  • 17. JMeter Plugins – Listeners • Transactions Per Seconds 17 / 49
  • 18. JMeter Plugins – Listeners • Response Times Distribution 18 / 49
  • 19. 이제 성능 테스트 해요! JMeter! 우리는 이렇게 사용했습니다.
  • 20. 성능 테스트 요청 사항 • 테스트1) 메인 페이지 동시 접속 성능 테스트 “메인 페이지 동시접속 몇 명까지 가능하겠니?” • 테스트2) 검색 페이지(모듈 별) 부하 테스트 “웹 페이지 검색 성능이 200TPS 이상 나와 줘야 하는데…” • 테스트3) 타 검색 사이트 응답시간 비교 “다른 검색 사이트에 비해 평균적으로 우리는 어때?” 20 / 49
  • 21. 동시접속은 몇 명 가능? • “초당 N명이 동시 접속 가능한 지 테스트 해 봐!” • 테스트 시나리오 1) 페이지 내 모든 요청(HTML, CSS, JS, IMG)을 기록해서 2) N개의 스레드를 만들어서 돌리고 3) 요청은 잘 받아 오는지, 서버에 이상은 없는지 확인 하자. 21 / 49
  • 22. 동시접속은 몇 명 가능? 22 / 49
  • 23. 이 테스트 방식의 문제점 • 페이지 내 모든 요청을 여러 스레드에서 발생하는 방식은… • 스레드의 순차적인 요청으로 인해 특정 응답이 느려질 경우 측정 된 전체 결과에 영향을 미침  신뢰성⇩ • 다수 서버 중 어디에서 문제가 발생하는지 파악하기 어려움. • 실제 환경과 동일한 부하를 발생하기 어려움. • 다수의 고성능 서버로 구성된 서비스에 부하를 주기 23 / 49 어려움.
  • 24. 성능을 평가할 다른 접근법? • 정적 파일(PNG, GIF, CSS, JS, …) 응답 시간은 아주 빠름. • 주로 DB 연결이 필요한 요청에서 성능 문제가 발생. • 각 서버는 기능별로 분리되어 있음. • 부하가 있을 때 전체 성능은 가장 느린 응답에 영향을 받음. • 모든 요청들을 잘 쪼개고 나눠서 서버/기능 별로 부하를 발생해서 부분 성능부터 점검 (bottom-up) 24 / 49
  • 25. 메인 페이지 성능 테스트 결과 • Static 서버에서 오랜 시간 부하 발생 할 경우  Fail • 로그인 URL 부하 발생  Fail (10TPS) • 비로그인 상황에서 메인 URL 부하 발생  Pass (300TPS) • 로그인 상황에서 메인 URL 부하 발생  Fail (100TPS) • Request A  Pass (500TPS) • Request B  Fail (Timeout) • Request C  Fail (Connection Refused) 25 / 49 (이 결과는 예제일 뿐 실제 테스트 결과와는 관련이 없습니다.)
  • 26. 검색 결과 페이지 성능은? • “검색 성능은 200TPS 만족해야 해. 잘 되나 테스트 해 줘” • 테스트 시나리오 1) 100만개의 실제 검색어 목록을 가지고 2) 검색 결과 페이지 URL에 검색어 쿼리와 함께 요청. 3) 30TPS부터 시작해서 200TPS 까지 서서히 늘려 보자. 26 / 49
  • 29. 스레드 개수와 TPS의 관계 • 스레드 개수 “N”이 TPS를 의미하지는 않는다. • 스레드는 응답을 받아 온 다음 바로 또 다른 요청을 한다. • 응답 시간이 0.1초일 경우 한 스레드는 초당 10개 요청. • 실제 TPS는 “스레드 개수 / 응답 시간”이 된다. • 스레드 10개, 평균 응답시간이 0.1초일 경우 10 / 0.1s = 100 TPS (초당 100개의 요청이 수행 됨) • TPS는 평균 응답시간에 의존적 29 / 49
  • 30. 스레드 개수와 TPS의 관계 • 평균 응답시간 0.06초 http://naver.com, 스레드 5개 30 / 49
  • 31. 발생 부하를 조절하는 방법 • Constant Throughput Timer • 한 스레드에서 1분 동안 보낼 수 있는 요청 수를 조절. • 스레드 개수로 TPS를 조절할 수 있음. 31 / 49
  • 32. 부하 발생은 잘 될까? (엔진) [JMeter] • Thread & Throughput • [웹 서버] Connections per second [엔진] Requests per second 32 / 49
  • 33. 성능 개선 확인 Before vs. After 33 / 49
  • 34. 타 사이트 평균 응답시간 비교 • “타 사이트와 평균 검색 응답시간을 비교 해 보자” • 테스트 시나리오 1) 검색어 목록 준비 2) 각 검색 사이트 별 HTTP Request 등록 3) 검색어를 차례대로 읽어와서 사이트 별 요청을 보냄. (부하는 필요하지 않기 때문에 스레드 1개) 34 / 49
  • 35. 타 사이트 평균 응답시간 비교 35 / 49
  • 37. 타 사이트 평균 응답시간 비교 • JMeter 없이 테스트 하려면?  PROGRAMMING 37 / 49
  • 38. JMeter 로그 활용 • CSV, XML 형식으로 저장되기 때문에 재가공에 용이. • 모듈 별 단위 성능 테스트 후 응답 분석에 활용. 38 / 49
  • 39. JMeter의 다른 기능? 잘 쓰면 유용한 JMeter의 기능들
  • 40. Distributed Testing • 부하 발생 장비의 물리적 한계(CPU, Memory, Network, …) • 2~3Ghz CPU에서 300~600개의 스레드 실행 가능 (테스트 특성에 따라 달라짐) • 더 많은 부하를 발생하기 위해 다수 PC를 사용 40 / 49
  • 41. Recording Tests • 브라우저에서 발생하는 모든 Request를 JMeter에 기록. • JMeter에서 Proxy Server를 실행. • Browser에서 Proxy Server로 연결 하도록 옵션 설정. 41 / 49
  • 42. Access Log Sampler • Web Server의 Access Log 파일을 이용하여 실제 서버 트래픽과 유사하게 부하를 발생할 수 있다. 42 / 49
  • 45. JMeter 요약 • JMeter는 부하를 발생 하는 오픈 소스 도구. • 외부 플러그-인을 사용하여 기능 확장 가능. • 단위 성능 테스트 활용에 적합. • 더 많은 부하를 발생하기 위한 분산 테스트 지원. • 부하 장비 및 서버 자원 모니터링. (CPU, MEM, I/O, …) • 프록시 서버를 이용한 레코딩 기능. • 상용 도구 못지 않게 활용 할 수 있음. 45 / 49
  • 47. JMeter Demo • DokuWiki의 페이지 뷰 성능을 측정해 보자. • 임의로 1만개의 페이지를 미리 생성. • URL: test.minu.kr/doku.php?id={PAGE_NAME} • 부하는 20TPS ~ 150TPS까지 서서히 증가. 47 / 49
  • 49. 오늘의 세미나 끝! • 감사합니다! • 발표자료 만드느라 늦은 밤까지 고생한 저에게 박수를 보냅니다.  • minwoo@estsoft.com 메일 주셔도 됩니다  49 / 49