전체 글

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..

1. Redis Temporary Location For Speed 데이터의 원래 소스보다 더 빠르고 효율적으로 액세스할 수 있는 임시 데이터 저장소 많은 애플리케이션에서 속도 향상을 위해 캐시를 이용한다. 당연히 속도를 높이려면 원본에 접근하는것보다 캐시에 접근하는게 빨라야 한다. 그리고 데이터의 반복적 액세스가 많아질수록 캐시를 사용하는게 유리하다. 아래와 같은 특징을 가진다. 단순한 key-value 구조 In-memory 데이터 저장소 (RAM) 빠른 성능 평균 작업속도 < 1ms 초당 수백만 건의 작업 가능 이외에도 최신 버전의 Redis는 데이터 저장뿐만 아니라 PUB/SUB 구조를 통해 메시지를 전달하는 용도로도 사용 가능하다. Redis는 메모리에 데이터를 저장하기 때문에 저장 공간에 제약..

1. 성능 최적화 계기 현재 프로젝트는 예약과 관련하여 시간을 많이 다루고 있다. 따라서, DATETIME 타입의 컬럼을 범위 비교 또는 동등 비교하여 조회하는 쿼리가 많이 존재하였다. 해당 컬럼에 대해 인덱스를 지정하여 성능 최적화를 할 수 있을것 같아 Real MySQL 8.0의 도움을 받아 시도해보았고 기간별 예약 내역 조회 쿼리에 대해 1374% 향상을 보게 되었다. 2. 문제의 쿼리 문제의 아래 쿼리는 기간별로 예약 내역을 조회하는 쿼리이다. where절에서 DATETIME 타입의 예약 시작날짜시간에 해당하는 start_at 컬럼에 대해 BETWEEN 연산을 진행한다. 나는 start_at 컬럼에 대해 Index를 적용해보고자 했다. select reservatio0_.project_table_..

일반적으로 웹 서비스와 같이 일반적인 온라인 트랜잭션 처리 환경의 DB에서는 INSERT나 UPDATE 작업의 경우 거의 레코드 단위로 발생하므로 성능상 문제가 되는 경우가 거의 없다. 하지만, SELECT의 경우 여러 개의 테이블로부터 데이터를 조합해서 빠르게 가져와야 하기 때문에 주의를 기울여야 한다. 따라서, SELECT 쿼리의 각 부분에 사용될 수 있는 기능을 성능 위주로 살펴보고자 한다. 1. SELECT 절의 처리 순서 아래와 같은 다양한 키워드를 이용한 SELECT 문이 존재한다. 이런 경우 어떠한 절이 먼저 실행되는지 예측해야 최적화를 할 수 있다. SELECT, FROM, WHERE. GROUP BY, HAVING, ORDER BY, LIMIT SELECT s.emp_no, COUNT(D..

애플리케이션에서 데이터를 저장 또는 조회하기 위해 DB와 통신할 때 DB 서버로 전달되는 것은 SQL 뿐이다. SQL은 어떠한(What) 데이터를 요청하기 위한 언어이지, 어떻게(How) 데이터를 읽을지를 표현하는 언어는 아니므로 자바와 같은 언어와 비교했을 때 제한적으로 느껴질 수 있다. 그래서 쿼리가 빠르게 수행되게 하려면 DB 서버에서 쿼리가 어떻게 요청을 처리할지 예측할 수 있어야 한다. 애플리케이션 코드를 튜닝해서 성능을 개선한다는 것은 쉽지 않지만, DBMS에서는 몇십 몇백 배의 성능 튜닝은 흔한 일이다. 따라서 SQL 작성 방법이나 규칙은 물론, 내부적인 처리 방식(옵티마이저)에 대해 공부해야 한다. 1. MySQL 연산자 (1) 날짜 다른 DBMS에서 날짜 타입을 비교하거나 INSERT하려..