Thread Pool
Thread Pool이란 미리 일정 개수의 Thread를 생성해서 작업이 발생하게 되면 Thread Pool에서 미리 생성된 Thread를 이용하여 작업을 처리하는 전략을 말한다.
DB Connection Pool
여러 사용자가 WAS로 요청을 보내어 DB에 그때마다 연결을 하고 응답을 주게 되면 DB 연결을 생성하는 것 자체에도 시간이 오래 걸리기 때문에 응답 속도가 느려질 수 있다. 따라서 여러개의 DB 연결을 미리 해놔서 DB Connection Pool에 저장을 해두고 요청이 오면 Connection Pool에 있는 DB 연결을 사용하도록 하기 위해 필요하다.
Thread Pool과 DB Connection Pool의 상관 관계
Thread Pool의 사이즈를 무작정 크게 늘려서 많은 사용자의 요청을 동시에 받을 수 있도록 하면 무조건 성능이 좋아질까?
Thread Pool 사이즈를 너무 크게 늘리게 되는 상황을 생각해보자.
많은 사용자가 동시에 요청을 보내 각 요청이 Thread를 할당 받고 DB Connection을 사용하게 되는 경우 DB Connection 수가 Thread의 개수보다 너무 적으면 DB Connection을 할당받지 못한 Thread는 다른 요청들이 완료되어 DB Connection을 Pool에 반납 할때 까지 기다려야 하는 상황이 발생하게 된다.
또한, Thread 수가 많더라도 결국 한번에 처리할 수 있는 Thread의 양은 CPU 코어 수에 의존적이다.
이때 CPU/코어에서 실행 중이던 스레드가 다른 스레드로 교체되는 과정에서 컨텍스트 스위칭 오버헤드 현상이 발생하게 된다.
이는 응답시간 증가로 이어져 성능 저하를 초래하게 된다.
또한 자원 낭비와 컨텍스트 스위칭 비용이 증가할 수 있다.
반면 DB Connection Pool의 사이즈를 Thread Pool 사이즈에 비해 너무 크게 설정하게 되면 어떻게 될까?
WAS에서 DB Connection을 사용하는 주체는 Thread인데, Thread Pool에서 트랜잭션을 처리하는 Thread가 사용하는 Connection 외에 남는 Connection은 실질적으로 메모리 공간만 차지하게 된다.
각 상황을 JMeter를 이용해 테스트 해보자.
1. Thread 120, Conn 20
- 응답 평균 194ms, 최대 384ms로 비교적 안정적인 결과
2. Thread 80, Conn 120 (Thread 보다 Connection이 많은 경우)
- 평균 1028ms → 응답이 1초 이상으로 치솟음.
- 불필요한 커넥션에 대한 자원 낭비 + DB가 한번에 여러 커넥션을 처리해야하는 상황 때문에 지연 증가
3. Thread 400, Conn 20 (Thread가 Connection보다 너무 많은 경우)
- 평균 355ms, 최대 1013ms → Thread 120 대비 응답시간은 길어짐
- Thread가 너무 많아 컨텍스트 스위칭 오버헤드 + 대기열 증가
결론적으로, Thread Pool 사이즈와 DB Connection Pool 사이즈를 적절하게 설정하는것이 운영적인 측면에서 매우 중요하다.