2013년 12월 16일 월요일

[JMeter] JMeter로 웹소켓 테스트 하기



검색결과 국내에 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 이 나오기도 합니다.)

2013년 12월 15일 일요일

[Node.js] Mysql - ReleaseConnection 에러

Hello SyntaxHighlighter

Cannot call method 'ReleaseConnection' of null

참조 페이지
https://github.com/dougwilson/node-mysql/commit/ef13ca08dfc8025a93c607656119b7abb3b3b2aa
// Release Connection시 에러가 날 때가 있는데요.
// 해결 방법입니다.


//  lib/PoolConnection.js 수정하기

PoolConnection.prototype.release = function () {
  if (!this._pool || this._pool._closed) {
      return;
    }
  return this._pool.releaseConnection(this);
};


//  test/integration/pool/test-destroy-connection.js 수정하기

var common     = require('../../common');
var assert     = require('assert');
var Connection = require(common.lib + '/Connection');
var pool       = common.createPool();

pool.getConnection(function(err, connection) {
  if (err) throw err;
  assert.strictEqual(connection, pool._allConnections[0]);
  connection.destroy();

  assert.ok(pool._allConnections.length == 0);
  assert.ok(!connection._pool);

  assert.doesNotThrow(function () { connection.release(); });
  
  pool.end();
});






2013년 12월 7일 토요일

[MySQL] Query with `Join` and `If`


다음에 보면 더 간단하게 짤 수 있지 않을까라는 생각이 들어 메모합니다.


테이블을 잠깐 설명하면


어떤 ID가 계획(부모)을 만들고 나면
다른 ID는 부모 계획을 가리키는 동일한 계획(자식)을 만들 수 있습니다.
자식계획을 만들었다고 해서 반드시 계획에 참여 하는 것은 아닙니다.
(부모 계획에 불참 가능)


(부모 자식이라는건 개념 이해를 돕기 위한것입니다.)


 User 테이블, Plan 테이블이 있고,

User 테이블에는
 `ID`와 `NM`(이름) 컬럼이 있습니다.

Plan 테이블에는 
 Primary키인 `index` 컬럼
 Unique키인 (`ID`,`code`) 컬럼
 index 컬럼을 참조하는 `plan` 컬럼
 참여를 뜻하는 일반 컬럼 `go` 가 있습니다. 


예를들어
index가 11이고 code가 1111인 부모(plan=1) 계획에 kim은 참여(go=1) 합니다.
index가 12이고 code가 1111인 자식(plan=11) 계획에 ston는 참여(go=1) 합니다.
index가 13이고 code가 1111인 자식(plan=11) 계획에 john는 불참(go=0) 합니다. 
ㅡㅡㅡㅡㅡㅡㅡㅡ
index가 20이고 code가 1111인 부모(plan=1) 계획에 poul은 참여(go=1) 합니다.
index가 21이고 code가 1111인 자식(plan=20) 계획에 nice는 참여(go=1) 합니다.


위 예제에서 index 11번이 삭제될 경우
index 12,13번도 같이 삭제시키고 Index 20 ,21 번은 삭제 안되게 하려면?
외래키 plan에 대해 Cascade로 설정하면 되겠네요.


진짜 문제는 다음과 같습니다.

클라이언트에서
kim과 1111을 가지고 쿼리했을 때
ston과 1111을 가지고 쿼리했을 때
john과 1111을 가지고 쿼리했을 때 

동일하게 이 계획에 참여하는 kim, ston의 이름을
출력해야 합니다.
(코드만 같고 다른 계획에 속한 poul,nice의 이름이나
계획은 있지만 불참하는 john의 이름은 출력하면 안됨)


다시말해
poul과 1111을 가지고 쿼리했을 때
nice와 1111을 가지고 쿼리했을 때

동일하게 poul과 nice의 이름이 출력 되어야 겠죠.






쿼리를 다음처럼 구성해보았고 결과는 잘 나오는데요
이게 과연 성능상 좋은 쿼리인지는 잘 모르겠네요.

SELECT NM
FROM Plan join `User` on `Plan`.ID=`User`.ID
WHERE ((plan=if(
(SELECT plan FROM Plan WHERE ID=? and code=?)=1,
(SELECT `index` FROM Plan WHERE ID=? and code=? ),
(SELECT `plan` FROM Plan WHERE ID=? and code=?)))
or (`index`=if(
(SELECT `plan` FROM Plan WHERE ID=? and code=?)=1,
(SELECT `index` FROM Plan WHERE ID=? and code=? ),
(SELECT `plan` FROM Plan WHERE ID=? and code=?))))
and go=1

짤땐 힘들었는데 짠다음 줄바꿈을 하고 보니 간단하네요.

쿼리를 설명하면


FROM 절 :
이름을 얻기위해 Plan과 User 테이블을 조인하는거구요


Where 절 :
1. 부모인 경우
ID와 code 로 쿼리했을 때 `plan`값이 1이겠죠.(부모) 그래서
부모의 `index`값으로 `plan`을 쿼리해 자식 계획들을 찾습니다.
근데 이러면 여기에 자식들만 포함되고 자기 자신은 포함 되지 않았죠?
그래서 or 이후 에서
plan이 1인경우 자기자신을 포함하는겁니다.

2.자식인 경우
ID와 code 로 쿼리했을 때 `plan`값이 1이 아니겠죠(자식)
그럼 자기자신을 포함한 자식들을 찾습니다.
`plan`값을 통해서요.
근데 부모가 포함되지 않았죠?
그래서 or 이후에서 1이 아닌 경우 자신의 `plan` 값으로
자신의 부모 `index` 를 찾습니다.