공식 문서 : https://socket.io/docs/v4/load-testing/ , https://www.artillery.io/docs
Node.js Artillery 이용 Server Stress Test (Socket.io)
https://g-g-g-g.tistory.com/entry/서버-스트레스부하-테스트-artillery-사용법-추가-socketio-테스트
https://sinsucoding.tistory.com/10
https://blog.hax0r.info/2020-04-19/stress-test-in-node-with-artillery/
https://ozofweird.tistory.com/entry/GCP-원데이-Artillery를-사용한-부하-테스트
npm install -g artillery
npx artillery run test.yml
npx artillery run 테스트파일명
npx artillery run -o myReport test.yml
npx artillery run -o myReport 테스트파일명
npx artillery report myReport
npx artillery report 레포트이름
artillery quick --duration 60 --rate 10 -n 20 서버 주소
//60초 동안 테스트를 하는데 초당 10 요청을 보내고 동시 접속은 20으로 한다
//사용할 수 있는 옵션의 자세한 내용은 artillery quick -h 로 확인할 수 있다.
loop 는 줄 맞춤이 중요함 : yml 파일은 줄맞춤이 중요함
출처:https://sinsucoding.tistory.com/10
config:
target: 'http://localhost:3000'
phases:
- duration: 60
arrivalRate: 10
engines:
socketio-v3: {}
scenarios:
- name: My sample scenario
engine: socketio-v3
flow:
- emit:
channel: 'newChat'
data:
message: 'hello11'
sender: 'admin'
recipient: 'test'
owners:
[
{ message: 'hello01', sender: 'admin', recipient: 'test' },
{ message: 'hello02', sender: 'admin', recipient: 'test' },
]
- think: 1
- emit:
channel: 'getChats'
- think: 1
세로는 지연시간(Latency), 가로는 시간을 나타낸다.
max: 가장 오래 걸린 요청 → 응답 시간
p95: 전체 HTTP 트랜잭션 중 가장 빠른 것부터 95%까지 (대부분의 트래픽)
p50: 전체 HTTP 트랜잭션 중 가장 빠른 것부터 50%까지 (절반의 트래픽)
min: 가장 빠르게 온 요청 → 응답 시간
이 외에 p99도 많이 사용하는데 거의 모든 트래픽을 의미하기 때문에
💡 p95와 p99는 퍼센타일(Percentile)값으로 Request latency 만 볼 때 95 % 에 있는 요청이 ms 초가 걸렸고, 99%에 해당하는 요청은 ms 가 걸려 느린 요청에 분포를 볼 수 있다.[출처][https://blog.hax0r.info/2020-04-19/stress-test-in-node-with-artillery/](https://blog.hax0r.info/2020-04-19/stress-test-in-node-with-artillery/)
Elapsed time: 10 seconds
Scenarios launched: 999 //인원 수
Scenarios completed: 998 //성공한 인원 수
Requests completed: 998 // 요청 건
Mean response/sec: 100 //100밀리 세컨드
Response time (msec):
min: 2 //제일 빠른 시간
max: 98 //제일 오래 걸린 시간
median: 5 // 중간 값
p95: 10 //하위 뒤에서 5번째로 느린 것.
p99: 25.5 // 하위 1% 애들
Codes:
200: 998 // 코드 200: 성공한 998
TPS는 arrivalRate로 측정할 수 있다.
대부분의 경우 스트레스 테스트는 목표로 하는 TPS가 고정되어 있고 그 TPS를 맞춰야 하기 때문에
TPS를 고정 시킨 상태에서 코드나 인프라를 수정하면서 목표로 하는 TPS가 안정적인지 보면 된다.
성능 향상을 위해 유의미하게 봐야 하는 내용은 가급적 스트레스 테스트를 길게 해봐야 한다는 것이고
실제 유저들의 패턴과 비슷하게 시나리오를 작성해 테스트해야 한다는 것이다.