TPS 및 톰캣 & HikariCP 설정
- 월 예산 초과로 인해 테스트 데이터베이스 환경을 운영 환경과 동일하게 구성하지 못했다.
- 데이터베이스: db.m6gd.large(운영), t4g.micro(테스트)
- 테스트 환경에서 최대한 성능 개선을 한 뒤, 그 결과를 운영에 적용하기로 결정했다.
- 데이터베이스 테이블당 더미 데이터 70만~100만건 적재
- 프로그래밍 관련 교육 서비스 중 보편적으로 많이 사용되는 알고리즘 서비스 백준 선택
- 백준 페이지 뷰 수를 초 단위로 나눈 값을 목표 TPS로 설정했다.
- 페이지 뷰 수 / 86,400(초/일)
- 19,080,000 / 86,400 = 220.69 TPS
- 페어 프로그래밍에 직접적으로 도움을 주는 주요 API 단일 테스트
- 서비스 사용 흐름을 예측하는 시나리오 기반 API 다중 테스트
- ‘코딩해듀오’ 서비스 사용자들이 페어 프로그래밍을 진행에 도움을 주는 몇가지 기능을 추려, 하나의 API건 별로 TPS 측정을 실시하고 특이사항을 관찰한다.
- 가상 사용자 200백명을 대상으로 2분간 50명씩 늘려가며 총 8분동안 테스트
시나리오: 각 사용자는 1초에 한번씩
[POST] /api/pair-roomAPI를 호출한다.
- TPS 추이
- 성능 테스트 실행 결과 메트릭
시나리오 TPS
- 16TPS
특이사항
- DB 병목: HikariCP pending이 최대 168개까지 올라간다.
- 0.17 %(즉, 07705 요청 중 13개 요청 실패)
시나리오: 각 사용자는 1초에 한번씩
[GET] /api/pair-room/{accessCode}API를 호출한다.
- TPS 추이
- 성능 테스트 실행 결과 메트릭
시나리오 TPS
- 22.61TPS
시나리오: 각 사용자는 1초에 한번씩
[PATCH] /api/pair-room/{accessCode}/statusAPI를 호출한다.
- TPS 추이
- 성능 테스트 실행 결과 메트릭
시나리오 TPS
- 25.80 TPS
특이사항
- DB 병목: HikariCP pending이 최대 148개까지 올라간다.
시나리오: 각 사용자는 1초에 한번씩 아래 API 호출
[POST] /api/pair-room방 생성[POST] /api/{accessCode}/todos방에 TODO 리스트 생성
- TPS 추이
- 성능 테스트 실행 결과 메트릭
시나리오 TPS
- 16.78
특이사항
- DB 병목: HikariCP pending이 최대 179개까지 올라간다.
- 페이룸 생성 타임아웃: 338개 발생
시나리오: 각 사용자는 1초에 한번씩 아래 API 호출
[POST] /api/{accessCode}/todos방에 TODO 리스트 생성[GET] /api/{accessCode}/todosTODO 리스트 조회
- TPS 추이
- 성능 테스트 실행 결과 메트릭
시나리오 TPS
- 5.30
특이사항
- JVM 쓰레드 live max312개
- 저조한 TPS
- 낮은 성공률
시나리오: 각 사용자는 1초에 한번씩
[POST] /api/{accessCode}/reference-linkAPI를 호출한다.
- TPS 추이
- 성능 테스트 실행 결과 메트릭
시나리오 TPS
- 24.39 TPS
각 사용자는 1초에 한번씩
[POST] /api/{accessCode}/categoryAPI를 호출한다.
- 초당 요청 성공률
- 성능 테스트 실행 결과 메트릭
시나리오 TPS
- 22.04
- 최소: 5.3
- 최대: 25.8
- 평균: 18.9
- 가상 사용자가 약 150명에 도달했을 때, hikariCP 고갈 문제 발생
데이터베이스 병목 현상이 발생함을 확인하고, 시나리오 테스트를 통해 개선한다.
- 페어룸 생성
- SSE 커넥션 생성
- 투두 목록 조회
- 레퍼런스 링크 조회
- 타이머 정보 조회
- 타이머 시작
- 레퍼런스 링크 생성
- 투두 목록 생성 10회
- 카테고리 생성 3회
- 페어 역할 변경
- 페어룸 상태 변경
- 타이머 중지
테스트 환경
- 0~4분: 50명 순차적으로 증가
- 4~8분: 100명 순차적으로 증가
- 8~12분: 150명 순차적으로 증가
- 12~16분: 200명 순차적으로 증가
- HikariCP
max-pool조정 - 톰캣
threads max,max connections,accept count설정 조정
- TPS: 7.9
- 특정 상황에서 connection이 반환되지 않아 요청이 pending 상태가 된다.
- 150명 이상 접속 시 hikari connection 급격하게 증가
- TPS: 10.8
- 특정 상황에서 connection이 반환되지 않아 요청이 pending 상태가 된다.
- 178명 이상 접속 시 hikari connection 급격하게 증가
- 왼쪽부터 시간 순으로 max-connection-pool의 수는 10개, 20개, 5개이다.
- 측정 결과 default 설정인 10개일 때 가장 TPS가 높았고, 20개와 5개일 때 비슷한 수치를 보였다.
- 측정 결과 default 설정인 10개일 때 pending 상태인 커넥션 수가 가장 적었다.
결론: HikariCP maxPoolSize는 10개 일때 가장 효율이 좋음을 확인했다.
데이터베이스 병목으로 인해 유미의한 측정이 불가능하여, 시나리오를 단순화하고 순간적인 대량 부하로 HTTP 요청 한계와 TPS를 측정한다.
- 0~1분: 100명
- 1~2분: 200명
- 1분~1분30초: 300명
max-thread: 100
- TPS:30.72
- 성공률: 94.79
max-thread: 150
- TPS: 29.35
- 성공률: 98.25
max-thread: 200
- TPS: 29.10
- 성공률: 97.03
결론: TPS에서 유의미한 차이가 없지만, 성공률에서 max-thread 150개가 98.53으로 가장 안정적이다.
max-connection: 4000
- 성공률: 97.47
- TPS : 27.98
- GC stop the world: 13.4ms
max-connection: 6000
- 성공률: 98.58
- TPS: 27.8
- GC stop the world: 16.6ms
max-connection: 8000
- 성공률: 98.53
- TPS:29.95
- GC stop the world: 66.1ms
결론: Tomcat의 Max-connection 조정으로 인한 뚜렷한 TPS 수치 변화는 몇지만, 8192개에서 6000개로 하향 조정한 결과 GC stop the world 지속시간이 약 4배 개선되었다.
accept-count: 100
accept-count: 200
결론: 약 2%대의 Request Timeout의 개선을 위해 Tomcat acceptCount를 상향 조정하였지만, 뚜렷한 변화를 관찰하지 못하였다.
적용 값
- HickariCP Max-pool-size: 10
- Tomcat Max-Thread: 150
- Tomcat Accept-Count: 100
- Tomcat Max-connection: 6000
실험을 통해 예측한 예상 값과 함께 운영서버와 같은 환경(db.m6gd.large)의 데이터베이스를 사용하여 최종 TPS를 측정한다.
220.47TPS로 목표치와 근사한 결과를 확인했다.