성능 테스트 도구 알아보기: Silk Performer (6) 결과분석

지난 글에서 다룬 내용 중, ‘Run Test’를 통한 테스트 실행 시 Monitor Tab에서 보여지는 몇가지 지표에 대한 이해가 필요할 것 같아 부연 설명을 덧붙여 진행한 후, 이번 글에서 다루는 마지막 주제인 Silk Performer의 수행 결과를 확인하고 편집하는 방법에 대해 살펴보도록 하겠습니다.

1. Run Test - Monitor

성능 테스트를 실행한다는 것은, 단순히 부하를 발생시킨다는 개념만은 아닙니다. 계획 및 설계단계에서 도출된 Workload를 기준으로, 스크립트 작성 및 이에 맞게 확보된 가상 사용자(구매 또는 기보유 라이선스 활용)에 기반하여, Workload Model에 맞는 정확한 부하 발생이 필요한 단계입니다.

그래서, 성능 테스트 도구에서 테스트가 실행될 때 주요하게 확인하는 부분을 예로 들면,

• 스크립트별로 할당된 가상 사용자들이 Ramp Up 단계를 거쳐 모두 정상적으로 투입되고 부하를 지속 발생 시키고 있는지,

• 부하상황에서 부하발생 장비인 Agent들의 CPU/Memory 과부하 현상은 없는지,

• 평균 응답시간, Transaction 처리(ex. Total TPS, TPS) 등은 목표 수준을 유지하는지,

• Transaction Fail이나 Error 발생 이슈들은 없는지 등 입니다.

지난 글에서 본 바와 같이 ‘Run Test’를 클릭하고 결과 파일명을 저장하면, 우리가 사전에 설정한 가상 사용자(VUser)가 대상 스크립트(ex. 01_MainPage, 02_Login)에 각각 할당되어, 부하를 발생하고 있는 실시간 현황을 우측 Monitor Tab 상단 창에서 보실 수 있습니다. 몇가지 설명이 필요한 지표들에 대해 정리해 보면 다음과 같습니다.

1) Users

부하를 발생하는 ‘사용자 정보’에 대해서는, Users(계획된 전체 사용자수), Running(현재 스크립트를 반복적으로 실행중인 사용자의 증가, 유지, 감소 현황), Failed(오류 등으로 더이상 작동하지 않는 사용자 수)로 구분하여 상태에 대한 정보를 보여줍니다. 이를 통해, 현재 몇몇의 가상 사용자가 실제 부하를 진행하고 있는지를 확인할 수 있습니다.

2) CPU, Memory

부하 발생 Agent들의 자원 사용율을 실시간으로 보여주어, 부하발생 장비 자체의 과부하 여부를 알 수 있습니다. 목표 수준의 부하에 도달하기도 전에 테스트 환경 이슈로 정상적인 부하 시뮬레이션이 어렵게 된다면, 목적에 맞는 성능 테스트 수행 및 결과 분석이 불가능하게 되므로 모니터링이 필요한 요소입니다.

참고로, 노트북 장비나 서버 장비 여러대로 Agent들을 구성하더라도 실제 부하를 발생해 보면 각 장비마다 성능이 고르지는 않기 때문에, 부하 상황(ex. 스크립트별 할당 VUser수 및 Agent 할당)을 고려하여 Agent를 적절히 배치하고, 필요시 상태가 불량한 Agent 장비는 배제한 후 다시 진행할 필요도 있습니다.

3) Tra. Busy Time

Transaction Busy Time이라는 용어가 등장하는데, Silk Performer에서는 우리가 기존에 사용하는 Response Time과 차이를 두어 아래와 같이 정의하고 있습니다.

A busy time is the response time without any think time, wait time, and time necessary for function transformations.

Source: https://www.microfocus.com/documentation/silk-performer/205/en/silkperformer-205-webhelp-en/SILKPERF-B1B1B4B8-CUSTOMTIMERMEASUREMENTS-REF.html

2. Load Test Summary

계획된 성능 테스트 수행 시간이 종료되고 성능 테스트 수행을 마치게 되면, 바로 Silk Performer Workbench 우측에 Load Test Summary라는 결과 요약화면이 나타납니다.

화면 우측 상단에 위치한 ‘Analyze load test’ 버튼을 클릭하여, 성능 테스트 수행 결과 편집을 위한 Silk Performance Explorer 화면으로 이동합니다.

