[BE] 톰캣 튜닝 설정 값 및 이유

threads max

• 200 (기본)

max connections

• 8192(기본)

accept count

• 100(기본)

배경

적절한 설정 값으로 튜닝하기 위해서는 기본 설정 값에서 값을 변경했을 때 성능 변화를 측정하고 이에 맞는 최적의 설정 값으로 선택하기로 결정했습니다. accept count나 max connections는 스레드가 처리할 수 없는 양의 요청이 들어왔을 때 요청을 얼마나 대기시킬지 정하는 값이기 때문에 적정 thread max값을 먼저 찾고 처리량에 따라 설정하기로 했습니다.

목표

• 병목의 원인이 되는 rps가 낮고 자주 사용되는 api의 rps를 최대화
• api 별로 최적의 응답시간을 만족하도록 튜닝
• CPU 점유율 80% 이하

과정

먼저, 가장 자주 사용되며 성능이 안좋을 것으로 예상되는 api를 측정했습니다.

api/	ThreadMax	accept-count	max-connection	rps
/studies/{studyId}/contents?progressId=100001,cycle=1	10	100	8192	33
/studies/{studyId}/contents?progressId=100001,cycle=1	50	100	8192	33
/studies/{studyId}/contents?progressId=100001,cycle=1	100	100	8192	33
/studies/{studyId}/contents?progressId=100001,cycle=1	200	100	8192	33

예상과는 다르게 thread max값을 조절하더라도 rps는 영향을 받지 않았습니다. 이는 thread 개수보다 더 큰 병목 지점이 있음을 의미하고 이를 해결한다면 thread의 개수가 늘어났을 때 처리량이 증가하여 rps가 증가할것으로 예상했습니다. 모니터링 툴을 통해 메트릭을 확인하였고 10개로 설정되어 있는 DBCP가 병목지점이라고 예상했습니다. pending 상태의 커넥션이 80~90개 정도였기 때문에 이 pending을 해소한다면 I/O 처리 성능이 증가되어 thread 개수에 영향을 받을 것이라고 생각했습니다. DBCP의 커넥션 개수를 200개로 증가시키고 다시 측정해 보았으나 rps는 동일하였고 해당 api는 이러한 설정 튜닝이 아닌 로직과 쿼리를 먼저 개선해야 한다고 결론을 내렸습니다.

이외에 다른 api도 몇 가지 실험을 진행했으나 유의미한 적절한 설정 값을 찾는데 실패했습니다.

API	maxThreads	RPS
api/me	150	451
api/me	100	449
api/me	50	534
api/me	10	688
api/me	5	506
api/auth/guest	100	1180
api/auth/guest	150	1300
api/auth/guest	200	1247

실패 원인

• 서비스의 실제 사용 시나리오를 생각하지 않고 특정 API에 대해서만 부하 테스트를 진행하며 튜닝을 진행
• DB connection pool 관련 설정 값의 영향, 서비스 로직 자체의 성능 개선사항, 스터디 동시 진행 기능 업데이트 등으로 인한 변수 발생 가능성이 존재할 수 있음
• 부하테스트 도구와 방법에 대한 학습 부족으로 인해 올바른 테스트 결과를 도출해내지 못함

해결 방안 및 계획

• 부하테스트 도구에 대한 학습
• thread 개수보다 더 큰 병목인 로직 최적화
• 변경 예정인 기능이 있어 기능 변경을 먼저 적용하고 재측정