프로젝트에서 Hikari 옵션을 아래와 같이 정의하고 사용키로 하였다.
driver-class-name: org.postgresql.Driver
auto-commit: true
connection-init-sql: select 1
minimum-idle: 3
maximum-pool-size: 20
connection-timeout: 600000
validation-timeout: 120000
idle-timeout: 108000000 # 600000*10*18 = 18hours
max-lifetime: 0 # controlled by idle-timeout
cachePrepStmts: true
prepStmtCacheSize: 350
prepStmtCacheSqlLimit: 2048
useServerPrepStmts: true
**autoCommit:**
auto-commit설정 (default: true)
**connectionTimeout:**
pool에서 커넥션을 얻어오기전까지 기다리는 최대 시간, 허용가능한 wait time을 초과하면 SQLException을 던짐. 설정가능한 가장 작은 시간은 250ms (default: 30000 (30s))
**idleTimeout:**
pool에 일을 안하는 커넥션을 유지하는 시간. 이 옵션은 minimumIdle이 maximumPoolSize보다 작게 설정되어 있을 때만 설정.
pool에서 유지하는 최소 커넥션 수는 minimumIdle (A connection will never be retired as idle before this timeout.). 최솟값은 10000ms (default: 600000 (10minutes))
**maxLifetime:**
커넥션 풀에서 살아있을 수 있는 커넥션의 최대 수명시간. 사용중인 커넥션은 maxLifetime에 상관없이 제거되지않음. 사용중이지 않을 때만 제거됨. 풀 전체가아닌 커넥션 별로 적용이되는데 그 이유는 풀에서 대량으로 커넥션들이 제거되는 것을 방지하기 위함임. 강력하게 설정해야하는 설정 값으로 데이터베이스나 인프라의 적용된 connection time limit보다 작아야함. 0으로 설정하면 infinite lifetime이 적용됨(idleTimeout설정 값에 따라 적용 idleTimeout값이 설정되어 있을 경우 0으로 설정해도 무한 lifetime 적용 안됨). (default: 1800000 (30minutes))
**minimumIdle:**
아무런 일을 하지않아도 적어도 이 옵션에 설정 값 size로 커넥션들을 유지해주는 설정. 최적의 성능과 응답성을 요구한다면 이 값은 설정하지 않는게 좋음. default값을 보면 이해할 수있음. (default: same as maximumPoolSize)
**maximumPoolSize:**
pool에 유지시킬 수 있는 최대 커넥션 수. pool의 커넥션 수가 옵션 값에 도달하게 되면 idle인 상태는 존재하지 않음.(default: 10)
PreparedStatement란:
데이터베이스 관리 시스템(DBMS)에서 동일하거나 비슷한 데이터베이스 문을
높은 효율성으로 반복적으로 실행하기 위해 사용되는 기능을 말할다.
**cachePrepStmts (cachePreparedStatements)**
default: false, recommend: true
MySQL은 PreparedStatement Caching을 비활성화하고 있기 때문에, 이 옵션을 허용해줘야 아래의 옵션값들이 실제 DB에 영향을 줄 수 있다.
**prepStmtCacheSize (preparedStatementsCacheSize)**
default: 25, recommend: 250 ~ 500
MySQL 드라이버가 Connection마다 캐싱할 PreparedStatement의 개수를 지정하는 옵션이다. HikariCP에서는 250 ~ 500개 정도를 추천한다.
**prepStmtCacheSqlLimit (preparedStatementsCacheSqlLimit)**
default: 256, recommend: 2048
MySQL 드라이버가 캐싱할 PreparedStatement의 최대 길이를 지정하는 옵션이다. HikariCP 개발자들의 경험상, Hibernate와 같은 ORM framework를 사용하는 경우에 특히 이 기본값이 턱없이 모자란다고 한다.
**useServerPrepStmts (useServerSidePreparedStatements)**
default: false, recommend: true
Server-Side PreparedStatement를 사용하는 옵션이다. Server-Side Prepared
**PreparedStatement 동작방식**
1. 먼저 애플리케이션은 쿼리 틀을 만들고 이를 DBMS로 보낸다. 특정값은 지정하지 않은 채로 남겨진다
ex) INSERT INTO products (name, age) VALUES (?, ?);
2. 해당 쿼리를 컴파일하며(최적화 및 변환) 아직 실행하지 않고 결과만 저장한다.
3. 나중에 쿼리 틀의 변수에 값을 지정하면 DBMS는 (결과를 반환할 수도 있는) 문을 실행한다. 애플리케이션은 여러 값으로 원하는 횟수만큼 문을 실행할 수 있다.
**Statement와 PreparedStatement차이**
Statement와 PreparedStatement의 아주 큰 차이는 바로 캐시(cache)사용여부이다.
Statement를 사용하면 매번 쿼리를 수행할 때마다 4단계를 거치게 되고(계속적으로 단계를 거치면서 수행)
PreparedStatement는 처음 한 번만 세 단계를 거친 후 캐시에 담아 재사용을 한다는 것이다.
만약 동일한 쿼리를 반복적으로 수행한다면 PreparedStatment가 DB에 훨씬 적은 부하를 주며, 성능도 좋다.
출처
https://webstone.tistory.com/56
https://effectivesquid.tistory.com/entry/HikariCP-%EC%84%B8%ED%8C%85%EC%8B%9C-%EC%98%B5%EC%85%98-%EC%84%A4%EB%AA%85
'JPA & DB' 카테고리의 다른 글
[JPA] mappedby 그리고 join column - 양방향 (0) | 2023.03.02 |
---|---|
JPA 트랜잭션 격리수준 (Isolation Level) 과 락 (Lock) (0) | 2022.01.10 |
JPA Persistence Context 그리고.. Flush / Lazy Loading / N+1 Problem (0) | 2021.11.15 |
Cascade 이해 및 orphanRemoval=true vs CascadeType.REMOVE (0) | 2020.05.15 |
[JPA] 복합키에서 equals () 및 hashCode () 구현하는 이유 (0) | 2020.03.06 |