HikariCP 커넥션 풀을 조정해서 TPS개선하기

HikariCP란

데이터베이스 커넥션 풀 프레임워크는 대표적으로 Apache Commons DBCP, Tomcat DBCP, HikariCP 등이 있다.

HikariCP는 스프링부트에 기본으로 내장되어 있는 JDBC 데이터베이스 커넥션 풀링 프레임워크이다.

스프링부트는 HikariCP를 사용할 수 있는 상황에서는 항상 HikariCP를 선택한다.

 

이러한 HikariCP는 커넥션을 하기 전에 미리 커넥션 풀(pool)에 커낵션을 저장해두고 필요할 때마다 재사용하는데

커낵션을 맺는 과정이 비용이 크다.

그래서 이러한 커넥션 풀의 size를 적절하게 설정하는게 불필요한 리소스를 줄이고 성능향상을 기대할 수 있다.

 

 

테스트 시나리오

시나리오는 다음과 같다.

1. 카테고리 조회
2. 마크다운 글 올리기
3. 카테고리에서 글 목록 조회
4. 글 목록에서 첫 번째 글 조회

유저가 동글 서비스에 들어와 다음과 같은 시나리오대로 서비스를 이용한다고 가정한 시나리오다.

 

 

테스트 시작

테스트는 nGrinder를 이용해서 가상의 사용자로 테스트를 진행했다.

 

Vuser 16

처음에는 우리의 서비스를 동시에 사용할 가상의 사용자를 10명정도로 예상했기에

Vuser와 Process, Tread의 수를 각각 16,8,2로 설정했다.

Vusers	Processes	Threads	CP Size	TPS	Peak TPS
16	8	2	10	30.7	34.5
-	-	-	6	29.7	39.0
-	-	-	12	29.6	37.5
-	-	-	8	29.5	37.0
-	-	-	50	28.7	39.5

 

 

실제 테스트 결과

풀 사이즈 10

풀사이즈 6

 

풀 사이즈 12

풀 사이즈 8

풀 사이즈 50

 

 

하지만 커넥션 풀 사이즈의 변동에 따라 TPS가 유의미하게 차이를 보이지 않아, Vuser 수를 늘리고, 요청 수를 늘려보기로 하였다.

 

 

Vuser 56

Vusers	Processes	Threads	CP Size	TPS	Peak TPS
56	8	7	4	30.7	34.5
-	-	-	3	29.7	39.0
-	-	-	5	29.6	37.5
-	-	-	2	29.5	37.0
-	-	-	6	28.7	39.5
-	-	-	10	39.3	50.5

 

실제 테스트 결과

풀 사이즈 4

풀 사이즈 5

풀 사이즈 2

풀 사이즈 6

풀 사이즈 10

 

위 테스트에서 왜 HikariCP 풀 사이즈를 4로 했을때 제일 성능이 좋은지 이해가 안됐다.

그래서 우리팀의 에코가 다음과같은 문서 찾아서 이해할 수 있었다.

위 문서를 요약하면 

• 여기서 말하는 성능은 순수 CPU 요청 처리 속도를 의미한다.
• 코어 수보다 많은 동시 커넥션은 CPU에 부하를 준다.
• 다만 DB 커넥션 풀과는 다르게 웹 서버는 동시에 여러 요청과 함께 특정 요청은 시간이 오래 걸리는 작업들이 있을 수 있기 때문에 connections = core * 2 + disk number 공식을 무조건 사용할 수 없다.

정리해서 위에 공식을 사용했고 우리 프로젝트환경에 적용해보면 

AWS EC2의 t4g.small의 CPU 코어 수는 2이고, EBS는 HDD를 사용한다.

우리가 사용하는 EC2 t4g.small은 HDD이기에 최대 커넥션풀사이즈를 4 ~ 5정도로 나오고

실제 실험 결과에서도 4가 가장 TPS가 높다는 것을 알게되었다.

따라서 현재 동글 서비스의 HikariCP 풀 사이즈는 4로 설정하게 되었다.