postgreSQL을 DB로 사용하는 Springboot application의 부하테스트를 실행할 일이 있었다.

AB(Apache HTTP server benchmarking tool)를 활용하여 테스트를 진행.

-c 옵션으로 request의 병렬 진행수를 늘려서 실행.

그런데 요청당 스루풋이 엄청나게 느렸다.

원인

스레드수와 커넥션 풀의 숫자 차이.

Springboot의 min spare thread의 default value가 40, max spare thread의 default value가 200이고 postgreSQL에 대한 connection pool은 10개.

부연 설명

이 Springboot application은 DB에 Read & Write가 많았기 때문에 이러한 connection pool가 thread수의 차이는 병목 현상을 일으킨다.

DB에 대량의 데이터를 저장하는 엄청나게 무거운 트랜잭션 메소드가 있었기에 이 메소드를 호출하는 리퀘스트를 실행하면 병목현상이 매우 심하여 전체적인 스루풋이 대폭 저하하였다.

이러한 병렬 리퀘스트에 대한 병목현상은 DB의 처리시간이 조금만 늘어나도 리퀘스트의 스루풋의 큰 저하를 가져온다.

예를 들면 DB에서 100개의 데이터를 가져오는것과 300개의 데이터를 가져오는 쿼리가 있다고 할때, 데이터가 크므로 DB와의 통신시간도 길어지고, DB 쿼리 자체의 처리 시간도 길어진다.

이 조그마한 DB 작업의 지연은 병렬 리퀘스트의 숫자에 비례하여 증가하므로 전체적인 스루풋이 감소하는 결과를 가져오게 된다.

해결책 후보를 내기

1. max-connection-pool을 증가

우선, connection-pool의 숫자를 어느정도 늘려야 할 필요가 있다.
그러면 어느정도까지 늘리면 될까?

적어도 1:1은 아니리라.

Springboot application에서 template engine으로 thymeleaf를 이용하고 있고 이 thymeleaf는 xml기반이므로 처리가 무겁다.

따라서 Springboot의 thread 수와 connection pool의 수를 1:1 비율로 하지 않아도 된다.

하지만 이것도 이번엔 DB쪽에 가해지는 부하가 커지므로 문제를 일으킬 가능성이 존재한다.

DB의 성능은 현재 수평적이든 수직적이든 개선이 가능하므로 성능만에 관계된 문제라면 좋겠지만...

2. SQL query의 개선.

• Write & Read의 횟수를 감소시키기
• 무거운 trasaction method
• 불필요한 JOIN문 제거