성능 테스트란?

서비스 및 서비스 시스템의 성능을 확인하기 위해 실제 사용 환경과 비슷한 환경에서 테스트를 진행하는 것.
성능 테스트를 통해 응답시간(Response Time), 처리량(Throughput), 병목구간 등을 확인가능.
성능 테스트로 얻은 정보로 서비스나 시스템의 문제점을 확인하고 이를 개선(Tuning)해 보완.

성능테스트는 서비스 및 서비스 시스템이 작업 부하 상태에서 제대로 작동하는지 확인하는 일종의 소프트웨어 테스트.
성능 테스트의 목적 - 버그찾는것 X -> 성능 병목 현상 제거.
특정 이벤트에 대해 미리 동시 접속자 수에 대한 성능 테스트를 수행함으로써 서버가 몇 명까지의 동시 접속자 수를 케어할 수 있는지, 어디에서 부하가 많이 발생하는지 사전에 미리 예측하고 대비 가능.

성능 테스트 유형

1) Load Test
- 동시 사용자 또는 프로세스 수에 의해 생성되는 트랜잭션의 요청으로 인해 현실적인 부하 수준을 처리하는지에 대한 시스템 성능 측정.
2) Stress Test
- 임계값 이상의 요청이나 비정상적인 요청을 보내 비정상적인 상황의 처리 상태 확인, 시스템의 최고 성능 한계를 측정하기 위한 테스트
3) Spike Test: 갑자기 사용자가 몰렸을 때 요청이 정상적으로 처리되는지, 또는 업무 부하가 줄어들 때 정상적으로 반응하는지 확인
4) Scalability Test/Soak Test
- 긴 시간 동안 테스트를 진행해 테스트 시간에 따른 시스템의 메모리 증가, 성능 정보의 변화 등 확인

성능 테스트 용어

1) Active User : 실제 서버에 연결된 상태로 요청을 처리 중인 사용자
2) Inactive User: 웹브라우저에 결과 화면이 출력된 상태에서 화면의 내용을 읽거나 정보를 입력하고 있는 사용자
3) Concurrent User: 특정 시점에 시스템에 접속해 사용하고 있는 사용자
* Concurrent User = Active User + Inactive User
4) Virtual User: 가상 사용자 수, Apache JMeter에서는 Thread 수로 표현하기도 함
5) Response Time/Load Time: 응답시간 또는 처리시간, 요청을 보낸 후 응답이 완료되어 사용자 화면에 출력될 때 까지의 시간
6) Latency : 요청을 보낸 후 데이터를 받기 시작할 때까지 시간
7) Think Time: 하나의 요청에 응답을 수신하고 다음 요청을 보낼 때까지 시간
8) Request Interal Time : 요청 보낸 후 다음 요청을 보낼 때 까지 시간
9) Ramp-Up Period : Thread 생성에 걸리는 시간
10) Transaction : 업무 처리의 단위, 화면 조작 및 응답을 트랜잭션으로 정의
11) Throughput: 단위 시간 당 대상 서버에서 처리되는 요청의 수, Apache JMeter에서는 시간 단위를 보통 TPS(Transaction Per Second)로 표현

Apache JMeter

서버가 제공하는 성능 및 부하를 측정할 수 있는 테스트 도구
서버나 네트워크 또는 개체에 대해 과부하를 시뮬레이션하여 강도를 테스트하거나 다양한 부하 유형에서 전체 성능을 분석하는 데 사용

• Thread Group - 몇 개의 쓰레드가 동시에 요청을 보내는 지
• sampler - 어떤 유저가 해야 하는 액션
• Listener - 응답을 받았을 때 어떤 동작취하는지
• Configuration - Sampler or Listener가 사용할 설정 값 (쿠키, JDBC 커넥션 등)
• Assertion - 응답 결과의 성공 여부를 판단하는 조건(응답 코드, 본문 내용 등)

• Number of Threads - 몇 개의 쓰레드(유저 수)로 테스트할 지(동시에 접속하는 가상 사용자 수) --> 동시 접속할 사람 수

• Ramp-up period - {Number of Threads} 만큼의 쓰레드를 몇초에 걸쳐 만들지(전체 Thread 유입시간)
  => 전체 쓰레드가 몇 초 안에 실행을 마쳐야 하는가. 보장X -> 빠르게 끝날수도, 늦게 끝날수도 있음 --> 몇 초 안에 몇 명 설정
  ->>>> 총 요청에 걸리는 시간(TPS = Number of Threads/Ramp-up period)
  ex) 10000개의 Thread 요청을 100초 동안 보낸 결과! 중 100초를 나타냄!!
  -> 이걸 수정하면 connection error가 해결할지도?
  

• Loop Count - 요청을 몇번 반복할지 (반복횟수)

