인증번호를 MySQL에 저장하고 조회하는 것에서 Redis에 저장, 조회로 변경했다.
단기간 사용할 데이터이기도 하고 빠른 조회의 속도가 장점이길래 한 번 도입해봤는데, 트래픽이 적은 입장에서 빨라졌는 지 체감이 되질 않는다.
시도한 방법
0. 단순히 API를 여러번 돌려봤다.
: SMTP를 통해 메일 전송까지 하는 API이다 보니 해당 소요시간은 DB차이를 체크하기에 너무 부적합했다.
1. 시스템시간을 DB 저장 메소드 실행 전 후 기록해서 차이를 log로 출력
: 아래처럼 save메소드 앞뒤로 시스템 시간을 변수로 담아 그 차이를 출력 해봤다.
long beforeTime = System.currentTimeMillis(); // DB 저장 전 시간
VerificationCode verificationCode = new VerificationCode(email, code);
verificationCodeRepository.save(verificationCode); //DB 저장
long afterTime = System.currentTimeMillis(); // DB 저장 후 시간
log.info("실행시간 : "+ (afterTime - beforeTime)); //로그 출력MySQL저장
처음엔 47ms, 이후엔 계속 해서 2ms가 나온다.
2. 나노타임으로 수정
: 좀 더 세밀한 체크를 위해 nanoTime, 나노초를 체크하는 메소드로 변경했다.
long afterTime = System.nanoTime();
MySQL저장
예를 들어 21201500ns 는 21.2ms 이다.
최대값과 최소값을 제외한 평균은 3.01ms로 나왔다.
Redis 저장
평균 2.37ms
그렇게 눈에 띄는 차이는 아니었다.
발견한 문제점
계속해서 API 요청을 보낼 때 Redis에 저장될 같은 값을 보내줘서, 새로운 추가가 아닌 수정의 동작만 이루어진 듯하다.
Redis 서버의 log를 보니까 DEL 이후에 다시 HMSET된걸로 보아 수정은 아닌듯 하다.
뭔가 클라우드라서 더 그런가 싶다.
로컬서버로 다시
같은 값으로 보냈을때
새로운 값으로 저장할 때
SADD명령어가 추가된다.
다시 똑같은 값으로 저장해서 SADD명령어가 없어도 시간은 비슷하다.
너무 시간이 길어져서 튜터님과의 면담 후 이어가보도록 한다.
튜터님 Says
Redis는 쓰기보다는 읽기 동작이 굉장히 빠르다
내일 다시 테스트와 더불어 Redis의 특징을 다시 복습해보고자 한다.
