Home

Welcome to the Github-Action-Test wiki!

리뷰

• 캠핑장 리뷰 조회 5분 간격

  • users 100

  

  

  • users 200

  

  

  • users 300

  

  

  • users 400

  

  

  • users 500

  

  backend ec2

  

  lb 대상 응답 시간

  

  

  db ec2

  

  lb 요청

  

• 리뷰 수정 5분 간격 (이상)

  • users 100 / 1 (10분)

  

  

  • users 100/ 10

  

  

  • users 200 / 10

  

  

  • users 300 / 10

  

  backend ec2

  

  lb 대상 응답 시간

  

  

  db ec2

  

  • FAILURE

    

    

  • 이슈

    • RPS가 저조함
    • USER 200부터 실패율이 크게 증가 ( 501, 504 에러 )
    • DynamoDB 처리에 문제 발생
    • 응답 시간이 들쭉날쭉 함

  • 분석

    • 트랜잭션 어노테이션이 dynamoDB에서 온전하게 작동하지 않은 거 같음
    • 한 번의 요청에 리뷰, 마이리뷰, 별점평균 총 3개의 테이블 연산이 포함된 것도 부하의 원인인 거 같음
    • 조회 시 생성일로 정렬하는데, 생성일은 인덱스 설정이 되지 않아 조회 성능이 떨어지는 거 같음

  • 개선 방안

    • DynamoDB의 TransactWriteItems 또는 TransactGetItems 작업 등을 시도
    • existsByUserIdAndCampId 메서드 성능 개선을 위한 userId, campId 복합 인덱스 고려
    • 캐시 도입해서 캐시에서 값 변동 후 db 업데이트는 나중
    • 리뷰 수정 과정에서 실행되는 각 과정의 실행 시간을 측정하여 병목 지점 파악
    • 업데이트 요청 시 요청된 값들이 db나 캐시에 저장된 값과 일치하다면 리턴시키기
    • 리뷰 아이디와 생성일 복합 인덱스 설정

• 나의 리뷰 조회 5분 간격

  • users 100 /10

  

  

  • users 200 /10

  

  

  • users 300 /10

  

  

  • users 400 /10

  

  backend ec2

  

  lb 대상 응답 시간

  

  

  db ec2

  

  lb 요청 수

  

  • users 500 /10

  • 이슈

    • 응답속도가 높아 rps가 저조함
    • 유저가 많아질수록 응답속도도 높아
    • cpu 모니터링 확인 결과 backend ec2의 cpu 점유율이 테스트 초반부터 100% 도달된 상태였음

  • 분석

    • 사용자에게 3988개의 캠핑장 리뷰를 작성해놔서 3988개의 reviewId로 Review 테이블에서 모든 값을 조회하여 페이징 처리를 하는 게 오래걸리는 거 같음
    • cpu 점유율이 시작부터 100%에 도달해있었다는 것도 원인인 거 같음

  • 개선 방안

    • cpu 점유율이 낮아진 거 확인 후 다시 테스트 해봐야 할듯

• 나의 리뷰 조회 5분 간격 (cpu 점유율 확인 후 다시 진행)

  • users 100

  

  backend ec2

  

  lb 대상 응답 시간

  

  

  db ec2

  

  lb 요청 수

  

  • 분석
    • 테스트 실행 시 user 100명에서도 서버와 db cpu 점유율이 높은 편임이 확인 됨
    • 이게 작성된 리뷰를 조회하는 과정에서 발생하는 것인지 확인하기 위해 리뷰가 적은 유저를 대상으로 다시 한 번 테스트 진행

• 나의 리뷰 조회 5분 간격 (작성 리뷰 1개인 유저 대상)

  • users 100

  

  

  • users 200

  

  

  • users 300

  

  

  • users 400

  

  

  • users 500

  

  backend ec2

  

  lb 대상 응답 시간

  

  

  db ec2

  

  lb 요청 수

  

  • 이슈
    • rps 100이 넘어가면서 응답 속도가 불안정해지고 유저수가 늘어나도 200을 못넘음
    • rps가 200에 근접하면서 응답 속도가 크게 튀기 시작하고 유저수가 500명일 떄 응답속도가 현저히 느려짐
    • cpu 점유율은 작성된 리뷰가 많은 유저에 비해 안정적임
  • 분석
    • 작성된 리뷰 수가 많을 때에 비해 cpu 점유율이 안정적인 걸로 보아 모든 리뷰를 페이징해 가져오는 현재 로직이 서버에 부하를 많이 주는 거 같음
    • 한 페이지에 필요한 것보다 훨씬 많은 데이터를 db에서 받아옴
    • 등록 리뷰가 많아지면 리뷰 테이블에서 조회 시 IN절에 사용하는 reviewId 리스트의 크기가 커짐
    • 리뷰가 하나 뿐인 유저의 리뷰를 불러오는 요청도 요청 수가 늘어나면서 응답 속도가 불안정해지는 건 보아 서버의 처리 용량이 문제인지 페이징 로직이 문제인지는 테스트를 더 진행해봐야 알 것 같음
  • 개선 방안
    • 리뷰 등록할 때마다 리스트로 저장해서 리스트 자체로 조회하는 기존 로직 개선 고려
    • 캐시 적용 고려