[BE] 6차 데모데이 요구사항 Tomcat Thread 설정

[zeus6768]

10월 11일 금요일에 회의할 예정입니다.

각자 자료조사 해오기~

[kyum-q]

Connection Pooling 이란

• 커넥션 풀링(Connection Pooling)이란?
• DataSource 객체를 통해 미리 커넥션(Connection)을 만들어 두는 것을 의미한다.
• 새로운 커넥션을 생성하는 것은 많은 비용이 들기에 미리 커넥션을 만들어두면 성능상 이점이 있다.
• 커넥션 풀링에 미리 만들어둔 커넥션은 재사용 가능하다.

HikariCP 설정

connectionTimeout

클라이언트(즉, 사용자)가 풀에서 커넥션을 기다리는 최대 밀리초 수

• 커넥션이 사용 가능하지 않은 채 이 시간을 초과하면 SQLException이 발생합니다.
• 허용되는 최소 커넥션 시간 초과: 250ms 
• 기본값: 30000(30초)

idleTimeout

커넥션이 풀에서 유휴 상태로 유지될 수 있는 최대 시간

• maximumPoolSize가 minimumIdle미만으로 정의된 경우에만 적용됩니다.
• 풀이 최소 유휴 커넥션 수에 도달하면 유휴 커넥션이 종료되지 않습니다.
• 커넥션이 유휴 상태로 종료되는지 여부는 최대 +30초, 평균 +15초의 변동이 있을 수 있습니다.
• 이 시간 초과 전에는 커넥션이 유휴 상태로 종료되지 않습니다.
• 값이 0이면 유휴 커넥션이 풀에서 제거되지 않습니다.
• 허용되는 최소값: 10000ms(10초)
• 기본값: 600000(10분)

keepaliveTime

데이터베이스나 네트워크 인프라에서 시간 초과가 발생하지 않도록 HikariCP가 커넥션을 활성 상태로 유지하려고 시도하는 빈도

• 이 값은 maxLifetime값보다 작아야 합니다
• 허용되는 최소값: 30000ms(30초)  
• 기본값: 0(비활성화됨)
  • 분 범위의 값이 가장 바람직

maxLifetime

풀에서 커넥션의 최대 수명을 제어

• 사용 중인 커넥션은 결코 폐기되지 않으며, 닫힐 때만 제거
• 커넥션별로 사소한 음수 감쇠가 적용되어 풀에서 대량 소멸이 방지
• 이 값을 설정하는 것이 좋으며, 데이터베이스나 인프라에서 부과하는 커넥션 시간 제한보다 몇 초 더 짧아야 합니다.
• 값 0은 최대 수명(무한 수명)이 없음을 나타내며, 물론 idleTimeout설정에 따라 달라집니다
•  허용되는 최소값: 30000ms(30초)
• 기본값: 1800000(30분)

minimumIdle

HikariCP가 풀에서 유지하려고 하는 최소 유휴 커넥션 수

• 유휴 커넥션이 이 값 아래로 떨어지고 풀의 총 커넥션이 maximumPoolSize보다 작으면 HikariCP는 신속하고 효율적으로 추가 커넥션을 추가하기 위해 최선을 다합니다.
• 그러나 성능과 급증하는 수요에 대한 응답성을 극대화하려면 이 값을 설정하지 않고 대신 HikariCP가 고정 크기 커넥션 풀로 작동하도록 하는 것이 좋습니다.
• 기본값: maximumPoolSize와 동일

maximumPoolSize

Connection Pool이 가질 수 있는 최대 커넥션 개수

유휴 커넥션과 사용 중인 커넥션을 모두 포함하여 풀이 도달할 수 있는 최대 크기

• 기본적으로 이 값은 데이터베이스 백엔드에 대한 실제 최대 커넥션 수를 결정합니다.
• 이 값은 실행 환경에 따라 결정하는 것이 가장 좋습니다.
• 풀이 이 크기에 도달하고 사용 가능한 유휴 커넥션이 없는 경우, getConnection() 호출은 시간이 초과되기 전까지 최대 connectionTimeout 밀리초 동안 차단됩니다.
• 기본값: 10

MySQL 설정

[!note] prepared statement란?
동일하거나 비슷한 데이터베이스 문을 높은 효율성으로 반복적으로 실행하기 위해 사용되는 기능.
일반적으로 쿼리나 업데이트와 같은 SQL 문과 함께 사용된다. 보통 템플릿의 형태를 취하며, 그 템플릿 안으로 특정한 상수값이 매 실행 때마다 대체된다.

cachePrepStmts

prepared statement의 캐싱 여부

• 디폴트값: false
• 추천값: true (캐싱 사용)

prepStmtCacheSize

하나의 커넥션에 캐싱할 prepared statement의 개수

• 디폴트값: 25
• 추천값: 250-500

prepStmtCacheSqlLimit

캐싱할 prepared statement의 최대 길이

• 디폴트값: 256
• 추천값: 2048

적절한 커넥션 풀 사이즈 찾기

이론상 데드락을 피하면서 모든 요청을 처리할 수 있는 커넥션 개수의 공식은 아래와 같습니다.