header에 담긴 토큰 설정하는 법

body에 값 담기

HTTP Request 구성
1) Protocol[http] : http or https 입력
2) Server Name or IP : Host or IP 입력
3) Port Number : Port 번호 입력
4) Path: Path 입력
5) Parameters: 파라미터 값 입력

Listener

Sampler에서 요청한 것에 대한 결과를 수집해서 결괏값을 보여주는 기능.

View Result Tree는 각 Sampler에 대한 Sampler result, Request data, Response data 등을 확인할 수 있고, Text, HTML 등의 형태로 확인 가능.

Summary Report

테스트한 결과 요약

구성
1) Label: HTTP Request Sampler에서 설정한 Name
2) #Samples: 호출 건수
3) Average/Min/Max/Std.Dev. : 응답시간 통계(1/1000초 단위로 표시됨)
4) Error% : 오류율
5) Throughput: 단위 시간당 처리량(TPS)

소프트웨어 품질 특성

1. functional suitablility(기능 적합성)
   1.1 functional completeness(기능 완전성)
   1.2 functional correctness(기능적 정확성)
   1.3 functional appropriateness(기능적 적절성)
   2. performance efficiency(성능 효율성)
   2.1 time behavior(시간 반응성)
   2.2 resource utilization(자원 효율성)
   2.3 capacity(용량성)
2. compatibility(호환성)
   3.1 co-existence(공존성)
   3.2 interoperability(상호운영성)
3. usability(사용성)
   4.1 appropriateness recognizability(적절성 인지정도)
   4.2 learnability(학습성)
   4.3 operability(조작성)
   4.4 user error protection(사용자 오류 방지)
   4.5 user interface aesthetics(UI 미학)
   4.6 accessibility(접근성)
4. reliability(신뢰성)
   5.1 maturity(성숙성)
   5.2 availability(사용가능성)
   5.3 fault tolerance(결함 허용성)
   5.4 recoverability(복구성)
5. security(보안)
   6.1 confidentiality(기밀성)
   6.2 integrity(무결성)
   6.3 non-repudiation(부인방지)
   6.4 accountability(책임추적성)
   6.5 authenticity(인증성)
6. maintainability(유지 보수성)
   7.1 modularity(모듈성)
   7.2 reusability(재사용성)
   7.3 analysability(분석성)
   7.4 modifiability(변경성)
   7.5 testability(시험성)
7. portability(이식성)
   8.1 adaptability(적응성)
   8.2 installability(설치성)
   8.3 replaceability(대체성)

---

1) Time behaviour measures(시간 반응성)
- Mean response time(평균 응답 시간)

• Response time adequacy(응답 시간 적절성)
  - Mean turnaround time(평균 소요 시간)
• Turnaround time adequacy(처리 시간의 적절성)
  - Mean throughput(평균 처리량)

2) Resource utilization measures(자원 효율성)

• Mean processor utilizaton(평균 프로세서 사용률)
• Mean memory utilization(평균 메모리 사용률)
• Mean I/O devices utilization(평균 I/O 장치 사용률)
• Bandwidth utilization(대역폭 사용률)

3) Capaciry measures(용량성)

• Transaction processing capacity(트랜잭션 처리 용량)
  - User access capacity(사용자 액세스 용량)
• User access increase adequacy(사용자 액세스 증가 적절성)

Apache JMeter를 이용해 측정 가능한 매트릭

• 평균 응답시간, 평균 소요시간, 평균 처리량, 사용자 액세스 용량

Average 값 : 평균 응답시간, 평균 소요시간 측정 가능.
TPS 값 : 평균 처리량
Thread 수(동시 접속자 수) 설정해 스크립트 실행 후 Error% 확인해 사용자 액세스 용량 측정.

그래프 더 참고할때 보는 블로그

---

JMeter 5.5

개방형 모델 스레드 그룹

개방형 모델 스레드 그룹을 사용하면 가변 하중이 있는 하중 프로파일 작성 가능
-> 속도(0/초) random_arrivals(1분) 속도(10/초)와 동일한 로드 프로파일 구성 가능.
스레드 그룹은 구성된 로드를 구동하는 데 필요한 스레드 생성.
부하 프로필은 속성을 사용할 수 있어 약간 다른로드 수준으로 동일한 스크립트 시작가능.

명령어

• rate((num/sec)
  - 목표 로드 속도를 구성.
  지원되는 시간 단위 - ms, sec, min, hour, day
• random_arrivals((num) sec)
  - 지정된 기간으로 임의 도착 일정 구성.
  시작하중율 - random_arrivals 전에 구성,
  마무리하중율 - random_arrivals 후에 구성.
  ex) 처음에 10/sec 부터 끝에서 5/sec 까지 15분 테스트는 속도(5/sec) random_arrivals(10분) 속도 (15/초