redis

1. 성능 최적화 계기 현재 관리자 페이지에서 예약 내역을 페이징 처리하여 조회할 수 있는 기능이 있다. limit는 20으로 한 페이지당 20개의 예약 컨텐츠를 보여주고 있다. 전체 예약 데이터는 354,200개인 상황이고 해당 API의 성능이 평균적으로 1.74초의 시간이 걸렸고 최대 1.99초까지 걸림으로써 성능이 좋지 못했다. 해당 성능을 최적화할 수 있는 방법을 모색하기 시작했다. 미리 말하자면, 평균 56.2%의 성능향상을 맛보게 되었다! 2. 반복되는 Count Query를 개선해보자! 해당 부분에서 성능을 최적화할 수 있는 부분으로 가장 눈에 띈것은 매번 반복되는 전체 데이터의 수를 측정하는 Count Query였다. "굳이 Count Query가 페이지마다 매번 반복될 필요가 있을까?" ..

1. 토큰 재발급에 저장공간이 필요한 이유 현재 JWT 인증방식을 적용하고 있다. 해당 방식의 플로우는 대략 아래와 같다. 로그인시 Access Token과 Refresh Token이 발급된다. 권한이 필요한 API의 경우 header에 Access Token을 추가하여 요청한다. Access Token이 만료된 경우에는 Refresh Token을 통해 Access Token과 Refresh Token 모두 재발급 받는다. 이러한 절차 과정에서 토큰을 저장할 공간이 필요하다. 현재 사용하고 있는 RDBMS인 MariaDB를 사용한 경우와 Redis를 사용한 경우 기능, 성능적 차이를 비교해보았다. 아래는 최종 비교 결과이다. Redis에 대해 자세히 알고 싶으면 이전에 작성한 포스팅을 참고하자! 2023..