본문 바로가기
Research/Testing

test_nGrinder의 지표를 성능 테스트 지표로 사용해도 될 것인가에 대한 고민

by RIEM 2023. 2. 28.

들어가기 앞서

팀 프로젝트에서 개발한 어플리케이션의 성능을 측정하기 위해 nGrinder을 사용하고 있다. 성능 테스트 결과 지표를 분석할 때는 TPS, MTT(Mean Test Time)를 각각 Throughput, Latency로 정의하고 있는 상황이다. 그런데 테스트를 진행하면서 과연 이 용어들을 같은 개념으로 봐도 되는 것인지에 대한 의문이 들었다. 팀원분들도 맞다고 하시고 또 블로그 글들을 참고해봐도 다들 이렇게 쓰는 것 같긴 했지만, 이 지표에 대해 확실하게 알고 넘어가지 않으면 안되겠다는 느낌이 자꾸 들었다. 마치 1+1을 사과 + 사과로 배우고 그냥 넘어가버리는 느낌이랄까. 그래서 다시 혹시 놓친 것이 있나 확인하고 정리도 해볼 겸 이 글을 쓰게 되었다.

성능 테스트의 주요 지표

성능 테스트 관련하여 가장 중요한 지표는 Throughput과 Latency다. 아래 내용은 책 <아마존 웹 서비스 부하 테스트 입문>에서 발췌했다.

시스템 성능 지표

  • Throughput(시간당 처리량)
    • RPS(Request/sec) : 1초에 처리하는 HTTP 요청 수 기준이 일반적
    • Network 대역폭 : (고화질 컨텐츠 전송과 같의) 네트워크로 전송되는 데이터 전송률(MB/s)
  • Latency(처리 시간)
    • 사용자 관점에서의 처리 시간
    • 시스템 관점에서의 처리 시간

의문점이 여러가지가 있다

  1. 시간당 처리량을 이 책에서는 RPS, Network 대역폭으로 정의했는데 왜 대체로 웹 상의 자료에서는 Throughput을 TPS으로 부를까? 이 책에서 과연 놓친 것이 있는걸까?
  2. Latency의 KPI는 무엇인가?

