230418 Today I Learned

실전 프로젝트 3주차. 어제 Redis로 공유자원 관리 로직을 구현한걸 오늘 jmeter로 테스트 해봤다.

Redis 테스트

• Post요청 예매하기
  jmeter를 사용해서 10000 쓰레드로 예매하기 API에 동시에 요청을 보냈다.
  DB에서 처리하던걸 Redis에서 처리하도록 로직을 변경했다.
  

10000명에서 반응속도 49368ms에서 11492ms로 줄어 약 76% 정도의 속도 개선 효과가 있었다.
tps 77 → 333으로 약 4.3배 향상되었고, 오류율 14.6%에서 0%까지 줄었다.
데이터 정합성(남은 좌석 수)도 전부 일치했다.

• get 요청 상세 페이지 조회
  jmeter를 사용해서 10000 쓰레드로 상세 페이지 조회 API에 동시에 요청을 보냈다.
  누가 조회하면 1시간동안 캐시가 유지되는 식으로 구현되었다.
  

22848ms → 505ms 처리량
176tps →786tps
오류율은 둘다 0%
속도 개선 약 97.8%

• 무한루프 테스트
  5번째 테스트에서는 100명 무한루프시 300~500tps 였으나
  이번 6번째 테스트에서는 1000명~3000명 무한루프에도 700~800tps 정도 나옴
  → 추후 스케일아웃 등을 통해서 더 개선 가능 할지도

• 추후 개선사항
  20000명이상 요청이 늘어날 시 java.net.BindException: Address already in use: connect 에러가 발생해서 오류율이 20%이상 증가했다. 이 부분은 추가로 알아봐야 한다.
  그리고 캐시서버가 다운되었을 경우나 정합성이 맞지 않을경우, 그외 예외처리에 대해서 좀 더 공부해봐야 한다.

• 테스트 전만해도 공유자원을 굳이 Redis로 관리를 해야되나라고 생각했지만 생각보다 응답 속도 개선이 너무 잘 되어서 이 로직을 유지하려고 한다. 불안정할 수 있는 로직이니 생각지 못한 변수가 더 있는지 여러방면으로 생각해서 안정적으로 유지하도록 해봐야 겠다.