검색결과 국내에 JMeter-웹소켓 테스트 정리한 자료가 없어서
정리해 봅니다.
이 포스팅에서는
가장 보편적으로 쓰이는 로그인으로 예를들어 테스트를 해보겠습니다.
1. JMeter는 다음 페이지에서 다운 받을 수 있습니다.
http://jmeter.apache.org/download_jmeter.cgi
2. JMeter Websocket
Kawasima 씨가 만드신 JMeter 플러그인을 다운 받습니다.
https://github.com/kawasima/jmeter-websocket
또는 소스코드 빌드가 귀찮으신 분은 Jar파일을 직접 다운 받으시면 됩니다.
-maven 3.0 으로 빌드되었습니다.
https://dl.dropboxusercontent.com/u/89045969/jmeter/ApacheJmeter_websocket-0.1.0-SNAPSHOT.jar
-With Dependencies
https://dl.dropboxusercontent.com/u/89045969/jmeter/ApacheJmeter_websocket-dist-0.1.0-SNAPSHOT.jar
3. 다운받은 jar파일을 \apache-jmeter\lib\ext 에
집어넣은 후, JMeter를 실행.
4. Thread Group 을 생성합니다.
생성한 Thread Group을 선택하면
Number of Threads (몇개의 Thread를 만들 것인지.)
Ramp-Up Period (Thread 당 생성 시간)
Loop Count (하나의 Thread가 해당작업을 몇 번 수행 할 것인지.)
항목이 있습니다.
예를들어,
Number of Threads를 100
Ramp-Up Period를 100
Loop Count를 100
으로 설정해서 돌리면 Thread가 초당 하나씩 100개 까지 생성되면서
각각 작업을 100번씩 수행하겠죠? 그럼 10000번 수행하게 됩니다.
그럼 Ramp-Up Period를 0으로 설정하면?
100개의 Thread가 0초 즉 동시에 생성되어 작업을 수행합니다.
이것도 10000번 수행하게 됩니다.
즉 Ramp-Up Period를 작게 설정하면 Throughput이 더 나올 거고
테스트에 걸리는 시간이 더 단축될겁니다. 서버에는 부하가 더 가해지겠죠.
5. 웹 소켓 샘플러를 생성합니다.
6. CSV Data Set Config 생성
먼저 설명을 좀 드리면 제 웹소켓 서비스 제공 서버는 Node.js 입니다.
받은 요청을 '/' 로 스플릿 하여 어떤 서버측 함수를 호출 했는지 구별하고,
서버측 내부 함수(reqLogin)에 파라미터로 '/' 이후 부분을 넘겨주는 식입니다.
다양한 값을 테스트해보기 위해 데이터 셋을 만듭니다.
물론 Send message 부분에 직접 값을 박아서 해도 됩니다.
${ID} 와 ${PW} 부분에 실제 데이터를 집어넣으시면 되는거죠.
(잘 안보이시는분, Send message 에
reqLogin/{"ID":"${ID}","PW":"${PW}"} 라고 적혀있습니다.)
자 이제 CSV Data Set Config를 생성합니다.
생성한 CSV Data Set Config 를 눌러서
Filename 부분에는 csv 파일경로(txt파일도 가능합니다.)
Variable Names(comma-delimited) 에는 ID,PW 라고 적습니다.
csv 파일은 이런식으로 구성 하면 됩니다.
테스트를 실행하면 id1,pw1 로 로그인을 시도하기 시작하는데요
일단 잠깐..
5. View Results Tree를 생성합니다.
테스트 후 결과를 보기위한 리스너를 달아줍시다.
View Results Tree를 생성해 요청 및 반환값을 확인합니다.
단, 여기에는 중요한 이슈가 있습니다.
많은 Thread Group을 돌릴 경우에, View Results Tree 때문에
느려지는 현상이 있습니다. 심하면 에러율이 100%까지 올라가며 JMeter가 멈춥니다.
이걸 몰라서 고생을 좀 했네요.
7. Summary Report 생성
Thread Group들의 테스트 결과를 보기위해 요약 리포트를 생성합니다.
쉽게 에러율과 Throughput 등을 확인 할 수 있습니다.
8. 시작, 비우고 시작
재시작 하실땐 비우고 하셔야 테스트가 제대로 됩니다.
검정색이 시작, 붉은색이 비우는겁니다.
9. 테스트 결과
Number of Threads를 100
Ramp-Up Period를 1
Loop Count를 100
으로 테스트 한 결과입니다.
(Constant Throughput Timer를 단 후 20만 정도의 적당한 값을 설정하면
더 높은 Through put 이 나오기도 합니다.)
jar 파일좀 다시 올려주실수 있을까요??ㅜㅜ
답글삭제미안합니다.. 너무 오래되서 파일이 없네요 ㅠ
삭제어떻게 사용하는지 몰라서 몇시간째 해매고 있었는데 감사 합니다 ㅎㅎㅎ
답글삭제제 글이 도움이 되었다니 기쁩니다ㅎㅎ
답글삭제안녕하세요. 질문이 하나 있습니다.
답글삭제Number of Threads : 100
Ramp-Up Period : 1
=> 이것은 1초에 100명이 동시접속해서 부하테스트를 진행하라...라는 의미라고 알고있습니다.
그런데, Summary Report에 보면, Throughput이 1908/sec입니다.
=> 초당 처리건수가 1908건이라는 의미라고 알고있습니다.
질문)
초당 100개의 Request가 들어오는데, 어떻게 초당 처리건수가 1908건으로 100을 넘을까요?
저도 부하테스트를 진행하는데 유사한 결과나 나와서 궁금해서 질문 드립니다.
이걸 마지막으로 사용한게 4년전이라 기억이 희미한데요,
삭제Throughput이 웹 사이트 또는 응용 프로그램에서 처리 할 수 있는 Capacity 라는 의미이므로
단순히 Throughput = Number of Threads * Ramp-Up Period 계산은 아니었던 것 같습니다.
지나가다 글남깁니다.
답글삭제jar 파일의 경우는 제작자 github 에 올려져있습니다.
https://github.com/maciejzaleski/JMeter-WebSocketSampler/releases
참고하시면 될꺼같습니다.
- 좋은글 감사합니다
감사합니다.
삭제안녕하세요. 작성자님. 꽤 오래된 게시물이지만, 궁금해서여쭙겠습니다.
답글삭제Send message 에
reqLogin/{"ID":"${ID}","PW":"${PW}"} 를 기입하셨는데,
request 파라미터명을 ID나 PW로 정하신 이유가 있으실까요?
저도 로그인 테스트를 시도중인데, 로그인이 되질않아서
혹시나 다른 이름으로 지정해도 되는지 궁금합니다.
답이 늦었네요 ㅠ "ID", "PW"의 경우에는 제가 테스트하고자 하는 서버가 해당 파라미터명으로 아이디 패스워드를 받았기 때문입니다. 다른 것으로 지정하셔도 되는데, 실제 서버가 받는 파라미터명과 이름을 맞추셔야 합니다.
삭제