2021.09.14 기록장

ToDo

• 알고리즘 문제 풀기
• 책 읽기
•  

Done

• 책 읽기

Weekly goal

• 책 읽기

 

real mysql

 

150p. 슬로우 쿼리 로그

 mysql은 서비스 운영 전, 운영 중에 성능을 검사할 수 있는데, 전자는 모두 검사를 해서 튜닝하면 되지만, 후자는 어떤 쿼리가 문제의 쿼리인지 판단하기가 쉽지 않다.

 mySQL에서는 슬로우 쿼리 로그를 제공하는데 이는 시스템 변수 long_query_time에 설정한 값( 초에서 마이크로 초까지 가능)을 초과하는 쿼리를 로그에 기록하는 것이다.

여기에는 쿼리 실행 시간부터 락이 걸린 시간도 알 수 있다. 근데 이 lock이 걸린 시간은 mysql엔진이 관장하는 테이블 lock만 시간을 잰다. 또 락을 실행할지 말지 검사하는 시간도 들어간다. lock 걸린 시간이 0.0001초 정도이며 테이블에 lock을 건 거보다는 검사하는 시간이라 봐도 무방하다.

 

159p. 트랜잭션의 범위

 

여태 spring에서 트랜잭션을 사용할 때 단순히 하나의 메서드에서 모든 일을 하고 트랜잭션 어노테이션을 걸었었다.

예로

1) 처리 시작

--> 데이터 베이스 커넥션 생성

--> 트랜젝션 시작

2) 사용자의 로그인 여부 확인

3) 사용자의 글쓰기 내용의 오류 여부 확인

4) 첨부로 업로드된 파일 확인 및 저장

5) 사용자의 입력 내용을 DBMS에 저장

6) 첨부 파일 정보를 DBMS에 저장

7) 저장된 내용 또는 기타 정보를 DBMS에서 조회

8) 게시물 등록에 대한 알림 메일 전송

9) 알림 메일 발송 이력을 DBMS에 저장

<-- 트랜잭션 종료

<-- 데이터 베이스 커넥션 반납

10) 처리 완료

 

이 모든 것을 트랜잭션 하나에 넣는 것은 옳지 않다. 프로그램 코드가 데이터 베이스 커넥션을 가장 적게 가지고 있는 것이 좋으며 트랜잭션의 활성화 범위를 적게 가져가야 한다는 것이다. 그래야 대기 시간이 줄기 때문이다.

 

위의 예에서 진짜 트랜잭션이 필요한 부분은 5~6, 8~9 부분이다.

 

또 메일 발송을 트랜잭션에 넣는 것은 좋지 않다. 만약 프로그램이 파일 전송 등 원격 서버와 통신은 메일 서버와 통신 불가 상황이 나면 웹 서버뿐 아니라 DBMS까지 위협하게 된다.