Artillery 성능테스트 여정 (계속 업데이트 예정)
| 1. 개요 2. 프로젝트에서 3. 출처 |
|---|
artillery.io 의 첫 화면
Artillery 는 모던하고, 강력하며, 사용하기 쉬운 load testing 그리고 functional testing 툴킷입니다. Backends, APIs & services 들의 테스트를 도와줍니다.
Artillery 는 개발자의 쉬운 사용과 행복, 그리고 건전지 포함 전략에 초점이 맞추어져 있습니다.
$ npm install -g artillery
다음과 같이 global 하게 설정해주어야 사용하기 편하다. ( 퍼미션 denied 가 나온다면, --allow-root --unsafe-perm=true 옵션을 추가해준다 )
$ artillery dino
설치확인을 이렇게 멋진 공룡이 해줍니다.
$ artillery run [options] <script>
스크립트는 다음과 같이 실행합니다. 스크립트는 yaml,json 등으로 짤 수 있습니다.
config:
target: "https://shopping.service.staging"
phases:
- duration: 60
arrivalRate: 5
name: Warm up
- duration: 120
arrivalRate: 5
rampTo: 50
name: Ramp up load
- duration: 600
arrivalRate: 50
name: Sustained load
payload:
# Load search keywords from an external CSV file and make them available
# to virtual user scenarios as variable "keywords":
path: "keywords.csv"
fields:
- "keywords"
scenarios:
# We define one scenario:
- name: "Search and buy"
flow:
- post:
url: "/search"
body: "kw={{ keywords }}"
# The endpoint responds with JSON, which we parse and extract a field from
# to use in the next request:
capture:
json: "$.results[0].id"
as: "id"
# Get the details of the product:
- get:
url: "/product/{{ id }}/details"
# Pause for 3 seconds:
- think: 3
# Add product to cart:
- post:
url: "/cart"
json:
productId: "{{ id }}"
- 사용한 이유 : 우리가 자주 서버성능 이야기를 하셔서 멘토님 께서, 간단하게 사용해보라고 주셨다. 다만, 우리 서버의 서비스들이 복잡하고 오래걸리는 logic 이 아니기 때문에, 눈에 보이게 성능 개선등은 힘들지만, 간단하게 테스트를 하라고 가르쳐 주신것 같다.
드디어 로그인을, 회원가입을 구현했다. 구현 기념으로 우리 API 의 성능을 테스트해보고 싶었다.
Artillery 설치 → 설정을 거쳐 드디어 테스트!
- 60초 동안 1초마다 100개의 요청이 오도록 설정
"target": "http://localhost:3000",
"phases": [
{"duration": 60, "arrivalRate": 100}
],- req 의 이메일, 패스워드 값을 설정해주고 로그인 api를 테스트했다.
"scenarios": [
{
"name": "User Login",
"flow": [
{"post":
{
"url":"/api/auth/login",
"json": {"email":"[email protected]","pwd":"asksA1@aa!"}
}
}
]
}
]- 결과는..?
총 6000개 요청 중에서 544개만 성공했다.
그리고 최소로 걸린 시간은 0.9초 , 최대로 걸린 시간은 119초로 응답을 받는데 평균 114초의 시간이 걸린것이다.
처음 성능테스트를 해보지만 일단 안좋은 결과인건 분명해보인다.
앞으로 이 결과를 어떻게 개선할 수 있을까???!
위의 결과를 멘토님께 피드백을 받았는데, 테스트 요청한 곳도 local 이고 node 가 돌아고있는 곳도 local 이라서 위와 같은 처참한 결과가 나올 수 밖에 없다고 한다.
또한 테스트 대상이 되는 우리의 Backend 서버 의 Logic 은 매우 간단한 편이기 때문에, 큰 성능 개선이 필요한 정도는 아니라고 말해주셨다.
다만 테스트 해보는 것 자체는 나쁘지 않다고 해주셨다.
내가 피드백에서 느낀 두 가지는 , 첫째.
이 날 피어 세션에서 테스트 도움을 주신 11프로젝트 분들 감사합니다.
세가지 결과를 얻었다.
그냥 node 에서 돌릴때
Summary report @ 18:36:42(+0900) 2020-11-27
Scenarios launched: 10000
Scenarios completed: 10000
Requests completed: 10000
Mean response/sec: 356.25
Response time (msec):
min: 72.8
max: 9948.3
median: 8895.5
p95: 9803.9
p99: 9905.3
Scenario counts:
Message Throw Test: 10000 (100%)
Codes:
200: 10000
PM2 프로세스 한개 일 때
Summary report @ 18:03:33(+0900) 2020-11-27
Scenarios launched: 10000
Scenarios completed: 10000
Requests completed: 10000
Mean response/sec: 359.84
Response time (msec):
min: 55.1
max: 9550.5
median: 8545.4
p95: 9395.9
p99: 9519.9
Scenario counts:
Message Throw Test: 10000 (100%)
Codes:
200: 10000
PM2 클러스터링 모드로 프로세스가 4개일 때
Summary report @ 18:06:38(+0900) 2020-11-27
Scenarios launched: 10000
Scenarios completed: 10000
Requests completed: 10000
Mean response/sec: 513.87
Response time (msec):
min: 3.7
max: 187.5
median: 6.7
p95: 41.5
p99: 98.5
Scenario counts:
Message Throw Test: 10000 (100%)
Codes:
200: 10000
보이는 것 처럼 PM2 클러스터링을 이용하면 더 좋은 성능을 보이는 것을 확인할 수 있었다 !