Solution/JMeter

[JMeter] KostaEdu Scouter를 사용한 JMeter 실습 과정 (2/3)일차

KKuGii 2023. 3. 30. 19:45
728x90

#####.목적에 따른 분류

 

ㅁ.성능 테스트 목적은 성능 측정, 결함 검출, 용량 검증, 병목 제거
-부하 모델링을 하는 것이 어려운 것
-보통 병목은 DBMS에서 commit을 하지 않으면 다른 사람들이 lock이 된다.
-서버의 용량은 현실 세계에서 일어나는 모델보다 조금 더 많이 주어도 된다.

ㅁ.단위 성능 : 특정 기능 하나만 단위 하나만 부하 테스트를 하는 것
-기능 하나하나가 잘 작동하는지 검증하는 것
-가상의 사용자지만 실제 유저처럼 행동하도록 시뮬레이션을 짜야한다.


ㅁ.통합성능테스트 : 가장 많이 사용한 시간대에 호출된 업무들을 리스트업
-부하 비율 산정, 업무 비율별로, 가상유저 별로 테스트 하는 것이다. TPS 임계치까지

 

ㅁ.임계성능 테스트
-TPS를 조금씩 늘려가면서 최대 TPS를 알아가는 테스트
-임계 TPS를 확인하면 임계점이 오는 이유가 뭔지 파악하고, 개선점을 파악한다.

 


#####.방법에 따른 분류


ㅁ.Loop back 테스트
-KB에서 하나은행으로 이체를 한다면 하나은행은 부하를 받게 된다. 그래서 그쪽으로 가지 않게
완료 됬다고 하자 라고 하는 것이 Loop back이다.

 

ㅁ.spike 테스트
-너도나도 키보드를 사려고 버튼을 누른다. 그러면 순식간에 부하가 들어오는데
-이것을 spike 테스트라고 하고 즉, 특정 시간에 한방에

 

ㅁ.확장성 테스트
-클라우드 환경에서는 auto scaling으로 자동으로 확장한다. 이를 테스트 하는 것을 확장성테스트
-1,2번 서버가 동작한다고 했을 때, 일부러 2번 서버를 꺼봐도 1번 서버로 잘 넘어가고 세션이 잘 넘어가는지

 

ㅁ.가용성 테스트
-오랫동안 거래를 발생 시켰을 때의 시스템 상황으로 점검하기 위한 성능 테슽
-규모가 작은 프로젝트에는 잘 사용하지 않는다.

 


#####.성능 테스트 성능평가 지표

 

ㅁ.TPS는 성능 평가의 중요한 지표이다.

 

ㅁ.평균 응답 시간, 최대응답시간, CPU 사용량, 메모리 사용량 등등

 

#####.성능 테스트 용어

 

ㅁ.웹서버 > AP서버 > DB서버
-웹서버에 로직이 필요하면 AP서버로 전달하고 DB서버로 전달한다.

 

ㅁ.클라이언트 입장에서 응답시간은 각 구간별 시간이 다 포함된다.

 

ㅁ.RespTime = cpu + wait(큐잉시간 : 공유자원을 아끼기 위해서 OS가 자동적으로 실행됨)

 

ㅁ.Visit Time, request Interval(요청주기), Think Time
-Visit Time : 사용자가 총 머무른 시간
-응답시간 : 클릭 후 로직이 돌아가고 응답 받은 시간
-Think Time : 응답을 받고 다음 클릭하기 직전까지의 시간
-Request Interval : 응답시간 + Think Time
-응답시간이 늦어진다면???? Think Time은????? = 굉장히 동적인 시간이 되는 것이다. = 응답시간

 

