was가 실행되면서 미리 DB와 연결 해놓은 객체들을 pool에 저장해두었다가
클라이언트 요청이 오면 connection을 빌려주고 처리가 끝나면 이를 반환받아 pool에 다시 저장하는 방식
커넥션 풀 사용이유
매번 연결 객체를 생성하게되는 경우 비효율적
- db와 네트워크 연결하는 시간 단축 = 응답 시간 단축 -> 처리량 증가
- db에 대한 커넥션 개수를 일정 수준으로 유지 = db 포화 방지 -> 일관된 db성능 유지
1. was가 실행될 때 connection 객체를 미리 생성하고 pool에 저장해둔다
2. 요청에따라 pool에서 connection객체를 가져다 쓰고 반환한다.
3. 이를 통해 데이터베이스 connection부하를 줄일 수 있다.
4. pool에 미리 connection객체를 생성해둠으로써 매 요청마다 생성하지 않고 있는걸 전달함으로써 적은 시간소요
대량의 요청이 발생하는 경우
커넥션풀에 생성된 connection객체가 모두 할당이되고 남은게 없다면
사용자는 connection객체가 반환될 때까지 대기
그러면 커넥션풀을 크게 설정하면되지 않느냐?
그만큼 많은 메모리 소모
그러나 커넥션풀을 작게 설정하면 그만큼 대량 요청시 대기시간 증가
스프링부트의 hikari 풀을 알아보자
설정을 잘 알아야 잘못된 사용을 막을 수 있다
커넥션 최대 개수 : maximumPoolSize
쿼리 실행시간이 총 0.1초인 상황에서 목표 TPS인 100을 맞추려면?
필요한 동시 커넥션 개수 = 목표 TPS / ( 1초 / 쿼리실행시간) = 100 / (1 / 0.1) = 10
즉 쿼리 실행시간이 평균 0.1소요될 때 100TPS를 맞추려면 10개의 커넥션이 필요
⭐️그런데 우리는 느린! 쿼리를 항상 염두해야한다
평균 쿼리 실행시간이 0.1초라고 모두 0.1초안에 처리되는게 아니다
따라서 느린 쿼리를 염두하고 조금 더 충분하게 커넥션 개수를 늘려야한다
커넥션 대기 시간 : connectionTimeOut
기본 30초는 커넥션 대기시간이 매우 길다. 좋지 않다.
만약 풀의 모든 커넥션이 사용중일때 30초 동안 다음 요청은 대기해야한다
응답 없음보다 차라리 에러 화면을 돌려주는게 좋을때도 있다.
커넥션 최대 유지 시간 : maxLifeTime
네트워크나 db의 관련 설정보다 최대 유지시간을 짧게 가져가야한다.
당연한것. 지원되는 네트워크 설정을 넘어서면 문제가 발생할 수 있다.
최소 유휴 커넥션 : minimumIdle
풀에 유지할 최소 유휴 커넥션 개수
- 설정하지 않으면 maximumPoolSize와 동일
이는 트래픽이 적은 시간대 db 자원 사용을 줄일 수 있는 방법이 될 수 있다.
그러나 hikari는 이를 추천하지 않는데
결국 이 값이 작으면 예상하지 못한 트래픽에 대응하기가 굉장히 어렵기 때문
(그럼 이때 10개로 설정해놨다가 갑자기 트래픽이 몰리면 급격하게 많은 커넥션을 생성해야하는 문제가 생긴다) 조심해라
커넥션 풀
커넥션 풀 사용이유
대량의 요청이 발생하는 경우
스프링부트의 hikari 풀을 알아보자
⭐️그런데 우리는 느린! 쿼리를 항상 염두해야한다
커넥션 대기 시간 : connectionTimeOut
커넥션 최대 유지 시간 : maxLifeTime
최소 유휴 커넥션 : minimumIdle
이는 트래픽이 적은 시간대 db 자원 사용을 줄일 수 있는 방법이 될 수 있다. 그러나 hikari는 이를 추천하지 않는데 결국 이 값이 작으면 예상하지 못한 트래픽에 대응하기가 굉장히 어렵기 때문 (그럼 이때 10개로 설정해놨다가 갑자기 트래픽이 몰리면 급격하게 많은 커넥션을 생성해야하는 문제가 생긴다) 조심해라