접속자 대기열 시스템 #9- 테스트

2024. 10. 10. 18:35·프레임워크/자바 스프링

waiting-web은 9000포트, waiting-api 9010포트로 각 서버를 실행합니다.

터미널 혹은 콘솔을 2개 띄어줍니다. 그리고 하나는 redis 모니터링을 하도록합니다.
그리고 남은 하나는 users:queue:default:wait, users:queue:default:proceed 큐에 몇개의 데이터가 있는지 1초마다 sleep하고 이후 무한히 반복됩니다.

JMeter를 이용하여 테스트를 진행합니다.

아래 이미지와 같이 세팅해줍니다.

1. Thread Group 설정

  • Number of Threads (Users): 30명으로 설정되어 있으며, 이는 30명의 가상 사용자가 동시에 요청을 보낸다는 의미입니다.
  • Ramp-up Period (Seconds): 10초 동안 점진적으로 30명의 가상 사용자를 추가합니다. 즉, 매초 3명의 사용자가 추가됩니다.
  • Loop Count: 'Infinite'로 설정되어, 테스트가 종료될 때까지 요청을 계속 반복합니다.

2. HTTP Request 설정

  • Protocol: http로 설정되어 있으며, 요청은 HTTP 프로토콜을 사용합니다.
  • Server Name or IP: localhost로 지정되어 있어, 로컬 서버를 대상으로 테스트하고 있습니다.
  • Port Number: 9010번 포트로 요청을 보냅니다.
  • HTTP Request Method: GET 메서드를 사용하여 /waiting-room 경로로 요청을 보냅니다.
  • Parameters:
    • user_id: 랜덤하게 생성된 숫자 값(1-999999)로, 다양한 사용자 ID를 시뮬레이션합니다.
    • redirect_url: http://localhost:9000로 설정되어 있습니다.

3. Summary Report

  • # Samples: 총 요청 횟수는 133100회이며, 모든 요청이 성공했습니다. Error %는 0%로 오류가 없는 상태입니다.
  • Average, Min, Max, and Std. Dev: 평균 응답 시간은 9ms, 최소 응답 시간은 3ms, 최대 응답 시간은 71ms입니다. 응답 시간의 표준 편차는 3.45ms로, 응답 시간이 비교적 일정하다는 것을 의미합니다.
  • Throughput: 초당 약 2958.5개의 요청이 처리되고 있습니다.
  • Received KB/sec & Sent KB/sec: 수신된 데이터는 약 13509.5KB/초이며, 전송된 데이터는 약 513.95KB/초입니다.

4. Transactions per Second

  • 그래프 분석:
    • 테스트 시작 후 약 10초 동안 트랜잭션 수가 점진적으로 증가하며, 이후에는 일정한 수준(약 3600 TPS)으로 유지됩니다.
    • 트랜잭션 수의 변동은 시스템 부하에 따라 다소 변화가 있음을 나타냅니다.

5. Response Latencies Over Time

  • 그래프 분석:
    • 응답 시간이 대체로 7ms~9ms 사이에서 유지되며, 간헐적으로 10ms를 넘는 경우도 관찰됩니다.
    • 응답 시간의 변동은 요청 수와 서버의 처리 성능에 따라 발생할 수 있습니다.

6. Response Codes per Second

  • 그래프 분석:
    • 모든 요청이 200 응답 코드를 반환하며, 초당 약 3600개의 요청이 성공적으로 처리됩니다.
    • 일정한 수준에서 응답 코드가 유지되고 있어, 서버의 안정적인 처리를 의미합니다.

 

Thread Group을 Infinite로 체크한 것을 해제하고 100으로 설정합니다. 
그리고 localhost:9000?user_id=1000 으로 하고 접속하면 아래와 같이 이미지가 나타납니다. 

 

 

 

종합 분석

  • 성능 요약:
    • 테스트에서 오류 없이 모든 요청이 성공했으며, 응답 시간이 비교적 짧고 일관된 수준을 유지하고 있습니다.
    • 초당 3600개 이상의 요청을 처리하는 능력을 보였으며, 서버의 안정성과 처리 성능이 양호합니다.
  • 추가 고려 사항:
    • 부하를 더욱 높여 스레스 테스트를 진행하거나, 실제 사용자의 접속 패턴을 시뮬레이션하여 다양한 환경에서 성능을 평가할 필요가 있습니다.

이러한 JMeter 설정을 통해 대기열 시스템의 성능을 확인하고 최적화 방향을 찾을 수 있습니다.

저작자표시 (새창열림)

'프레임워크 > 자바 스프링' 카테고리의 다른 글

접속자 대기열 시스템 #8- 대기열 이탈  (0) 2024.10.10
접속자 대기열 시스템 #7- 대기열 스케줄러 개발  (0) 2024.10.10
접속자 대기열 시스템 #6- 접속 대기 웹페이지 개발  (1) 2024.10.10
접속자 대기열 시스템 #5- Redis를 이용한 대기열 관리 및 웹페이지 진입 API 구현  (1) 2024.10.10
접속자 대기열 시스템 #3- 셋업  (2) 2024.10.10
'프레임워크/자바 스프링' 카테고리의 다른 글
  • 접속자 대기열 시스템 #8- 대기열 이탈
  • 접속자 대기열 시스템 #7- 대기열 스케줄러 개발
  • 접속자 대기열 시스템 #6- 접속 대기 웹페이지 개발
  • 접속자 대기열 시스템 #5- Redis를 이용한 대기열 관리 및 웹페이지 진입 API 구현
hyeseong-dev
hyeseong-dev
안녕하세요. 백엔드 개발자 이혜성입니다.
  • hyeseong-dev
    어제 오늘 그리고 내일
    hyeseong-dev
  • 전체
    오늘
    어제
    • 분류 전체보기 (286)
      • 여러가지 (107)
        • 알고리즘 & 자료구조 (72)
        • 오류 (4)
        • 이것저것 (29)
        • 일기 (1)
      • 프레임워크 (39)
        • 자바 스프링 (39)
        • React Native (0)
      • 프로그래밍 언어 (38)
        • 파이썬 (30)
        • 자바 (3)
        • 스프링부트 (5)
      • 컴퓨터 구조와 운영체제 (3)
      • DB (17)
        • SQL (0)
        • Redis (17)
      • 클라우드 컴퓨팅 (2)
        • 도커 (2)
        • AWS (0)
      • 스케쥴 (65)
        • 세미나 (0)
        • 수료 (0)
        • 스터디 (24)
        • 시험 (41)
      • 트러블슈팅 (1)
      • 자격증 (0)
        • 정보처리기사 (0)
      • 재태크 (5)
        • 암호화폐 (5)
        • 기타 (0)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    Python
    자바
    #개발자포트폴리오 #개발자이력서 #개발자취업 #개발자취준 #코딩테스트 #항해99 #취리코 #취업리부트코스
    그리디
    SAA
    항해99
    파이썬
    WebFlux
    java
    FastAPI
    Spring Boot
    AWS
    reactor
    Redis
    Docker-compose
    Spring WebFlux
    완전탐색
    RDS
    spring
    mybatis
    백준
    OOP
    취업리부트
    프로그래머스
    ecs
    DP
    celery
    EC2
    docker
    시험
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.0
hyeseong-dev
접속자 대기열 시스템 #9- 테스트
상단으로

티스토리툴바