현재 버전

메시지큐는 해결방법이 아닐겁니다.

 (해결도 안될뿐더러 또다른 이슈 양산할 가능성이 다분)

0. 커넥션 풀 확인(capacity는 적정한지.leack은 없는지)

1. 일단 부하발생하는 SQL 확인 및 튜닝

2. 어플리케이션 캐시 도입 (공통코드라던지 자주 변경이 없음에도 계속 조화되는 부분, 왜민한 DAO프레임워크에는 캐시기능이 있음)

3. DB서버 설정 및 커널 패라미타 튜닝 (제일 마지막)


ps mysql이고 inser량이 많은 경우면 innodb_flush_log_at_trx_commit  옵션도 한번 타협해볼만합니다. (살을 주고 뺘를 취하는 전략이라 보통은 안씀)


수정 이력

2021-07-19 19:09:00 에 아래 내용에서 변경 됨 #5

메시지큐는 해결방법이 아닐겁니다.

 (해결도 안될뿐더러 또다른 이슈 양산할 가능성이 다분)

0. 커넥션 풀 확인(capacity는 적정한지.leack은 없는지)

1. 일단 부하발생하는 SQL 확인 및 튜닝

2. 어플리케이션 캐시 도입 (공통코드라던지 별자주 변경이 없음에도 계속 조화되는 부분, 왜민한 DAO프레임워크에는 캐시기능이 있음)

3. DB서버 설정 및 커널 패라미타 튜닝 (제일 마지막)(


ps mysql이고 inser량이 많은 경우면 innodb_flush_log_at_trx_commit  옵션도 한번 타협해볼만합니다. (살을 주고 뺘를 취하는 전략이라 보통은 안씀)

2021-07-19 08:57:29 에 아래 내용에서 변경 됨 #4

메시지큐는 해결방법이 아닐겁니다.

 (해결도 안될뿐더러 또다른 이슈 양산할 가능성이 다분)

0. 커넥션 풀 확인(capacity는 적정한지.leack은 없는지)

1. 일단 부하발생하는 SQL 확인 및 튜닝

2. 어플리케이션 캐시 도입 (공통코드라던지 별자주 변경이 없음에도 계속 조화되는 부분, 왜민한 DAO프레임워크에는 캐시기능이 있음)

3. DB서버 설정 및 커널 패라미타 튜닝 (제일 마지막)(


ps mysql이고 inser량이 많은 경우면 innodb_flush_log_at_trx_commit  옵션도 한번 타협해볼만합니다. 

2021-07-19 08:56:18 에 아래 내용에서 변경 됨 #3

메시지큐는 해결방법이 아닐겁니다.

 (해결도 안될뿐더러 또다른 이슈 양산할 가능성이 다분)

0. 커넥션 풀 확인(capacity는 적정한지.leack은 없는지)

1. 일단 부하발생하는 SQL 확인 및 튜닝

2. 어플리케이션 캐시 도입 (공통코드라던지 별자주 변경이 없음에도 계속 조화되는 부분, 왜민한 DAO프레임워크에는 캐시기능이 있음)

3. DB서버 설정 및 커널 패라미타 튜닝 (제일 마지막)(mysql이고 inser량이 많은 경우면 innodb_flush_log_at_trx_commit  옵션도 한번 타협해볼만합니다. )

2021-07-19 08:56:04 에 아래 내용에서 변경 됨 #2

메시지큐는 해결방법이 아닐겁니다.

 (해결도 안될뿐더러 또다른 이슈 양산할 가능성이 다분)

0. 커넥션 풀 확인(capacity는 적정한지.leack은 없는지)

1. 일단 부하발생하는 SQL 확인 및 튜닝

2. 어플리케이션 캐시 도입 (공통코드라던지 별자주 변경이 없음에도 계속 조화되는 부분, 왜민한 DAO프레임워크에는 캐시기능이 있음)

3. DB서버 설정 및 커널 패라미타 튜닝 (제일 마지막, mysql이라면 tx_log xxx 옵션도 한번 타협해볼만한. )

2021-07-19 08:52:52 에 아래 내용에서 변경 됨 #1

메시지큐는 해결방법이 아닐겁니다. (또다른 이슈 양산할 가능성이 디분)

0. 커넥션 풀 확인(capacity는 적정한지.leack은 없는지)

1. 일단 부하발생하는 SQL 확인 및 튜닝

2. 어플리케이션 캐시 도입 (공통코드라던지 별자주 변경이 없음에도 계속 조화되는 부분, 왜민한 DAO프레임워크에는 캐시기능이 있음)

3. DB서버 설정 및 커널 패라미타 튜닝 (제일 마지막, mysql이라면 tx_log xxx 옵션도 한번 타협해볼만한. )