3. Silk Performance Explorer

기본적으로, 수행된 결과에 대한 Overview Report가 Silk Performance Explorer 오른쪽 화면에 자동 생성되어 나타납니다.

4. Chart

위의 자료에서도 충분히 많은 정보를 제공하기는 하지만, (결과서에 담기위한) 우리가 원하는 형태의 결과 편집을 위해서는, ‘Empty Chart’를 새로 생성하여 편집을 진행합니다.

이제부터는, 성능 테스트 수행결과와 관련하여, 빈 차트에 원하는 그래프를 생성하는 방법에 대해 알아보겠습니다.

1) TPS(Transaction Per Second) 그래프 및 데이터

우선 그래프를 생성하는 방법은, Silk Performance Explorer 왼쪽 트리 메뉴에서 원하는 정보를 마우스로 드래그하여, 오른쪽에 새로 생성해 놓은 Empty Chart에 끌어다 놓는 식으로 진행됩니다.

왼쪽의 트리 리스트를 보시면, 우리가 Start Timer/Stop Timer로 잡아놓았던 Transaction(ex. 01_Mainpage, 02_Login)에 대한 측정 결과가 생성되어 있는 것을 보실 수 있습니다. (ex. Client Measures > Overall > Timer > 01_Mainpage)

각각의 Timer에서 하위의 트리메뉴를 더 열어보면, Response Time[s] 하단에 ‘Count’가 보이는데, 이 항목이 각 Transaction별 TPS 측정 결과입니다. (ex. Client Measures > Overall > Timer > 01_Mainpage > Response Time[s] > Count)

마우스로 ‘01_Mainpage’와 ‘02_Login’의 Count를 각각 드래그하여, 오른쪽 Empty Chart로 끌어다 놓으면 성능 테스트 대상 업무별 TPS 차트가 생성됩니다.

이렇게만 하면 TPS 그래프 결과가 대략 완성된 것 같은데, 만들어진 그래프 내용을 가만히 살펴보면 Y축의 눈금과 하단 평균 TPS의 수치 정보가 매치되지 않습니다.

우선, Scale이 자동으로 10으로 설정되어 있으므로, 마우스 오른쪽 클릭으로 Scaling을 선택하여 1로 각각 변경해 줍니다. 다음으로, Y축의 눈금을 TPS 수치와 맞추기 위해, 마우스 오른쪽 클릭으로 Property를 선택한 후 Chart Tab에서 ‘Scale values between 0 and 100’을 체크해제 합니다.

그러면, 아래 그림과 같이 위의 그래프의 눈금과 Avg. TPS 값이 맞추어져 나타나는 것을 확인할 수 있습니다.

그래프 편집 관련 기능들에 대한 보다 상세한 설명이 궁금하신 경우에는, Silk Performer Help의 ‘Customizing Visualization’를 참조하시기 바랍니다.

2) Running User와 Total TPS 그래프

위에서 그래프를 만드는 기본 방법에 대해 알아 보았으므로, 이번에는 사용자 증가 및 유지에 따라 Total TPS가 어떻게 변화하는지를 함께 볼 수 있도록, 두개의 그래프를 한 차트에 담는 방법에 대해 살펴보겠습니다. 이번에도 새로운 차트를 하나 만들어 놓고, 왼쪽의 트리 리스트에서 이동 대상 그래프를 찾습니다.

우선, Running users 그래프의 위치는, Overall > Summary General > Running users입니다. 여기의 ‘Average’를 드래그하여 오른쪽으로 이동시킴으로 Running users 그래프를 생성합니다.

다음으로, Total TPS 그래프의 위치는, Overall > Timer > Overall Response Time > Response time[s]입니다. 여기의 ‘Count’를 드래그하여 오른쪽으로 이동시킴으로 Running users 그래프를 생성합니다.

위에서 언급한 그래프 조정작업을 동일하게 적용하면, 아래와 같은 그래표로 표시됩니다.

위의 파란색이 Running users 그래프로, Ramp up을 시작하여 가상 사용자 10명에 도달후 부하를 지속하는 것을 보실 수 있습니다.

아래의 갈색 그래프는 Total TPS 그래프로, 메인화면 및 로그인 2개 Transaction의 초당 처리건수의 합을 나타내는 그래프입니다. 부하 지속 상태에서 4.5~5.5TPS(Transaction Per Second)를 유지하고 있는 것을 확인할 수 있습니다.

