- MySQL과 HikariCP를 기준으로 설명함
DBCP(DB connection pool)이 필요한 이유
- 위와 같은 문제를 해결해주는 것이 DBCP이다.
DBCP의 개념과 원리
- TCP protocol을 활용하여 미리 connection들을 모아둔다.(이를 connection pool이라고 함)
- 그러다가 connection이 필요해지는 경우 pool에서 대기 중인 connection을 가져와 사용한다.
- 이후에 쿼리 통신을 마친 뒤 close connection을 하게 되면 connection pool에 다시 반납을 한다.
DB 서버 설정
- max_connections : client와 맺을 수 있는 최대 connection 수(client는 서버 1대를 말하는 것이 아닌 연결 시도하는 모든 요청들을 말한다.)
- 만약 max_connections 수가 4이고, DBCP의 최대 connection 수가 4라면 다른 서버에서 connection을 맺지 못하게 될 수 있다.
- wait-timeout : connection이 inactive할 때 다시 요청이 오기까지 얼마의 시간을 기다린 뒤에 close 할 것인징를 결정한다. 아래와 같은 상황을 방지해줌
- 비정상적인 connection 종료
- connection을 다 쓰고 반환이 되지 않음
- 네트워크 단절 등등
DBCP 설정
- minimumIdle : pool에서 유지하는 최소한의 idle connection 수
- 권장 사항 : 기본 값은 maximumPoolSize와 동일하게 설정하는 것을 권장함(=pool size 고정)
- maximumPoolSize : pool이 가질 수 있는 최대 connection 수
- idle과 active(in-use) connection 합쳐서 최대수
- maxLifetime : pool에서 connection의 최대 수명
- maxLifetime을 넘기면 idle일 경우 pool에서 바로 제거, active인 경우 pool로 반환된 후 제거
- DB우ㅏ connection time limit보다 몇 초 짧게 설정하는 것을 권장
- pool로 반환이 안되면 maxLifetime이 동작 안하기 때문에 pool로 반환을 잘 시켜주는 것이 중요하다.
- connectionTimeout : pool에서 connection을 받기 위한 대기 시간
적절한 connection 수를 찾기 위한 과정
- 모니터링 환경 구축(서버 리소스, 서버 스레드 수, DBCP 등등)
- 백엔드 시스템 부하 테스트(nGrinder 툴 추천)
- request per second와 avg response time 확인
- 백엔드 서버, DB 서버의 CPU, MEM 등등 리소스 사용률 확인
- thread_per_request 모델이서 CPU와 MEM의 부하가 크지 않음에도 성능이 나오지 않는다면 active thread수를 확인해본다.
- DBCP의 active connection 수 확인