ㅁ.동시 사용자 : 클라이언트가 서버에 요청을 보내고 응답을 받으면 컨넥션을 끊는다.
특정 시점에 단면을 잘라서 과거 10분 미래 10분을 산정해서 동시 사용자를 Concurrent User
-Active User : 현재 로직을 돌리는 사용자
-Inactive User : 현재 로직을 돌리는 사용자 이외에 과거 10분 미래 10분
-Concurrent = Active User + Inactive User
-고객사와 테스트 엔지니어와의 동시 사용자의 개념을 명확하게 맞춰야한다.

 

ㅁ.처리량 Throughput
-단위 시간당 서버에서 처리되는 요청 건수 TPS
-Through put === >>>> 3600 tph = 60 tpm = 1 tps

 

ㅁ.임계점 Saturation point
-부하를 늘려줘도 TPS가 증가하지 않는 지점

 

ㅁ.Little's Law 리틀이라는 학자이름
-Throughputs = Number of Active User / Average Response Time(sec)
-TPS = 가상유저 / 응답시간
-가상 유저수 / 요청주기
-요청주기가 길어질 수록 분모가 커지기 때문에 TPS는 줄어드는 성향을 나타낸다.

 


#####.성능테스트 프로세스

 

ㅁ.분석
-정보를 수집해서 어떻게 무엇을 부하 모델링을 할 건지
-고객사에게 먼저 보고하고 승인을 받아야함
-하드웨어, 소프트웨어, 구성요소, 네트워크를 먼저 알고 있어야하고
부하를 주기 전에 루프백이라던지, 부하를 DDos로 인식하는 경우도 있기에 먼저 파악
-workload 분석 : 사용량이 가장 많은 peak time을 선정하고, 호출된 업무를 나열해본다.
-일반적으로 사용자들이 가장 많이 사용하는 기능일 가능성이 높다.
-이 기능을 대상으로 통합 테스트를 진행하고 (70~80의 기능) 부하 기능의 비율을 나눈다.
-개발자나 고객사가 의심하고 있는 기능을 대상으로도 부하테스트의 대상으로 삼는다 (20~30)
-Infra에서는 CPU가 70프로를 넘으면 안된다라고 얘기하면 참고하여 분석 대상 모델을 구상한다.
-부하모델 설정 계획 

 

ㅁ.설계 
-목표 TPS를 산정한다.
-테스트 일정
-테스트 시나리오 수립 : 단위 테스트, 성능 테스트 등

 

ㅁ.준비 : 스크립트 작성

 

ㅁ.수행 : 단위 테스트, 성능 테스트, 고객이 요청하는 테스트

 

ㅁ.평가 : 결과 분석, 최적화, 검증 테스트, 결과보고

 


####.성능테스트 도구 소개

 

ㅁ.LoadRunner
-상용 시장 점유율 1위
-머큐리가 2000년에 만들어서 2006년 HP가 인수, Micro Focus에서 인수
-쉽고 기능이 많다. 욕나오게 비싸다.
-2003년? KB차세대 프로젝트 Load Runner를 납품한 직원이 아파트를 삿다는??
-LoadRunner 1 : 1.3 Jmeter
-지원하는 protocol이 많다.
-셉 부하테스트는 Jmeter는 못함

 

ㅁ.silk Performer

 

ㅁ.Jmeter
-이제부터 실습을 통해서 배움

 

ㅁ.NHK

 


##########.JMeter

 

#####.JMeter 개요

 

ㅁ.성능을 측정하기 위한 100% 자바 프로그램
-Apache JMeter는 다양한 프로토콜을 지원한다.

 

ㅁ.bin, lib 폴더가 중요
-많은 자료들이 있고
-ext자료도 있다.
-jmeter는 plugin architect 기능을 제공하고 그 기능들이 유용함
-printable doc --> index.html은 jmeter로 메인 페이지로 가게한다.

 