3) Resample

만약, 평균 TPS를 계산할 목적으로 Ramp Up 및 Down 구간을 잘라내고, 부하 유지구간(또는 특정 시간대 구간)만 그래프를 편집하고자 할때는 어떻게 해야 할까요? 직관적으로는 생성된 그래프에 마우스를 대고 오른쪽 버튼을 누르면 무언가 나오지 않을까 해서 이리저리 찾아봐도 관련 메뉴는 보이지 않습니다.

이때는, ‘Resample’기능을 사용합니다.(라고 가이드를 받았습니다.^^) 해당 메뉴는 좌측 결과트리에서 마우스 오른쪽 클릭으로 나타나는 메뉴중 ‘Resample’을 선택하면 나타납니다.

편집하고자 하는 구간만큼 Start Time과 End Time에 시간을 기입한 후 다음 또는 마침을 클릭하면, Resample된 결과 트리가 기존 결과 트리 하단에 새로 생성됩니다.

여기서 다시, 빈차트를 열고, 그래프를 옮기고, Scale등을 조정하는 작업을 거치면, 원하는 시간대 구간이 반영된 그래프가 나타납니다.

참고로, 편집된 그래프 하단에 나타난 TPS Count 정보를 가지고, 평균 TPS를 계산하는 방법에 대해 간단히 설명해 보겠습니다. 위의 그래프의 경우, Duration of simulation을 4분으로 했기 때문에, 그래프 하단의 Count(총 처리건수) Data 정보를 기준으로 TPS를 계산해 보면 다음과 같습니다.

• Mainpage 평균 TPS = 682건 ÷ (4분 x 60초) = 2.841 TPS
• Login 평균 TPS = 498건 ÷ 240초 = 2.075 TPS

4) Response Time 그래프 및 데이터

왼쪽 트리 리스트 중에서 ‘응답시간’에 해당하는 항목은, 각 Transaction 하단의 Response Time[s]에서 ‘Average’입니다. 위에서와 동일한 방법으로 새로운 차트를 만들어 옮겨주면 응답시간 그래프가 완성됩니다.

5. 마무리 글

이상으로, 총 6편의 연재글을 통해 상용 성능 테스트 도구 중 Silk Perfomer를 사용하기 위해 필요한 기본적인 기능들에 대해 알아보았습니다. 가급적 실제적인 사용흐름에 맞게 명확한 가이드를 드리고자, 작성 시 (다시한번) 직접 기능들을 눌러보고 해당 화면들을 캡쳐하면서 내용을 작성했습니다만, 글을 읽으시면서 도구에 대한 기본적인 이해 외에도 여러가지 궁금증만 더 생기셨을지도 모르겠습니다.(사실 저도 그렇습니다. Silk Performer에 구현되어 있는 기능들이 너무 많아서 아직도 안눌러본 버튼들이 많네요.)

지난번에도 언급했지만, 스크립트 단계에서 필요한 추가적인 작업들(ex. Customize session handling, Parameterize input data 등)은 아직 다루지 않았는데, 추후 별도의 ‘Silk Performer 수행 기법’ 글로 구분하여 공유해 보도록 하겠습니다. 아쉬운 대로, Micro Focus에서 제공하는 영상 가이드인 HowTo Customize Session Information in Silk Performer 등을 참조하시면 궁금증 해소에 우선 도움이 되실 것 같습니다.

한편, 테스트 환경 설정 관련해서도 예를 들어 Silk Perpormer Controller와 Agent 간에 방화벽이 존재하는 경우 Port Open이 필요한데, 이러한 부분도 우선 Silk Performer Help를 우선 참조하시고, 추후 ‘수행 기법’에 함께 포함하여 정리해 보도록 하겠습니다.

Agent Connection Establishment Without Firewalls

Source: https://www.microfocus.com/documentation/silk-performer/205/en/silkperformer-205-webhelp-en/GUID-06BAB0C0-9050-48C3-86AE-7B1299CD3289.html

다음주부터는 다시 총 3개 프로젝트의 성능 테스트 지원이 연달아 예정되어 있어서, 3월 이후에나 새로운 글로 만나뵙게 될 것 같습니다. 읽어주셔서 감사합니다. 새해 복 많이 받으세요! ^^

[끝]