의문점
프로젝트를 진행하면서 게시글의 좋아요 수를 증감시키는 기능을 구현했다.
이 프로젝트 내에서 좋아요 수의 정확성이 중요하기 때문에 낙관적 락을 사용하기로 했다.
PESSIMISTIC_WRITE을 사용 할 경우 그 엔티티에 대해 작업 중일 때 다른 곳에서 읽기,수정,삭제가 불가능 하다. 하지만 일반 게시글의 같은 경우 읽기 요청이 들어오는 경우가 많다.
그렇다면 게시글에 대한 UPDATE와 DELETE의 부분에 모두 PESSIMISTIC_READ을 걸어주면 동시성 문제 해결과 읽기에 대한 성능 향상 가능하지 않을까 라는 의문이 생겼다.
테스트 목록
1. 동시 요청에 대한 결과 확인
2. 낙관적 락의 동시 요청에 대한 결과 확인
3. 비관적 락의 PESSIMISTIC_WRITE, PESSIMISTIC_READ 동시 요청에 대한 결과 확인
4. 특정 상황 속 PESSIMISTIC_WRITE와 PESSIMISTIC_READ 성능 비교
동시 요청에 대한 결과 확인
기본적인 환경 세팅은 다음과 같다. 엔티티를 하나 생성하고 1000개의 요청을 동시에 보냈다.
1000개의 요청 중 974개의 요청만 반영되는 결과를 확인할 수 있다.
낙관적 락의 동시 요청에 대한 결과 확인
낙관적 락으로 인해 작업 중인 엔티티에 접근했다는 에러 메시지와 1000개가 전부 반영되지 않은 것을 확인할 수 있다.
비관적 락의 PESSIMISTIC_WRITE 동시 요청에 대한 결과 확인
두 방법 모두 1000개 요청이 들어오는 것을 확인 할 수 있다.
특정 상황 속 PESSIMISTIC_WRITE와 PESSIMISTIC_READ 성능 비교
확실한 결과를 보기 위해 조회수 증가와 게시글의 조회에 각각 1초만에 10000개의 요청을 5번 보내도록했다.
PESSIMISTIC_WRITE를 사용한 경우 평균적으로 PUT에 관한 응답의 속도가 빠른편이다.
결론
조회수 증가를 시키는 것과 게시글을 조회하는 것에 대한 성능은 둘 다 모두 PESSIMISTIC_WRITE를 사용한 경우가 PESSIMISTIC_READ를 사용한 경우 보다 모두 응답 시간이 2배 정도 빠르다.
엔티티를 수정하는 동안 읽기에 대한 락을 해제한다고 해서 읽기에 대한 속도 증가는 보이지 않는다.
두 방식의 요청 모두 회차가 늘어날수록 두 응답에 대한 시간이 줄어드는데 원인을 분석할 필요가 있다.
추가 확인 사항 및 오류
10000개의 요청을 2번째로 보낼 때 비관적락 임에도 불구하고 모든 요청이 들어가지 않은 것을 확인할 수 있다. 쓰레드를 계속 보낼수록 전송에 실패하는 요청들이 늘어나며 이게 스프링의 오류인지 쓰레드를 보내는 프로그램의 문제인지 확일 할 필요가 있다.
위에서의 응답 시간이 줄어듦은 이 오류로 인해 발생한 문제점으로 보인다.
