제일 첫 소개는 당연히 JMeter Wiki이다.
JMeter 단축키
JMeter csv 파일 읽어 User(thread)마다 가변 파라메터 셋팅하기 (여기)
그럼 실제로 한번 해보도록 하자.
우선, 아래는 JMeter를 사용한 안전성, 신뢰성, 부하, 기능 테스트를 위한 테스트 구성이다.
그리고 각 테스트에 대한 시나리오는 다음과 같다.
안전성 테스트 |
FailOver 테스트 - Single, Multi node failure시에 데이터 유실 무 검증 | |
Aging 테스트 - 장시간동안 서버 처리 기능 검증 | |
확장성 테스트 |
기존 서버 구성에서 서버가 추가될 경우 부하 Rebalancing 기능 검증 | |
부하 테스트 |
최대 한계에 대한 임계치를 구하고, 로드 밸런싱 기능의 성능 검증 | |
기능 테스트 |
Infinispan의 기본 기능, 그리고 추가 확장 기능 검증 | |
그리고 위 테스트를 위한 환경 셋팅을 위한 변수 인자들은 다음과 같다.
테스트 결과 보고서를 제공하는 JMeter의 기능 중 사용할 것을 정리했다.
SplineVisualizer |
데이터 전송량을 그래프로 보여준다. |
View Results Tree |
각 요청건 별로 실제 송수신 데이터 보여준다. |
Response Time Over Time |
응답시간별로 그래프 보여준다. |
Transaction Throughput vs Threads |
동시접속 사용자수에 따른 전송데이터량 |
Response Times vs Threads |
동시접속자수에 따른 응답시간의 변화 |
아래는 추가로 JMeter Plugin 설치를 하여 사용할 수 있는 확장 기능을 정리했다.
혹시 요청 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를 사용하지 말자!!! 기능테스트에서 사용하되, 부하테스트에서는 리소스가 없어 클라이언트가 먼저 리소스 다 잡아먹고 다운되버린다.
아래는 메뉴얼쪽 경고사항
|
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/