개요

Commons DBCP 이해하기

Commons DBCP, Commons DBCP2

• JDK 버전과 Commons DBCP의 호환성을 잘 맞춰 설정해야 한다. Commons DBCP2가 이전 버전의 하위 호환성을 보장하지 않는다.

커넥션

• 커넥션 풀의 저장 구조

  

  • 어떤 타입의 커넥션 객체를 생성하는가?
    • PoolableConnection
  • 커넥션 풀은 어떤 자료구조로 커넥션을 관리하는가?
    • LIFO 형태의 CursorableLinkedList 자료구조

• 사용자가 임의로 지정할 수 있는 속성

  • initialSize : BasicDataSource 클래스 생성 후 최초로 getConnection() 메서드를 호출할 때 커넥션 풀에 채워 넣을 커넥션 개수
  • maxActive
  • maxIdle
  • mindIdle

TPS

• 하나의 요청에서 총 10개의 쿼리를 실행하고 하나당 50ms가 소요된다면 하나의 요청을 처리하는데에 걸리는 시간은 500ms다.

• 1초에 2개의 요청을 처리할 수 있고 이것이 가능한 커넥션에 커넥션 풀에 5개가 존재하니 1초에는 10개의 요청을 처리할 수 있다. 성능 지수로는 10TPS(Transaction Per Second, 1초에 처리할 수 있는 트랜잭션)다.

• TPS는 커넥션의 개수와 밀접한 관계를 갖는다. 만약 요청이 5개 이상이 된다면 요청을 처리해야하는 커넥션이 없기 때문에 요청이 사용할 수 있는 커넥션이 생길 때까지 maxWait만큼 대기한다.
  • 이 때 시도할 수 있는 방법은 **커넥션 풀에서 일할 수 있는 커넥션 개수(maxActive)**를 늘리는 것이다.
  • 하지만 DBMS는 다른 서비스와 공유되기 때문에 무턱대고 크게 늘릴 수 없다.
    • 예상 접속자 수와 서비스의 실제 부하를 측정해 최적값을 설정해야 한다.
    • 따라서 maxWait을 최적으로 설정하는 것이 과부하 상태에서 시스템의 견고함을 유지시키는데에 도움이 된다.
• 최적의 maxWait(커넥션을 얻기 위해 대기하는 시간을 의미, 초과 시 예외 throw) 값은 어떻게 찾을까?
  • 우선 maxWait에서 커넥션을 기다리는 쓰레드는 톰캣의 쓰레드 풀에서 관리되는 HTTP Request를 처리하는 쓰레드다.
    • 톰캣의 쓰레드 풀은 기본값으로 200개를 갖는다.
  • 쿼리가 정말 느려서 만약 5개는 커넥션을 통해 쿼리를 실행하고 있고, 나머지 195개가 10초의 전부 maxWait(여기서는 10초라고 가정)만큼 기다리고 있는 중이라고 생각해보자. 이 때 사용자 수가 폭주해서 톰캣의 쓰레드 풀조차 가용 쓰레드가 없다면 어떻게 될까?
    • 톰캣도 All threads (512) are currently busy, 에러를 발생시키며 정지한다.
    • 결국 1~5번부터 커넥션에서 쿼리가 완료되고 10초중 7초를 대기하던 6번부터 차례로 200번 스레드까지 커넥션을 얻어 쿼리를 정상적으로 처리해도 사용자들은 이미 다 떠난 뒤다.
    • 대부분의 사용자들은 2~3초 내에 반응이 없으면 새로고침을 연타하거나 나가버린다. 사용자가 인내할 수 있는 시간을 넘는 maxWait은 의미가 없다.
    • 반대로 1초로 너무 작게 설정하면 1초밖에 안기다리고 “난 못해!”라고 사용자에게 에러를 반환한다. 이런 경우 역시 일어나선 안된다.
    • maxWait 값도 사용자의 대기 가능한 시간 같은, 애플리케이션의 특성과 다른 주변의 설정, 자원의 상황 등을 고려해 판단해야 한다. 만약 갑작스럽게 사용자가 증가해 maxWait 값 안에 커넥션을 얻지 못하는 빈도가 늘어난다면 maxWait 값을 더 줄여서 시스템에서 사용하는 스레드가 한도에 도달하지 않도록 방어(톰캣 스레드가 더이상 대기하지 않고 사용자에게 에러를 throw한 뒤 쓰레드 풀에 반환되도록, 간헐적 오류를 발생시키는 것)할 수 있다.