[DataBase] DBCP

DBCP

커넥션 풀이란 일정량의 Connection 객체들을 미리 만들어서 pool 에 저장했다가, 클라이언트 요청이 오면 Connection 을 빌려주고, 해당 객체의 임무가 완료되면 다시 반납해서 pool에 저장하는 기법입니다.

Hikari CP 동작원리

1. Connection 요청
2. 이전에 사용했던 Connection 정보가 존재하는지 확인합니다.
3. 이전 사용했던 Connection 목록 중 사용 가능한 Connection 이 있는지 확인
4. 전체 Connection 목록 중 사용 가능한 존재 여부 확인
5. Connection 반환

만일 사용가능한 Connection 이 없다면 HandOffQueue 를 Polling 하면서 Thread 가 반납할 때까지 기다립니다. (지정한 TimeOut 시간까지 대기하다가 시간이 만료되면 예외를 던집니다.)

DBCP 의 장점

1. DB 접속 객체를 미리 만들어 메모리 상에 등록해 놓으므로 생성, 삭제같은 작업들이 사라져 빠르게 DB 접속이 가능합니다.
2. DB Connection 수를 제한할 수 있어서 과도한 접속을 방지할 수 있습니다.
3. 새로 객체를 만드는 비용이 줄어듭니다.
4. DB 접속 모듈이 공통화되어 DB 서버의 환경이 바뀔경우 유지보수가 쉬워집니다.

DBCP 의 단점

1. 동시 접속자 수에 따라 Connection 의 개수를 잘 조절해야합니다.
2. Connection Pool 을 크게 만든다면 Connection 을 사용하지않아도 그만큼 메모리에 차지하고있으니 성능이 좋지않습니다.

Thread Pool 과의 비교

1. Thread Pool < Connection Pool
   1. Thread가 사용하는 Connection 외에 남은 Connection은 실질적으로 메모리 공간만 차지합니다.
2. Thread Pool 증가
   1. Thread 증가로 Context Switching 이 더 많이 발생합니다.
   2. Thread 만 넘쳐나면 Connection 개수가 딸려 병목현상이 발생합니다.
3. Connection Pool 의 크기
   1. Hikari CP 공식문서에 의하면 1 connections = ((core_count) * 2 + effective_spindle_count) 로 정의하고 있습니다.
      1. 위와 반대되는 의견인 추가자료 : https://techblog.woowahan.com/2663/
   2. core_count : 현재 사용하는 서버 환경에서의 CPU Core 개수 → Context Switching 을 고려하더라도 데이터베이스의 Disk I/O 보다 CPU 속도가 훨씬 빠릅니다.
      1. 과도한 Context Switching은 CPU Threshold 를 발생시킵니다.
   3. effective_spindle_count : 기본적으로 DB 서버가 관리할 수 있는 동시 I/O 요청 수
      1. Hard Disk 하나는 spindle 하나를 갖습니다.

어떤식으로 Lock 을 걸어?

아래글에서 자세히 설명되어있습니다.

HikariCP Dead lock에서 벗어나기 (이론편) | 우아한형제들 기술블로그

추가적으로 할일

• 하나의 Thread 가 여러개의 Connection을 잡아먹는게 있는지 확인하는법
• 부하테스트 (JMeter, ngrinder) 를 통해 각각 조절하는 기준을 세워보기
• 우아한 기술블로그 - Ngrinder 편 읽기
• https://backtony.github.io/spring/2022-04-21-spring-db-1/