Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

practical perf testing - d2startup

practical perf testing with ngrinder - d2startup

  • Identifiez-vous pour voir les commentaires

practical perf testing - d2startup

  1. 1. Practical Performance Testing 윤준호
  2. 2. WHO AM I nGrinder 프로젝트 리드 윤준호
  3. 3. 3 성능 테스트? 스트레스 테스트 로드 테스트 로드 상황에서 크래시 등의 문제점 확인 로드 상황에서 성능 특성 파악 성능 테스트 정의
  4. 4. 0 500 1000 1500 2000 2500 1 2 5 10 50 100 200 Apache Nginx Nginx-caching 동시사용자 # (Think Time 없을 때) 초당 처리량 로드 테스트 성능 테스트 정의
  5. 5. 부적절한 커넥션 풀? 불충분한 쓰레드 풀? 메모리 릭? 리소스 릭? 비효율적인 코드? 스트레스 테스트 성능 테스트 정의
  6. 6. 성능 테스트 수행 시점 목표 성능 달성 위한 설계 예) Non-Blocking? NoSQL? 캐시? 개별 프레임워크 테스트 중요 성능 키 팩터만 부분적 테스트 실제 성능 확인 및 병목/오류 제거 성능 목표 설정 예산 평가?
  7. 7. 성능 테스트 범위 리소스 (js,css) API DB 미디어 (동영상/음악) 서버 렌더링된 웹페이지 기타 (MsgQueue / Cache) 일반적으로는 제외 주요 테스트 대상 가끔 테스트 초기 선정시 테스트 일반적으로는 제외 가끔 테스트
  8. 8. 서버 용량 산정 Response Time (응답시간)
  9. 9. 서버 용량 산정 Concurrent User (동시 사용자)
  10. 10. 서버 용량 산정 Active User (활성 사용자) <= 서버 쓰레드 또는 프로세스 개수 (Blocking 서버 일 경우) <= DB 커넥션 풀 개수
  11. 11. 서버 용량 산정 Transaction (트랜잭션) • 작업 단위 - 정의하기 나름 • 개별 호출만? 로그인+개별호출? • 어떻게 정의하느냐에 따라 Response Time 도 재정의 필요
  12. 12. 서버 용량 산정 TPS (Transaction Per Second / 초당처리량) • 초당처리량(TPS)= 활성 사용자(Active User) / 평균 응답 시간(Average Response Time) • 초당처리량(TPS)= 동시 사용자(Concurrent User) / 요청 주기(Request Interval) • 활성 사용자(Active User) = TPS * 평균 응답 시간(Average Response Time) • 활성 사용자(Active User) = 동시 사용자(Concurrent User) * 평균 응답 시간(Average Response Time) / 요청 주기 (Request Interval) • 활성 사용자(Active User) = 동시 사용자(Concurrent User) * 평균 응답 시간(Average Response Time) / [ 평균 응답 시간(Average Response Time) + 평균 Think 타임(Average Think Time) ]
  13. 13. 서버 용량 산정 • 활성 사용자 : 96.77 • 3000 * 0.5 / (0.5 + 15) • 동시 사용자 * 평균 응답 시간 / [ 평균 응답 시간 + 평균 Think 타임 ] • 필요 TPS : 193.56 • 50 / 0.5 • 초당처리량(TPS)= 활성 사용자 / 평균 응답 시간 동시 사용자 3000명, 목표 응답 시간 0.5초, Think Time 15초 일 경우
  14. 14. 서버 용량 산정 그런데.. 구식… Cloud 환경에서는 의미가 퇴색 On-Demand / AWS T2 instance / Scaling Group
  15. 15. 서버 용량 산정 일단 만들고 성능을 측정해본 다음 투입 서버 사양 / 개수 결정 이후 비용을 줄이기 위해 서버 최적화
  16. 16. 로드를 주는 방법? 스크립트 방식/폼 채워넣는 방식 ApacheBench? JMeter? Gatling? nGrinder? 테스트는 어떻게?
  17. 17. 무제한 로드 부여 가능 / 대규모 테스트에 적합 컨트롤러 테스트 대상 서버 로드 생성기 부하제어 스크 립트 분산 테스트 테스트는 어떻게?
  18. 18. nGrinder since 2010 nGrinder is NOT Grinder. It’s 3 times bigger with a lot of fixes.
  19. 19. nGrinder 직접 실행방법 [ec2-user ~]$ wget --content-disposition http://downloads.sourceforge.net/project/ngrinder/ngrinder-3.3/ngrinder-controller- 3.3.war?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fngrinder%2Ffiles%2Fngrinder- 3.3%2F&ts=1460820117&use_mirror=tenet [ec2-user ~]$ sudo java -XX:MaxPermSize=200m -jar ngrinder-controller-3.3.war -p 80 & 컨트롤러 컨트롤러 - 1Core, 2GRAM 권장 / 에이전트 - 2Core, 4GRAM 이상 권장 [ec2-user ~]$ wget --content-disposition 링크주소 [ec2-user ~]$ tar xvf 에이전트파일명.tar [ec2-user ~]$ cd ngrinder-agent && run-agent-bg.sh 에이전트 JDK1.7필요 JDK1.8지원  3.4부 터
  20. 20. nGrinder docker 실행방법 [ec2-user ~]$ docker run -d -v ~/.ngrinder:/root/.ngrinder -p 80:80 -p 16001:16001 -p 12000-12009:12000-12009 ngrinder/controller:3.3 컨트롤러 [ec2-user ~]$ docker run -d -e CONTROLLER_ADDR=controller_ip:80 ngrinder/agent:3.3 에이전트
  21. 21. 테스트 진행결과 리포트 테스트 설정스크립트 작성 상세 결과 보기
  22. 22. 내장 SVN 자이썬 그루비 그루비 + 메이븐 스크립팅 - 지원언어
  23. 23. 컨트 롤러 에이전트1 에이전트2 컨트롤러+에이전트 스크 립트 스크 립트
  24. 24. 에이 전트 프로세스1 프로세스2 프로세스+쓰레드 쓰레드 1 쓰레드 2 쓰레드 3 쓰레드 4 쓰레드 1 쓰레드 2 쓰레드 3 쓰레드 4 가 상 유 저 스크 립트 스크 립트
  25. 25. 스크립팅 - 그루비 프로세스당 한번 쓰레드당 한번 지정한 만큼 반복 Request의 메소드가 호출될 때마다 트랜잭션 1증가
  26. 26. 스크립팅 - 실행 순서
  27. 27. 스크립팅 - 자이선 Once per process Once per process Repeating
  28. 28. 스크립팅 - 실행 순서
  29. 29. 그루비 + 메이븐 + 서브버전 + 이클립스/IntelliJ 스크립트 디버깅 / 자동완성 / 의존성 관리 스크립팅 – IDE 지원
  30. 30. 스크립팅 – 트랜잭션 testMyTransaction 메소드 정상 호출시 트랜잭션 1증가
  31. 31. 스크립팅 – 트랜잭션 Gtest test = new Gtest(1, “통계1”) MyTest object = new MyTest(); test.record(object, “sendMessageToGoogle”) class MyTest { public void sendMessageToGoogle() { 구글에 HTTP를 보내고, 결과 검증 } …. } 통계 1을 준비하라 여기까지 왔으면 테스트가 성공한거다. 통계1에 트랜잭션을 하나 올려라
  32. 32. 실패 – Transaction 증가 없음 스크립팅 – 트랜잭션
  33. 33. 스크립팅 – 트랜잭션 성공 – Transaction 1 증가
  34. 34. 테스트 준비시 고려사항 비용 (트래픽/스토리지) 외부 의존성 (블록킹 당할 수 있음) 캐시 효과 (주로 같은 유저 ID에 대한 지속적 호출시) 네트웍 딜레이 포함 여부 (에이전트를 타겟 네트웍과 같은 네트웍에 배치?) Think Time 포함 여부 (제거시 동시사용자=활성사용자)
  35. 35. 테스트 준비시 고려사항 스트레스 테스트 • 주로 장기간 수행 그러나 초기에는 오류때문에 장기간 수행할 수 없을 것 • 개발서버 대상 • 외부 API는 Mock으로 대체 • 캐시 효과 크게 고려하지 않음 • 네트웍 딜레이 제거함 • Think Time 제거함 로드 테스트 • 주로 단기간 수행 • 개발서버+스테이징서버+ 실서버 대상 • 외부 API 그대로 유지 • 캐시 효과 제거 • 네트웍 딜레이 제거는 유동적 • Think Time 제거함
  36. 36. 서버 인터렉션 알아내기 - 웹 크롬 개발자 도구 사용
  37. 37. 서버 인터렉션 알아내기 - 앱 Chales Proxy 사용 Phone ServerChalesProxy
  38. 38. 스크립트 작성하기
  39. 39. 스크립트 작성하기 로그인후 네이버 접근 XXXXXXX
  40. 40. 스크립트 작성하기 – 외부 라이브러리 사용 Jython / Groovy Maven Groovy
  41. 41. 데이터베이스 성능 측정 스크립트 작성하기
  42. 42. 큰 응답 스트림 제어 스크립트 작성하기
  43. 43. 스크립트 작성하기 동시에 여러 가중치 부여한 테스트 실행
  44. 44. 스크립트 작성하기 리소스 읽기 (jython/groovy)
  45. 45. 리소스 읽기 / Groovy Maven 스크립트 작성하기
  46. 46. 스크립트 작성하기 쓰레드 마다 다른 일 시키기
  47. 47. JSON 파싱하기 스크립트 작성하기
  48. 48. XML 파싱하기 스크립트 작성하기
  49. 49. 테스트 실행 Ramp Up
  50. 50. 테스트 실행 Target Host /etc/hosts 조작 Load Balancing까지..
  51. 51. 성능 테스트에서 주로 발견되는 문제 부적절한 Pool 개수 (작은 커넥션 풀 또는 WAS커넥션풀<DB커넥션풀) 락킹 (synchronized 구문) Non-Tread Safe 코드에 의한 비정상 동작 (HashMap, ArrayList) DB 인덱스 설정 오류 / 불필요한 DB 호출 지나친 로깅 또는 부적절 로거 설정 Full GC (메모리 Leak / 리소스 Leak) 단순 로직 오류
  52. 52. 테스트 결과 분석 - Rule of Thumbs 테스트 도구를 의심하지 말것! 문제는 스크립트를 잘못 짰거나 서버가 잘못 동작하는 것임
  53. 53. 테스트 모니터링 ngrinder monitor – CPU/메모리/네트웍 [ec2-user ~]$ wget --content-disposition 링크주소 [ec2-user ~]$ tar xvf 모니터파일명.tar [ec2-user ~]$ cd ngrinder-monitor && run-monitor-bg.sh
  54. 54. 테스트 모니터링 https://github.com/firehol/netdata/wiki/Installation netdata - 단일 인스턴스 상세 모니터링
  55. 55. 테스트 모니터링 pinpont – 대규모 시스템 성능 모니터링 XX XX https://github.com/naver/pinpoint
  56. 56. 사례1 – JVM 메모리 부족 • 부하를 생성하는 타겟으로 커넥션을 맺지 못함 • 서버의 CPU/MEM은 여유가 있는 상황 • 서버측에 CLOSE_WAIT된 소 켓이 존재할 거라 생각했지 만 원인이 아님 • JVM 모니터를 통해 Full GC 발생이 잦고 발생 시점에 TPS가 떨어지는 것을 확인 • JVM 메모리 증가후 증가시 켜 원하는 부하에서 응답을 줄 수 있도록 튜닝
  57. 57. 사례2 – ulimit • 생각보다 성능이 않나오고, vuser 를 증가시키더라도 추가된 vuser 는 접속 오류 발생 • CPU/메모리/네트웍은 놀고 있는 상황. • Ulimit을 늘린후 성능 개선
  58. 58. 감사합니다

×