ㅁ.스크립트 작성
-sampler는 protocol 요소를 지정함
-http://프로토콜
-IP주소 서버이름
-8080 포트번호
-이하 애플리케이션
-jmeter는 현재 폴더를 루트로 지정한다.
-oracle j visual vm
-100명이면 30TPS
-jmeter는 자바 쓰레드로 돌아간다
-사용자 100명이면 쓰레드가 100개
-노트북 pc로 보면 400명 정도 된다고 본다.
-자바의 스레드를 만드는 부하를 주는 최상위 그룹 - 스레드 그룹 - 유저 - 가상 유저

 


#####.sampler

 

ㅁ.각 protocol에 맞게 제공되는 HTTP는 GET/PUT 등등

 

ㅁ.jdbc request
-DBMS에 다이렉트로, JMS Publisher 자바에서 Queue를 핸들링 때 MSA 아키텍쳐 등등

 

ㅁ.Java request
-10프로 비율로 클라이언트 서버 환경의 프로토콜을 사용한다. (자체 프로토콜 포맷)
-계좌번호:은행명:사용자명 <--- 이런 식으로 금융권에서 사용하는 자체 프로토콜

 

ㅁ.LDAP request : 

 

ㅁ.sampler
-실제 앱이 갖는 프로토콜을 사용하여 부하를 주는 항목 

 


######.Logic Controller

 

ㅁ.If Controller
-로직을 처리할 수 있는 컨트롤러

 

ㅁ.앞으로 계속 강의 예정

 


#####.Listener

 

ㅁ.모니터링 용도로 사용

 

ㅁ.부하를 발생시켜 놓고 여러가지 성능 지표를 실시간으로 확인

 

ㅁ.Resp time graph - 이런 것들을 실시간으로 확인 시켜주는 PlugIn을 잘 사용해야한다.

 

ㅁ. 이후....

 


#####.Timer

 

ㅁ.jmeter는 스레드로 돈다.
-HTTP Request -> 그다음 Constant Timer <----이 부분을 무한으로 돈다.

 

ㅁ.대부분의 실제 웹 애플리케이션에서는 멀티 로그인 기능을 제공하지 않는다.

 


#####.업무 시나리오

 

ㅁ.스크립트를 작성해야함(부하 스크립트)

 

ㅁ.부하모델 설정

 

ㅁ.부하 설정

 

ㅁ.실시간 모니터링(with infra, DB, PM, Network)
-목표 TPS 달성시 다시 환경 개선점 search

 

ㅁ.피드백

 


#####.proxy

 

ㅁ.사전적 의미는 대신한다.

 

ㅁ.Forward Proxy , Reverse Proxy 2가지가 있다.

 

ㅁ.Forward Proxy
-외부로 나가는 모든 네트웍을 한번 거쳐서 가게함 한번 갔던 것을 캐시화함
-빠르지만 내가 뭘 하는지 다 안다.

 

ㅁ.Reverse Proxy
-웹 서버가 Reverse Proxy를 해주는데 거르고 분배를 해주는 역할을 담당한다.

 

ㅁ.JMeter는 Forward Proxy를 사용한다.

 

 


#####.Template

 

ㅁ.구성요소들을 미리 만들어 놓은 것

 

ㅁ.recording controller
-쿠키 매니저를 활성화하면 개별 가상유저의 쿠키를 관리할 수 있다.
-HttpScriptRecorder

 

ㅁ.Java virtual VM 에 HTTP Proxy Server를 쓰레드를 활성화 한다.
-8888을 경유하도록 설정해야한다.
-WIN -> Controller -> Internet Option -> connect -> Lan Conf -> Proxy Server Setting
-addr = localhost, port = 8888
-이제부터 모든 트래픽은 JMeter가 띄원 Proxy Server를 경유하게 됨
-클릭했던 모든것들을 파라미터가 캡쳐를 한다.
-OS를 통해서 브라우저를 실행하게 하기 때문에 stop 버튼을 누르면 인터넷이 안됨

 


#####.fireFox

 

ㅁ.chrome, Edge는 인터넷 옵션 Proxy를 따라가지만 OS층에서 Proxy를 사용하는 것은 좋은 방법이 아니다.

 

