practical perf testing - d2startup

Practical Performance Testing
윤준호

WHO AM I
nGrinder 프로젝트 리드
윤준호

3
성능 테스트?
스트레스 테스트 로드 테스트
로드 상황에서
크래시 등의 문제점 확인
로드 상황에서
성능 특성 파악
성능 테스트 정의

0
500
1000
1500
2000
2500
1 2 5 10 50 100 200
Apache
Nginx
Nginx-caching
동시사용자 #
(Think Time 없을 때)
초당
처리량
로드 테스트

부적절한 커넥션 풀?
불충분한 쓰레드 풀?
메모리 릭?
리소스 릭?
비효율적인 코드?
스트레스 테스트

성능 테스트 수행 시점
목표 성능 달성 위한 설계
예) Non-Blocking? NoSQL? 캐시?
개별 프레임워크 테스트
중요 성능 키 팩터만
부분적 테스트
실제 성능 확인
및
병목/오류 제거
성능 목표 설정
예산 평가?

성능 테스트 범위
리소스
(js,css)
API
DB
미디어
(동영상/음악)
서버 렌더링된
웹페이지 기타
(MsgQueue
/
Cache)
일반적으로는 제외
주요 테스트 대상
가끔 테스트
초기 선정시 테스트
일반적으로는 제외
가끔 테스트

서버 용량 산정
Response Time
(응답시간)

Concurrent User
(동시 사용자)

Active User
(활성 사용자)
<= 서버 쓰레드 또는 프로세스 개수
(Blocking 서버 일 경우)
<= DB 커넥션 풀 개수

Transaction
(트랜잭션)
• 작업 단위 - 정의하기 나름
• 개별 호출만? 로그인+개별호출?
• 어떻게 정의하느냐에 따라
Response Time 도 재정의 필요

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) ]

• 활성 사용자 : 96.77
• 3000 * 0.5 / (0.5 + 15)
• 동시 사용자 * 평균 응답 시간 / [ 평균 응답 시간 + 평균 Think 타임 ]
• 필요 TPS : 193.56
• 50 / 0.5
• 초당처리량(TPS)= 활성 사용자 / 평균 응답 시간
동시 사용자 3000명, 목표 응답 시간 0.5초,
Think Time 15초 일 경우

그런데.. 구식…
Cloud 환경에서는 의미가 퇴색
On-Demand / AWS T2 instance / Scaling Group

일단 만들고
성능을 측정해본 다음
투입 서버 사양 / 개수 결정
이후 비용을 줄이기 위해 서버 최적화

로드를 주는 방법?
스크립트 방식/폼 채워넣는 방식
ApacheBench? JMeter?
Gatling? nGrinder?
테스트는 어떻게?

무제한 로드 부여 가능 / 대규모 테스트에 적합
컨트롤러 테스트 대상 서버
로드 생성기
부하제어
스크
립트
분산 테스트
테스트는 어떻게?

nGrinder since 2010
nGrinder is NOT Grinder. It’s 3 times bigger with a lot of fixes.

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부
터

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
에이전트

테스트 진행결과 리포트
테스트 설정스크립트 작성
상세 결과 보기

내장 SVN
자이썬 그루비
그루비
+
메이븐
스크립팅 - 지원언어

컨트
롤러
에이전트1
에이전트2
컨트롤러+에이전트
스크
립트
스크
립트

에이
전트
프로세스1
프로세스2
프로세스+쓰레드
쓰레드 1
쓰레드 2
쓰레드 3
쓰레드 4
쓰레드 1
쓰레드 2
쓰레드 3
쓰레드 4
가
상
유
저
스크
립트
스크
립트

스크립팅 - 그루비
프로세스당 한번
쓰레드당 한번
지정한 만큼 반복
Request의 메소드가 호출될 때마다
트랜잭션 1증가

스크립팅 - 자이선
Once per process
Once per process
Repeating

그루비 + 메이븐 + 서브버전 + 이클립스/IntelliJ
스크립트 디버깅 / 자동완성 / 의존성 관리
스크립팅 – IDE 지원

스크립팅 – 트랜잭션
testMyTransaction 메소드 정상 호출시
트랜잭션 1증가