한 가지 실마리를 찾은 것은 한 블로그에 따르면 처리량(Throughput)을 표현하는 단위 호칭는 분야마다 각기 다르다고 한다.(https://performance.tistory.com/4)

  • CPU : MIPS, MFLOPS
  • Network : BPS, pps
  • Server: tpmC
  • C/S, TP-Monitor(Transaction Processing Monitor), Mainframe: TPS
  • Storage : IOPS

TPS

TPS는 Transactions per Second 또는 Throughput per second라고 표현하는 곳도 있. 초당 수행한 트랜잭션의 수를 의미하는 TPS(시간당 처리량)은 시스템의 성능을 평가하는 대표적인 지표다.

TPS
= Throughput/Sec
= Transactions 처리 건수 / Sec
= number of response/Sec
= number of request/Sec

= Concurrent / Request Interval

= Number of Active Users/Average Response Time(Sec)

공식은 중복일 수도 있는데, 일단 참고자료에서 언급하는 공식은 모두 나래비했다

Active User
= TPS * Average Response Time(Sec)
= (Concurrent User) * (Average Response Time(Sec)) / Request Interval

Response Time

Response Time
= Clinet Time + Network Time + Server processing/Sending Time

Response Time은 사용자가 요청(클릭)한 이후로부터

응답시간의 유형

  • 평균 응답시간(Avg) : 각 Transaction 별 Response의 평균 응답시간
  • 최소 응답시간(Min) : 각 Transaction 별 Response의 가장 짧은 응답시간
  • 최대 응답시간(Max) : 각 Transaction 별 Response의 가장 긴 응답시간
  • 백분율 응답시간

풀리지 않는 의문

책, 블로그 모두 각자 다른 용어들을 사용해서 혼란스럽다. 우선 nGrinder 테스트 툴을 쓰니 이 툴 관점에서 먼저 알아보는 것이 좋겠다는 생각이 들었다.

Screen Shot 2023-02-28 at 7 25 53 AM

nGrinder QNA의 내용을 발췌했다. 참고로 nGrinder admin님의 답변을 발췌했기에 어느정도 참인 명제로 받아들여도 될 것이다.

vuser 를 늘린다는 것은 로드를 늘린다는 것이고, 로드를 증가시킬때마다 개별 테스트 시간(MTT)이 길어지는 것은 매우 자연스러운 현상입니다.
  • vuser를 늘린다 = 로드를 늘리는 것
  • 로드를 늘린다 = 개별 테스트 시간(MTT)가 길어진다
1. API의 부하테스트 측면에서 MTT가 테스트하는 API의 평균 응답 시간과 같은 개념으로 이해해도 되는지

-> 평균 테스트 시간은 말 그대로 작성하신 스크립트의 @Test 함수의 평균 수행시간을 의미합니다. 따라서 스크립트 내 @Test 함수 내부에서 단순 API 호출만 하고 다른 time consuming 코드가 없을 경우 MTT와 API 평균 응답 시간은 크게 차이가 없다고 보시면 됩니다. 그리고 API 평균 응답시간은 상세 보고서에 나오는 MTTFB(첫번째 바이트 평균 도달 시간) 값으로 보시는게 가장 정확합니다.

2.말씀하시는 로드의 증가가 'API 호출량의 증가'를 의미하시는게 맞는지 궁금합니다.

-> 네 맞습니다.
  • time consuming 코드가 없다면 MTT(Mean Test Time)과 평균 응답 시간(Response time)과 동일하게 봐도 된다. 이 경우 MTT를 Latency로 봐도 된다
TPS는 초당 트랜잭션 개수입니다.
아주 단순하게 본다면 즉 10초간 스크립트가 실행되었다면 그 기간동안 실행된 트랜잭션(record 로 레코딩된)의 개수를 평균하시면 됩니다.
실제로는 각 Sampling Rate 별로 최근 1~5초간에 실행되었던 트랜잭션을 초로 나눠서 초당 트랜잭션을 계산합니다. (이러한 자세한 내용은 이해 안하시는 편이.. ^^)

2013년 글을 찾아보다 내가 정말 궁금해했던 부분과 동일한 질문을 한 사람의 글을 보았다.

Q
윗 글의 댓글 중에서 몇회 이상 지속적으로 발생하지 않으면 데이터 자동 복구라고 하셨는데,
테스트 도중 여러번 지속적으로 발생하여 데이터 유실이 생길 경우,
데이터의 신뢰성을 믿을 수 없을 것으로 판단되는데,
혹시 최대한 자료가 유실 되지 않고 테스트를 할 수 있는 설정법이 있는지 궁금합니다.

그리고 MTT(Mean Test Time)에 대한 의미가 궁금합니다.
주로 성능 테스트를 할 때 보는 수치가 TPS와 Response Time 인데,
nGrinder에는 TPS는 있는데 Response Time이 없네요.
MTT를 Response Time과 유사한 개념으로 생각하면 되는건가요?

계속 좋은 답변 해주셔서 너무 감사합니다.
nGrinder를 사용하는데 큰 도움이 되고 있습니다.
A
데이터 유실은 다음 2가지에서 생길 수 있습니다.

1. 초당 전송되는 에이전트 CPU / 메모리 수치
2. 초당 전송되는 샘플링 결과

1번이야.. 문제가 않될 거구요. 2번의 경우가 문제가 될 수 있는데..
그래프 상에 약간의 왜곡이 생길 수는 있겠으나, 누적치에는 영향을 미치지 않습니다.
그래도 만약 이러한 왜곡을 최소화 하고 싶다면 에이전트/컨트롤러 리눅스로 전환하세요.
리눅스에서는 에러 발생 가능성이 더 적습니다.

Response Time 있습니다. Response Time 을 뭘로 보냐에 따라 좀 다른데..
첫번째 바이트 도달 시간을 Response Time 으로 보실수도 있고, 이 항목은 이미 nGrinder 에서 제공하고 있습니다.
만약 마지막 바이트 도달 시간을 체크하고 싶으시다면, 사용자 그래프를 정의하시고 처리하셔야 합니다.

http://junoyoon.tistory.com/entry/nGrinder-HTTP-Reponse-%EC%9D%BC%EB%B6%80%EB%A7%8C-%EC%9D%BD%EC%96%B4%EC%98%A4%EA%B8%B0
로 직접 Response 를 읽어오시게 처리하시고,

http://www.cubrid.org/wiki_ngrinder/entry/user-defined-statistic-in-ngrinder
를 사용하여 해당 시간을 기록하시면 될겁니다.

그러나 한개의 단순 URL만을 테스트할 경우 MTT와 Response Time 이 거의 같은 값을 가지게 됩니다.
  • 내가 궁금해 했던 질문의 요지는 성능 테스트 시 참고하는 주요 지표가 TPS, Response Time인데, nGrinder에서는 TPS는 있는데 Response Time이 없다. MTT를 Response Time으로 보면 되냐?이다.
  • 이에 대한 admin 님의 답변은 Response Time을 어떻게 정의하느냐에 따라 다르다고 하는데, 첫번째 바이트 도달 시간으로도 볼 수 있다고 한다. 리포트에서 제공하는 CSV 파일을 참고해보니 MTT나 첫번째 바이트 도달 시간 간 극히 미세한 차이만 있다.

Screen Shot 2023-02-28 at 7 17 32 AM

결론

성능 테스트의 주요 지표는 Through, Latency 지표들이다. 1)Through는 시간당 처리량을 의미하는데 주로 TPS(Transaction per Secons)를 참고하는데, 이는 nGrinder에서 제공하는 지표다. 2)Latency라는 지표는 nGrinder에서 제공하지 않는데, admin 님의 말에 따르면 관점에 따라 다르게 볼 수 있지만, time consuming 코드가 없다면 MTT(Mean Test Time)과 평균 응답 시간(Response time)과 동일하게 봐도 된다고 한다. time consuming 코드가 따로 없이 바로 요청을 하는 방식으로 테스트하고 있기 때문에 MTT를 Latency(Response time)로 정의해도 괜찮다는 결론을 내리게 되었다.

링크

저작자표시

'Research > Testing' 카테고리의 다른 글

nGrinder_ Body JSON Post 요청 보내기  (0) 2023.03.06
성능 이론_처리량과 응답 시간  (1) 2023.02.28
부하테스트 단계와 발생 문제 유형  (1) 2023.02.24
Test_AB(Apache Benchmark)로 간단히 테스트하기  (0) 2023.02.23
성능 테스트란 무엇일까  (0) 2023.02.23

관련글

댓글

티스토리툴바