[!note] 커넥션 개수 공식
Connection Pool Size = Tn * (Cn - 1) + 1

• Tn: 전체 Thread 개수
• Cn: 하나의 요청에서 동시에 필요한 Connection 개수

[zangsu]

10분 테코톡 - 조조그린의 Thread Pool

TPS 값 설정이 중요한 것 같다.
+) 일반적으로 Non-Blocking 을 지원하는 톰캣의 경우 N 개의 Connection 이 1 개의 Thread 와 묶인다.

정리

결국 톰캣 값을 설정하기 위해선 적절한 TPS 값 설정이 선행되어야 할 것 같다.

톰캣 값 설정 이 목표 -> X
TPS 를 도달하기 위해 Tomcat, Hicari CP 의 값을 조정한다 -> O

TPS

TPS : 1초동안 수행될 수 있는 트랜잭션 수 라고 한다. 이 때의 트랜잭션은 Business Transaction, 즉 일반적인 요청 건수를 생각하면 될 것 같다.
서비스에 지속적으로 사용자가 늘어나면 어느순간 TPS 가 증가하지 않고 수렴하게 된다.
-> 이 지점 : Saturation Point
-> 이 때의 동시 사용자 수 : 최대 허용 동시 사용자

Warning

제대로 튜닝되지 않은 서비스는 Saturation Point 를 지나면 오히려 TPS 가 떨어진다.
TPS 는 수렴하고 떨어지지 않아야 정상적!
떨어진다면 개선해야 한다!!

[!info]
그럼 반대로 최대 동시 사용자 수를 먼저 정하고 TPS 를 설정할 수도 있는건가??

+) SW Maestro 를 하는 사람의 블로그를 보면 TPS 가 2~3000 정도 나오면 괜찮은 서버라고 한다.

목표 TPS 정하기

우리의 첫 목표는 프리코스 사용자 를 고려해 보는 것도 괜찮을 것 같다.
여기에는 두 가지 시나리오가 있을 것 같다.

1. 프리코스 사용자의 상시 업데이트

프리코스 사용자가 어떤 행동을 할 지는 모르겠다.
다만, 업데이트 요청이 많을 것이고, 시간대도 분포되어 있을 것이다.

이 경우 우선 최대한 많은 사용자가 사용할 수 있도록 준비해 두고, 성능 지표를 보면서 조금씩 낮추어 나가도 좋을 것 같다.

2. 최종 코딩테스트 사용자의 동시다발적 접속

이 때는 생성 / 업데이트 요청은 거의 없을 것 같다.
대신 약 200 명 가량의 유저가 조회에 대해 아무 문제 없도록 서비스를 제공해야 할 것 같다.

테스트 방법

무조건 성능 테스트 툴을 사용해 보아야 할 것 같다.

JMeter는 오픈 소스 성능 테스트 도구로, 다양한 프로토콜을 지원하며 사용자 친화적인 인터페이스를 제공합니다. 왜냐하면 JMeter는 다양한 시나리오를 설정하여 성능 테스트를 수행할 수 있기 때문입니다.
Gatling은 고성능 성능 테스트 도구로, 스칼라 기반의 스크립트 언어를 사용하여 테스트 시나리오를 작성할 수 있습니다. 왜냐하면 Gatling은 높은 성능과 확장성을 제공하기 때문입니다.
nGrinder는 분산 성능 테스트 도구로, 여러 대의 머신을 사용하여 대규모 부하 테스트를 수행할 수 있습니다. 왜냐하면 nGrinder는 분산 환경에서 성능 테스트를 수행할 수 있기 때문입니다.

JMeter

가장 참고할 수 있는 아티클이 많아보임\

nGrinder

몰리가 보내준 글 존재

Tomcat 값 설정

우선 스레드는 코어 개수에 따라 달라지는 것 같다.

그리고 Connection은 NIO Connector 의 동작을 조금 더 살펴봐야 하는지도 모르겠다.
어쨋건 스레드 개수 보다는 더 많아도 괜찮을듯

대기큐의 크기는 더 모르겠다.
요청 대기할 사람의 수는 어떻게 정하지

참고

야미의 맛있는 코딩일지 - TPS

[HoeSeong123]

https://velog.io/@tco0427/%EB%B6%80%ED%95%98-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A5%BC-%ED%86%B5%ED%95%9C-%ED%86%B0%EC%BA%A3-%EC%93%B0%EB%A0%88%EB%93%9C-%EC%84%A4%EC%A0%95-%EC%8B%A4%ED%8C%A8%EA%B8%B0

[zangsu]

CPU bound / IOBound 정하고 가야 할 것 같다.
-> IOBound 가 많으면 스레드의 개수를 확 늘릴 수 있다.
왜냐면 IO 작업을 기다리며 CPU 가 놀기 때문에 이 때 다른 스레드를 더 잡을 수 있다.

[zangsu]

병목을 줄이기 위해 DB 를 조금 더 손봐야 할 것 같다.

1. read-only
2. 쿼리 성능 최적화