툴 선택
•
ngrinder
◦
groovy 기반
◦
한국어 지원
•
jmeter
◦
스레드 단위로 관리 가능
◦
업데이트가 안됨
•
k6
Ngrinder 개요
•
controller: 요청 받는 애
◦
agent 관리함
◦
agent 가 보낸 요청에 대한 응답 관리
•
agent: 요청 보내는 애
◦
서버에 요청 보냄 (한 agent 당 3000개까지 보낼 수 있음)
◦
agent를 3000개 이상으로 만들고 싶은 경우, 인스턴스 분리 필요
▪
우리는 3000개 이하로 하기로 결정
•
server
◦
testServer → testDB 생성
서버
결과
offering 조회를 기준으로 성능 측정
HikariCP
•
MaxConnectionPool
◦
50
TPS: 평균 457 (최고 606)
ActiveConnection
PendingConnection
◦
40
TPS: 평균 469 (최고 613)
ActiveConnection: 평균 15 (최고 40)
PendingConnection: 최고 22
API Latency
◦
30
TPS: 평균 448 (최고 608)
ActiveConnection
PendingConnection (7개)
◦
20
TPS: 평균 421 (최고 579)
ActiveConnection: 평균 10~20
PendingConnection: 0 ~ 14(36, 51도 나오긴 했는데 이 수치는 제외한다)
◦
10
TPS 평균 510 (최고 556)
ActiveConnection
PendingConnection
API Latency
유휴상태
◦
8 [채택]
TPS
API Latency
유휴상태
◦
4
TPS 평균 425 (최고 514)
TPS 평균 475 (최고 663) - 두번째 측정
ActiveConnection
PendingConnection
API Latency
40 vs 4
◦
API latency: 10배 차이 (500ms vs 50ms)
◦
PendingConnection: 0 vs 200
◦
ActiveConnection: 15 vs 4
Thread
적정 스레드 개수 = CPU 코어 수 * (1 + 대기시간/작업시간)
필드 정리
•
maxThread = 200
◦
요청을 처리하는 Thread의 최대 수입니다. 처리될 수 있는 동시 요청의 최대 수
•
maxConnections = 8192/10000(NIO)
◦
Max-Connection에 도달하면, 서버는 요청을 받아들이지만 처리하지 않습니다. (서버가 요청을 처리할 수 있는 Connection의 수)
◦
Max-Connection이 10이라면, 10개의 요청이 처리중이라면, block되고 acceptCount 설정에 따라 제어됩니다.
◦
한계(Max-Connection)에 도달하면 OS는 기본 값이 8192인 acceptCount에 따라 요청을 받아들입니다.
•
acceptCount = 100
◦
queue의 최대 길이
•
acceptCount = 100
◦
큐에서 대기 가능한 연결 수
테스트 결과 정리
•
maxThread = 3
◦
TPS: 평균 416
◦
API Latency: 평균 6ms
▪
latency 매우 감소됨. 그러나 TPS에는 큰 변화 없음. (이유: 현재 우리가 측정하는 latency는 스레드가 할당되어야 측정이 가능하다. 따라서 max connections에 비해 max thread가 현저히 적기 때문에 latency는 매우 낮다. + DB 풀을 할당하는 시간이 절약된다.)
•
maxThread = 100
◦
TPS: 평균 516
◦
API Latency: 평균 200ms