Gtest test = new Gtest(1, “통계1”)
MyTest object = new MyTest();
test.record(object, “sendMessageToGoogle”)
class MyTest {
public void sendMessageToGoogle() {
구글에 HTTP를 보내고, 결과 검증
}
….
}
통계 1을 준비하라
여기까지 왔으면 테스트가 성공한거다. 통계1에 트랜잭션을 하나 올려라

실패 – Transaction 증가 없음

성공 – Transaction 1 증가

테스트 준비시 고려사항
비용
(트래픽/스토리지)
외부 의존성
(블록킹 당할 수 있음)
캐시 효과
(주로 같은 유저 ID에 대한 지속적 호출시)
네트웍 딜레이 포함 여부
(에이전트를 타겟 네트웍과 같은 네트웍에 배치?)
Think Time 포함 여부
(제거시 동시사용자=활성사용자)

테스트 준비시 고려사항
스트레스 테스트
• 주로 장기간 수행
그러나 초기에는 오류때문에
장기간 수행할 수 없을 것
• 개발서버 대상
• 외부 API는 Mock으로 대체
• 캐시 효과 크게 고려하지 않음
• 네트웍 딜레이 제거함
• Think Time 제거함
로드 테스트
• 주로 단기간 수행
• 개발서버+스테이징서버+
실서버 대상
• 외부 API 그대로 유지
• 캐시 효과 제거
• 네트웍 딜레이 제거는 유동적
• Think Time 제거함

서버 인터렉션 알아내기 - 웹
크롬 개발자 도구 사용

서버 인터렉션 알아내기 - 앱
Chales Proxy 사용
Phone ServerChalesProxy

스크립트 작성하기
로그인후 네이버 접근
XXXXXXX

스크립트 작성하기 – 외부 라이브러리 사용
Jython / Groovy
Maven Groovy

데이터베이스 성능 측정

큰 응답 스트림 제어

동시에 여러 가중치 부여한 테스트 실행

리소스 읽기 (jython/groovy)

리소스 읽기 / Groovy Maven

쓰레드 마다 다른 일 시키기

JSON 파싱하기

XML 파싱하기

테스트 실행
Target Host
/etc/hosts 조작
Load Balancing까지..

성능 테스트에서 주로 발견되는 문제
부적절한 Pool 개수
(작은 커넥션 풀 또는 WAS커넥션풀<DB커넥션풀)
락킹
(synchronized 구문)
Non-Tread Safe 코드에 의한 비정상 동작
(HashMap, ArrayList)
DB 인덱스 설정 오류 / 불필요한 DB 호출
지나친 로깅 또는 부적절 로거 설정
Full GC
(메모리 Leak / 리소스 Leak)
단순 로직 오류

테스트 결과 분석 - Rule of Thumbs
테스트 도구를 의심하지 말것!
문제는 스크립트를 잘못 짰거나
서버가 잘못 동작하는 것임

테스트 모니터링
ngrinder monitor – CPU/메모리/네트웍
[ec2-user ~]$ wget --content-disposition 링크주소
[ec2-user ~]$ tar xvf 모니터파일명.tar
[ec2-user ~]$ cd ngrinder-monitor && run-monitor-bg.sh

https://github.com/firehol/netdata/wiki/Installation
netdata - 단일 인스턴스 상세 모니터링

pinpont – 대규모 시스템 성능 모니터링
XX XX
https://github.com/naver/pinpoint

사례1 – JVM 메모리 부족
• 부하를 생성하는 타겟으로
커넥션을 맺지 못함
• 서버의 CPU/MEM은 여유가
있는 상황
• 서버측에 CLOSE_WAIT된 소
켓이 존재할 거라 생각했지
만 원인이 아님
• JVM 모니터를 통해 Full GC
발생이 잦고 발생 시점에
TPS가 떨어지는 것을 확인
• JVM 메모리 증가후 증가시
켜 원하는 부하에서 응답을
줄 수 있도록 튜닝

사례2 – ulimit
• 생각보다 성능이 않나오고,
vuser 를 증가시키더라도
추가된 vuser 는
접속 오류 발생
• CPU/메모리/네트웍은
놀고 있는 상황.
• Ulimit을 늘린후 성능 개선

practical perf testing - d2startup

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (13)

Similar to practical perf testing - d2startup

Similar to practical perf testing - d2startup (20)

practical perf testing - d2startup