ㅁ.OS층에서 사용되는 모든 HTTP 프로토콜을 Proxy로 바뀌기 때문에 좋지 않은 방법이다. 

 

ㅁ.fireFox는 브라우저 층에서 Proxy를 사용할 수 있다. 그래서 fireFox로 가는 것이 바람직하다.

 

ㅁ.스마트폰 부하 테스트 요청시
-스마트폰의 Proxy server 설정 기능이 있다. Window와 같은 네트워크에 묶어 놓고 테스트하면 JMeter로 할수있다.
-이럴 경우 OS층에서 Proxy를 설정해야한다.

 


#####.Test Fragment

 

ㅁ.구성요소를 보기 좋게 한다.

 

ㅁ.항상 스크립트를 떠 놓은 원본은 Test Fragment에다 저장해 놓은 다음 내용을 수정한다.

 

ㅁ.(.xml) 스크립트 파일은 해당 경로 bin경로에 있다.

 


#####.script debugging

 

ㅁ.generate parent sample

 

ㅁ.viewResultTree의 그룹핑 된다.

 

ㅁ.viewResultsTree의 response data

 

ㅁ.request body, request headers 등의 정보는 디버깅 하는데 있어서 큰 도움이 된다.

 

ㅁ.쿠키매니저 disable하면 logout하면 

 

ㅁ.로그인을 성공하면 성공 쿠키를 받는다. 요즘엔 헤더에 쿠키성공을 달고다니는데

 

ㅁ.loadRunner에는 쿠키 매니저 기능이 없다.

 

ㅁ.Jmeter만의 로그를 확인할 수 있다. 우측 상단에 !를 클릭하거나 opt에 cheack box를 클릭하면 나옴

 

ㅁ.메인 - 로그인 - 카테고리 선택 - 장바구니 담기 - 로그아웃에서 필요한 기능은 "선택","담기"

 

ㅁ.로그인은 1번만 나머지는 무한반복 선택한다.

 

ㅁ.3개의 request를 1개의 transaction으로 본다.(비지니스 트랜잭션 : 컨센서들과 잘 소통해야함)

 

ㅁ.scouter는 1request를 1transaction으로 봄

 

ㅁ.구조화과 되면 가독성도 좋고 정리하기도 편함

 

 


#####.CSV 데이터 적용

 

ㅁ.Variable Name : username,password,name

 

ㅁ.Ignore first line

 

ㅁ.Recycle on EOF?

 

ㅁ.stop thread onn EOF? 0부터 99까지하면 멈추겠느냐

 

ㅁ.Sharing mode : current thread : 현재 thread controller에서 사용하겠다.

 

ㅁ.test001, jadecross를 ${username},${password}로 치환

 


#####.User Defined Variables

 

ㅁ.host, scheme에는 value IP, http가 적히는데

 

ㅁ.테스트 단계에서 하던 것을 바로 운영서버로 변수처리해서 적용할 수 있다.

 


#####.동적 데이터 처리

 

ㅁ.항상 첫번째 데이터만 담고하는데 현실에서는 다른 물건도 산다.

 

ㅁ.시스템 입장에서는 결국에는 관계형 데이터 베이스는 HDD가 아닌 메모리로 올린다.

 

ㅁ.캐시화된 것들은 의미없는 부하가 되어버린다.

 

ㅁ.Correlation
-다음 request를 보낼 때 val값을 바꿔준다.
-view result에서 text로 response body를 보면 해당 productId=FI-FW-02를
-정규식 productid=(.+?)"
-에드 포스트 프로세스 ㅇ레귤러 익스세션 액스랙터 프로덕트 id에
-productid
-productid=(.+?)"  작성
-$1$
-0
-NOTFOUND

 

#####.REC01_장바구니담기.xml 활용

 

ㅁ.Search에서 FISH를 찾거나 정규식을 찾으면 빨간색 네모로 강조된다.

728x90