JMeter

제일 첫 소개는 당연히 JMeter Wiki이다.

JMeter 단축키

JMeter csv 파일 읽어 User(thread)마다 가변 파라메터 셋팅하기 (여기)

그럼 실제로 한번 해보도록 하자.

우선, 아래는 JMeter를 사용한 안전성, 신뢰성, 부하, 기능 테스트를 위한 테스트 구성이다.

그리고 각 테스트에 대한 시나리오는 다음과 같다.

안전성 테스트	FailOver 테스트 - Single, Multi node failure시에 데이터 유실 무 검증
	Aging 테스트 - 장시간동안 서버 처리 기능 검증
확장성 테스트	기존 서버 구성에서 서버가 추가될 경우 부하 Rebalancing 기능 검증
부하  테스트	최대 한계에 대한 임계치를 구하고, 로드 밸런싱 기능의 성능 검증
기능 테스트	Infinispan의 기본 기능, 그리고 추가 확장 기능 검증

그리고 위 테스트를 위한 환경 셋팅을 위한 변수 인자들은 다음과 같다.

JMeter
Request Paramter

테스트 결과 보고서를 제공하는 JMeter의 기능 중 사용할 것을 정리했다.

SplineVisualizer	데이터 전송량을 그래프로 보여준다.
View Results Tree	각 요청건 별로 실제 송수신 데이터 보여준다.
Response Time Over Time	응답시간별로 그래프 보여준다.
Transaction Throughput vs Threads	동시접속 사용자수에 따른 전송데이터량
Response Times vs Threads	동시접속자수에 따른 응답시간의 변화

아래는 추가로 JMeter Plugin 설치를 하여 사용할 수 있는 확장 기능을 정리했다.

Response Times Disributions	x축 - 응답시간 인터벌,  y축 - 각 인터벌간 잡혀있는 샘플의 개수
Active Threads Over Time Listener	시간대별 살아있는 스레드의 개수
Reponse Codes Per Second	시간대별 Response Code 기록 (오류 발견시 아주 유용할듯 )
Latencies Over Time	Load Test시 Latency를 측정하는 그래프인데 별로 안좋은듯 피드백도 없고!
Server Hits per Second	Servers Hits 보여주는 그래프
Bytes Throughput Over Time	아주 중요한 그래프 (웹소켓 적용될지는 미지수)
Composite Graph	여러그래프를 함께 보여주도록 설정 가능

혹시 요청 url의 경우수가 많을 경우, WorkBench의 Http Proxy Server기능을 사용하여 요청 url을 레코딩할수가 있다. 

Thread Group에서의 설정값

아래는 Config Element에 잘 쓰는 놈중의 하나인 Counter 에 대한 설명이다.

아래는 ServerAgent 를 설치하여 cilent에서 서버의 cpu, memory usage 를 표로 보고 있는 그림

마지막으로 JMeter 사용시 주의사항이다.

Threads를 늘리거나 Listener를 많이 넣을 경우 메모리에 부하를 갈 수 있다. 모니터링 시간이 늘어나면 위험부담은 기하급수적으로 늘어나며 Heap 메모리 부족에러부터 다양한 리소스 부족 현상으로 빚어지는 에러로 에이징(장시간 부하)테스트등이 매끄럽게 진행이 되지 못한다.

그래서 해결방법은

리스너를 줄이거나 아니면 memory heap size를 많이 주는 것이다.

아래는 예제

Sometime I tune Jmeter options like:
JVM_ARGS="-Xms1024m -Xmx1024m -XX:+UseParallelGC -Xss1024k -XX:TenuredGenerationSizeIncrement=1m"

또하나는 Listener에 View Results Tree를 사용하지 말자!!! 기능테스트에서 사용하되, 부하테스트에서는 리소스가 없어 클라이언트가 먼저 리소스 다 잡아먹고 다운되버린다.

아래는 메뉴얼쪽 경고사항

18.3.6 View Results Tree

View Results Tree MUST NOT BE USED during load test as it consumes a lot of resources (memory and CPU). Use it only for either functional testing or during Test Plan debugging and Validation.

> Trouble Shoointg

테스트 중간에 Thread 개수가 많게 하여 테스트를 할 경우 Thread 개수가 증가하다가 나중에 그 개수가 점점 줄어들며 0으로 바뀌고 테스트가 종료가 되어야 

정확한 집계가 되는데 다음과 같이 Thread가 종료가 안되서 정확한 테스트 수치를 획득을 못할 경우가 있다. 

Q) i am running 100 threads concurrently for 5 mins using Jmeter 2.7 on website, once the execution duration is complete, it has to close all the running threads one by one and stop the execution completely, but Jmeter is left with few more threads(around 10-20 threads) without closing..

A)  

가능성 1 : those threads are still waiting on a response from the server

가능성 2 : This issue usually occurs when the requests to the application under test got high response times. The threads will be waiting for the pending response even after the specfied duration is elapsed. This can be avoided to an extent by allowing sufficient thread ramp down time or shut down time. Use Stepping thread group or ultimate thread group( these are JMeter plugins) to give an inclined ramp down instead of sudden shutdown as in normal thread group

Reference

1 : http://www.javaworld.com/javaworld/jw-07-2005/jw-0711-jmeter.html?page=1

2.  http://nico.vahlas.eu/2010/03/30/some-thoughts-on-stress-testing-web-applications-with-jmeter-part-2/