적절한 pool-size가 필요한 이유

conection이 여러 개여도 cpu의 갯수가 무제한이 아닌 이상 switch-context 비용이 발생하게 됨

thread의 수가 적을 수록 데이터에 대한 탐색시간이 짧아지고 switch-context에 대한 비용이 감소하게 된다. 적절한 수는 결국 cpu의 core의 수에 가까운 수 일수록 좋은 효율을 나타내게 된다.

그렇다면 CPU의 코어 수와 같은 pool 사이즈를 사용하면 되는 것 아닌가?

그건 또 아닌 것이 적은 pool사이즈에서는 pool-locking이라는 현상이 발생

2개의 커넥션이 쓰이는 쓰레드와 1개의 max-connection-pool을 가지는 프로그램이 있다고 가정을 할때,

이 쓰레드가 하나의 커넥션을 쓰는 것과 동시에 나머지 1개의 커넥션을 대기하면서 스스로 lock을 걸어버리게 된다. 이처럼 쓰레드가 사용해야하는 수보다 커넥션의 수가 부족하게 되어 쓰레드 스스로가 사용하고 있는 스레드를 대기하게 되는 현상을 pool locking이라고 한다. 이에 대한 해결책으로 HikariCP-wiki에서는 다음과 같은 공식을 최소한의 pool size로 제시를 하였다.

pool size = Tn x (Cm - 1) + 1

(Tn : 쓰레드 수, Cm: 단일 스레드가 사용하게될 커넥션의 수

최소한이지만 최적은 아닐 것이다. 따라서 최소한 pool-size의 갯수를 가진채 최대 효율을 가지는 pool-size를 성능 테스트를 통해 찾아본다. 조건은 K6를 통하여 300명의 유저가 2분간 요청을 보낸다는 가정하에 요청에 걸린 평균 시간을 비교해본다.

hikari cp에서 바꿀수 있는 properties

// Properties changeable at runtime through the HikariConfigMXBean
   //
   private volatile String catalog;
   private volatile long connectionTimeout;
   private volatile long validationTimeout;
   private volatile long idleTimeout;
   private volatile long leakDetectionThreshold;
   private volatile long maxLifetime;
   private volatile int maxPoolSize;
   private volatile int minIdle;
   private volatile String username;
   private volatile String password;