성능테스트 프로세스

성능테스트란?

시스템의 목표성능(응답시간, 동시접속자 수)을 정의하고, 이를 개선하기 위해 구조를 반복적으로 개선하는 작업

 

용어정의

1. TPS = Active User 수 / 평균응답 시간

2. Peak Time

• 서버가 순간적으로 가장 부하를 많이 받는 순간을 정의 한다.
• 일반적인 업무 시스템의 경우, 출근 9시~9시30분 사이가 가장 부하가 높다. 
• 이 때 Peak (최고 정점)을 찍는 순간의 동시 사용자 수와 기준 응답 시간을 목표로 성능 목표를 정의 하는 것이 일반적이다.

 

성능테스트 프로세스

단계1) 성능 목표 수립

목표수립 대상

• 시스템 총 사용자수
• 목표 응답시간
• 동시접속자 수
• 시스템 부하패턴 (ex) 컨텐츠 사용 시간과 사용 후 로그아웃하는데 까지의 사용자 체류시간, 특정시간 대의 부하발생)
• 목표 TPS 

단계2) 모델정의(=시나리오 정의)

1. 시나리오 정의

ex) 사진을 저장하는 시나리오가 있다고 하면, 이 서비스의 주요 사용자 시나리오는 아래와 같다.

• 로그인
• 사진 리스트
• 사진 업로드
• 사진 보기
• 사진 다운로드
• 로드 아웃

2. 시나리오 실행비율 정의

• 사용자가 로그인 한후, 리스트 보기를 10번, 업로드를 2번, 보기를 5번, 그리고 다운로드를 1번 한후에 로그 아웃 한경우
• 성능 모델 : 로그인의 비율 5%, 리스트 보기 50%, 업로드 10%, 보기 25%, 로그아웃 5%

3. 측정기준

• 목표 TPS : 1000tps
• 복합 시나리오 수행 시, 1000 TPS가 나와 함.
• 각 개별 시나리오 수행 시, 비율별 TPS 산정.
• ex) 로그인의 경우 1000TPS의 5%로 이므로 50TPS 기준을 목표.

 

단계3) 테스트환경셋팅

• 서버환경 선정
• 테스트 데이터 셋팅
• 테스트 수행 script 작성

 

단계4) 테스트 수행 및 모니터링

1. application 관점

[모니터링대상]

• 응답시간
• TPS

2. 미들웨어 관점

대부분의 성능 문제는 실제 애플리케이션 로직이 수행되는 Tomcat과 같은 application server와 데이타 베이스단에서 많이 발생

[모니터링 대상]

application 서버

• thread 수 : 서버용량초과 시 Idle thread수가 떨어지게 됨.
• Queue 길이 : Idle Thread가 0 이 되면 request message가 앞단의 queue에 저장됨.
• >> 위 두고래 병목상태 판단할수있음.

DB 서버

• slow query : query 수행내용 분석 후 Index를 걸어 튜닝 함.

3.Infra 관점

성능을 내기 위해 용량이 충분한지, 하드웨어 구간에서 병목이 생기는지, 병목구간에대한 해결하기 위함.

[모니터링 대상]

- cpu 

보통 70 ~ 80%으로 유지. 20 ~30%의 여유를 남기는것이 좋음. 이유는 CPU 가 100%가 되는 순간에는 이미 애플리케이션이 CPU 부족으로 제대로 작동을 하지 못하는 경우가 많기 때문에, 항상 여유를 남겨 놓고 성능 목표를 정의

- memory

Peak Time시에 memory가 얼마나 사용되는지가 중요.

Java Application의 경우 특성상, 전체 JVM 프로세스가 사용할 메모리량을 미리 정해놓기 때문에, 부하 테스트 중에도 메모리 사용량 자체는 크게 변화하지 않는다. 다만 자주 놓치는 점이 swapping status 인데, Unix/Linux는 시스템의 특성상 물리 메모리 이상의 메모리를 제공하기 위해서 virtual memory 라는 개념을 사용하고 swapping space라는 디스크 공간에 자주 사용하지 않는 메모리의 내용을 dump해서 저장한 후 다시 사용할때 memory에 loading 하는 방식을 사용한다. 그런데 이 메모리의 내용을 디스크에 저장 및 로드 하는 과정 (swapping이라고 함)이 실제 disk io를 발생 시키기 때문에, 실제 메모리 access 성능이 매우 급격하게 떨어진다. 그래서 시스템에서 system에서 swapping이 발생하면 시스템의 성능이 장애 수준으로 매우 급격하게 떨어진다.

부하 테스트 중이나, 운영 중에 swapping이 발생하게 되면 전체 메모리 사용량을 줄이도록 튜닝을 하거나, 반대로 물리 메모리를 늘리는 증설 과정이 필요하다.

- disk io

[모니터링 대상]

• 파일을 저장 API
• 로그저장하는 모듈
• 데이터베이스

병목발생 시 해결방안

• 디스크를 SSD로 변경
• 버퍼가크거나 RPM이 높은 디스크로 변경
• 인터페이스를 SATA에서 SAS나 SSD와 같은 높은 IO를 제공하는 디스크 인터페이스로 변경
• 애플리케이션 차원에서는 데이타 베이스 앞에 memcache와 같은 캐싱을 사용
• 로깅의 경우에는 중간에 message queue를 써서 로그를 다른 서버에서 쓰도록 하여 IO를 분산
• Back write와 같은 방식으로 로그 메세지가 발생할때 마다 disk에 writing 하는 것이 아니라 20개 30개씩 한꺼번에 디스크로 flushing 하는 방식

 

단계5) 튜닝

1. 문제정의

 “그냥 느려요”가 아니라, “성능 목표가 350TPS에 1초내의 응답 시간인데, 현재 60 TPS에 5초의 응답 시간에 WAS의 CPU 점유율이 100% 입니다.”와 같이 명확해야 하며, 문제점이 재현 가능해야 한다.

2. Break Down 

전체 성능 구간중, 어느 구간이 문제를 발생 하는지를 정의한다.

3. Isolate

문제가 되는 구간을 다른 요인으로 부터 분리 (고립) 시킨다. 

4. Narrow down

근본적인 문제를 찾기 위해서 문제의 원인을 파 내려간다. Profiling을 하거나, 코드에 디버그 정보를 걸어서 문제의 원인을 분석하는 과정

5. 병목구간 확인

6. 해결

 

단계6) 반복

튜닝이 끝났으면 다시 “테스트 및 모니터링” 항목으로 돌아가서 성능 목표에 도달할때까지 위의 작업을 계속해서 반복해서 수행한다.

 

참고자료

bcho.tistory.com/m/787