top bar

글 목록

2016년 2월 28일 일요일

[MAVEN] Shade Plugin (2) - artifactSet과 filter 설정 사용 및 minimizeJar

들어가기 앞서



가령 아래와 같은 구조의 project-a, project-b, project-c 라고 하는
3개의 프로젝트가 있다고 하자. (클릭하면 크게 보임)





이때 'MainClass' 가 있는 'project-a'의 pom.xml의 'dependency' 설정은 아래와 같이 구성한다.
<dependencies>

    <dependency>
        <groupId>com.asuraiv.bbb</groupId>
        <artifactId>project-b</artifactId>
        <version>0.0.1-SNAPSHOT</version>
    </dependency>

    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>3.8.1</version>
    </dependency>

</dependencies>

간단히 코드도 살펴보자.

'project-a'의 'MainClass'는 아래처럼 'project-b'의
'com.asuraiv.bbb.util_1.B_Utils1' 클래스를 사용한다.
package com.asuraiv.aaa;

import com.asuraiv.bbb.util_1.B_Utils1;

public class MainClass {
    
    public static void main(String[] args) {
        
        System.out.println("Hello Shade Plugin !!");
        
        // project-b 의 Utils 클래스 사용
        B_Utils1.printString("Hello Project B");
    }
}
'B_Utils1.printString' 메소드는 아래처럼 단순히 System out으로 문자열을 찍는다.
package com.asuraiv.bbb.util_1;

public class B_Utils1 {
    
    public static void printString(String text) {
        System.out.println(text);
    }
}

한편, 'com.asuraiv.bbb.util_2.B_Utils2' 클래스는 'project-c' 의 클래스를 사용한다.
package com.asuraiv.bbb.util_2;

import com.asuraiv.ccc.util_2.C_Utils2;

public class B_Utils2 {
    
    public static void printIntegerUsingCUtils(int value) {
        
        // project-c 의 Utils 클래스 사용
        C_Utils2.printInteger(value);
    }
}
뭐, 이런 상황이다.

이렇게 되면 이들 3개의 프로젝트의 의존관계는 아래처럼 될 것이다.










정리하자면 'project-a' 의 'MainClass' 에서 'project-b'의 'com.asuraiv.bbb.util_1.B_Utils1' 를 사용하고, 'project-b' 의 다른 패키지인 'com.asuraiv.bbb.util_2.B_Utils2'에서는 'project-c'의 'com.asuraiv.ccc.util_2.C_Utils2' 를 사용하는 것이다.

이때 'project-a'를 shade 플러그인을 사용하여 'uber-jar' 만들고,
디렉토리 구조를 보면 아래와 같은 것이다.
├─com
│  └─asuraiv
│      ├─aaa
│      ├─bbb
│      │  ├─util_1
│      │  └─util_2
│      └─ccc
│          ├─util_1
│          └─util_2
├─junit
│  ├─awtui
│  ├─extensions
│  ├─framework
│  ├─runner
│  ├─swingui
│  │  └─icons
│  └─textui
└─META-INF
    └─maven
        ├─com.asuraiv.aaa
        │  └─project-a
        ├─com.asuraiv.bbb
        │  └─project-b
        └─com.asuraiv.ccc
            └─project-c


artifactSet



위의 상황들이 전제로 주어졌을때, 결과적으로 'project-c'는 'project-b'가 의존하고 있지만, 사용되지 않는다. 'project-a'의 'MainClass'가 'project-b'의 'com.asuraiv.bbb.util_1.B_Utils1' 만을 사용하고 있기 때문이다.

하지만 project-c를 사용하지 않음에도 불구하고 shade 플러그인을 사용해 생성된 uber-jar는 위의 tree 구조를 보면 알 수 있듯 물리고 물린 의존관계는 몽땅 패키징이 되어 사용되지 않더라도 uber-jar 안에 포함되 있는것을 볼 수 있다.

이때 사용하지 않는 'proejct-c' 의 의존관계를 uber-jar 생성시에 제외시킬 수 있다.

'configuration' 태그 밑의 'artifactSet' 설정을 사용하여 어떤 라이브러리를 제외하고 포함시킬 것인지 정의가 가능하다. 아래와 같이 설정한다.
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>2.4.3</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <transformers>
                    <transformer
                        implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>com.asuraiv.aaa.MainClass</mainClass>
                    </transformer>
                </transformers>
                <artifactSet>
                    <excludes>
                        <exclude>com.asuraiv.ccc:project-c</exclude>
                    </excludes>                             
                </artifactSet>
                <outputFile>d:/shade/project-a.jar</outputFile>
            </configuration>
        </execution>
    </executions>
</plugin>
'artifactSet'태그와 함께 'excludes' 설정을 하면, 어떤 라이브러리를 제외 시킬 것인지 명시 할 수 있게 된다. 더불어 'outputFile'은 jar 파일이 떨어지는 위치를 말한다.

이러한 설정을 바탕으로 package를 하게 되면 아래와 같은 tree 구조가 된다.
├─com
│  └─asuraiv
│      ├─aaa
│      └─bbb
│          ├─util_1
│          └─util_2
├─junit
│  ├─awtui
│  ├─extensions
│  ├─framework
│  ├─runner
│  ├─swingui
│  │  └─icons
│  └─textui
└─META-INF
    └─maven
        ├─com.asuraiv.aaa
        │  └─project-a
        └─com.asuraiv.bbb
            └─project-b
보는것과 같이 사용하지 않는 'project-c' 가 패키징 되지 않았다.


filters



하지만 아래처럼 'MainClass'에서 'B_Utils1.printString'을 사용하지 않고 'project-c'를 사용하여 문자열을 찍는 'B_Utils2.printIntegerUsingCUtils' 메소드를 사용한다면 어떨까?
package com.asuraiv.aaa;

import com.asuraiv.bbb.util_2.B_Utils2;

public class MainClass {
    
    public static void main(String[] args) {
        
        System.out.println("Hello Shade Plugin !!");
        
        // project-c를 사용하여 문자열을 찍는 project-b의 Utils 클래스를 사용
        B_Utils2.printStringUsingCUtils("Hello Project B");
    }
}
'project-c' 라이브러리를 통째로 날렸다가는 프로그램 실행시에 아래와 같은 에러를 볼 것이다.



'MainClass'에서, 'project-c' 라이브러리를 사용하는 'project-b'의 메소드를 호출했는데, 'project-c'가 통째로 제외 되었으니 런타임에 오류가 나는것은 당연하다.

이때 'filter' 설정을 사용해 'project-c' 라이브러리에서 사용하는 패키지를 남기고 나머진 제외 시켜서 uber-jar를 생성할 수 있다!
<configuration>
    <transformers>
        <transformer
            implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
            <mainClass>com.asuraiv.aaa.MainClass</mainClass>
        </transformer>
    </transformers>
    <artifactSet>
        <excludes>
            <exclude>junit:junit</exclude>
        </excludes>
    </artifactSet>
    <filters>
        <filter>
            <artifact>com.asuraiv.ccc:project-c</artifact>
            <excludes>
                <exclude>com/asuraiv/ccc/util_2/**</exclude>
            </excludes>
        </filter>
    </filters>
    <outputFile>d:/project-a.jar</outputFile>
</configuration>
앞서 배운 'artifactSet' 설정을 사용하여 'junit'을 통째로 제외 시켰다.

여기서 'filters' 설정에 주목하자. 현재 'project-b'의 'printStringUsingCUtils' 메소드는, 'project-c'의 'com.asuraiv.ccc.util_1' 패키지만을 사용하고 'com.asuraiv.ccc.util_2' 패키지는 사용하지 않는다. 따라서 'filters' 설정을 사용하여, 특정 라이브러리의 특정 패키지만을 제외 시킨 것이다.

tree로 디렉토리 구조를 보면 아래와 같이 필요한 패키지만 uber-jar에 포함되어 있다.
├─com
│  └─asuraiv
│      ├─aaa
│      ├─bbb
│      │  ├─util_1
│      │  └─util_2
│      └─ccc
│          └─util_1
└─META-INF
    └─maven
        ├─com.asuraiv.aaa
        │  └─project-a
        ├─com.asuraiv.bbb
        │  └─project-b
        └─com.asuraiv.ccc
            └─project-c
ccc.utils_2 패키지가 제외 되었다. 근데 사실 bbb.utils_1 패키지도 사용하지 않는다.
filter 설정을 추가해보자
<filters>
    <filter>
        <artifact>com.asuraiv.bbb:project-b</artifact>
        <excludes>
            <exclude>com/asuraiv/bbb/util_1/**</exclude>
        </excludes>
    </filter>
    <filter>
        <artifact>com.asuraiv.ccc:project-c</artifact>
        <excludes>
            <exclude>com/asuraiv/ccc/util_2/**</exclude>
        </excludes>
    </filter>                               
</filters>
위와같이 'project-b' 에 관련한 필터설정도 추가했다.

빌드후에 디렉토리 구조를 보면 아래와 같이 필요없는 패키지들이 모두
제거된 것을 볼 수 있다.
├─com
│  └─asuraiv
│      ├─aaa
│      ├─bbb
│      │  └─util_2
│      └─ccc
│          └─util_1
└─META-INF
    └─maven
        ├─com.asuraiv.aaa
        │  └─project-a
        ├─com.asuraiv.bbb
        │  └─project-b
        └─com.asuraiv.ccc
            └─project-c


minimizeJar



사실 'artifactSet' 이나 'filter' 설정처럼 세밀하게 포함될/제외될 라이브러리나 패키지를 설정하기 힘들다면, 'minimizeJar' 설정으로 간편하게 필요없는 소스코드들을 제외 시킬 수 있다
<configuration>
    <transformers>
        <transformer
            implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
            <mainClass>com.asuraiv.aaa.MainClass</mainClass>
        </transformer>
    </transformers>
    <minimizeJar>true</minimizeJar> <!-- 필요없는 소스코드 제외! -->
    <outputFile>d:/shade/project-a.jar</outputFile>
</configuration>
위와 같이 'minimizeJar' 태그 설정만 하면 우리 위에서 살펴봤던 'artifactSet'과 'filter'설정을 한 것과 동일한 결과를 가져온다.

여태까지 'exclude'의 경우만 설명하고 'include'의 경우를 설명하지 않았는데, 사용법은 'exclude'와 동일하다.

만약 minimizeJar를 사용했는데 런타임에 필요한 패키지까지 제외되어 오류가 난다면 'include' 설정을 사용하여 필요한 패키지를 포함 시킬 수 있을 것이다.

'artifactSet'을 사용하여 어떤 라이브러리를 포함/제외 시킬 것인지, 'filter'를 사용하여 패키지 레벨로 세세하게 명시할 것인지, minimizeJar를 사용하여 간편하게 jar파일을 만들것인지.. 이 모든 방법들을 적당하게 조합하여 사용하면 효율적인 용량의 jar 파일을 만들 수 있을 것이다.


2016년 2월 12일 금요일

[Performance] The Grinder 3 (3) - 테스트 수행 및 리포트 산출

샘플 스크립트 작성



아주 간단한 HTTP Get 요청을 수행하는 스크립트를 작성해 본다.
그라인더 설치 디렉토리의 'example' 밑에 있는 스크립트를 참고하여 작성해보았다
import string
import random

from java.lang import String
from java.net import URLEncoder
from net.grinder.script import Test
from net.grinder.plugin.http import HTTPRequest
from net.grinder.common import GrinderException
from net.grinder.script.Grinder import grinder

# Server Properties
SERVER = "http://10.113.182.195:9001"
URI = "/test.jsp"

test = Test(1, "http_test")

class TestRunner:
    def __call__(self):
        request = HTTPRequest()
        requestString = "%s%s" % (SERVER, URI)
        test.record(request)
        result = request.GET(requestString)
        
        print "# Response text :", result.text
이전 포스트에서 언급했지만 그라인더는 'Jython' 스크립트를 사용해 부하 테스트를 수행 한다. 위의 코드는 HTTP Get 요청을 수행하는 간단한 스크립트이다.

위 파일을 'simplehttp.py' 라는 이름으로 저장하고, 'D:\grinder\python_source\grinder' 경로에 두었다. 따라서 'grinder.properties' 파일의 'grinder.script' 값을 아래와 같이 수정한다.
grinder.script = d:/grinder/python_source/grinder/simplehttp.py


테스트 수행



테스트하기 전, 프로세스와 스레드, 실행 횟수도 알맞게 설정해보자.
grinder.processes = 1
grinder.threads = 10
grinder.runs = 100
Agent 프로세스는 1개, 그 안에서 돌아가는 스레드를 50개로 설정 하였고, 각 스레드의 실행횟수는 100번으로 설정 하였다.

그리고 아래의 'start collecting' 버튼을 클릭한다.


















그러면 'Collection stopped' 라는 메시지가 'Wating for samples' 라고 바뀔 것이다. 이제 Worker Agent로부터 샘플 데이터를 기다리는 상태가 된것이다.

이제 아래의 'Start the Worker processes' 버튼을 클릭하여 Worker Agent를 구동시킨다.


















해당 버튼을 클릭하면 Agent 에 아래와 같은 로그가 찍힌다.












grinder.processes 값이 2이기때문에 2개의 Worker 프로세스가 시작된다. 특별히 정해진 네이밍 규칙이 있는데 '[host이름]-[seq번호]' 와 같은 식이다.

Agent 가 실행되면 'grinder.properties'파일의 grinder.consoleHost 와, grinder.consolePort 에 설정한(default는 localhost, 6372 이다) 호스트와 포트를 통해 수집된 데이터를 콘솔로 보낸다.

이때 Console창의 'Results' 탭을 보면 아래와 같이 수집되고 있는 데이터가 실시간으로 변화하는 모습을 볼 수 있다.





















TPS, Mean Time 등의 용어들은 알아서 찾아보자! (이것도 시간나면 정리해야겠다)


GrinderAnalyzer를 이용한 리포트 산출



테스트를 완료하면 그라인더 'log' 디렉토리에 아래와 같은 로그가 쌓인다.












위 사진을 보면, 'host-n.log' 의 형식으로 생성되는 각 프로세스별 정보 로그 파일과, 'host-n-data.log' 형식으로 생성되는 각 테스트 건별 데이터 로그 파일이 보인다.

파일을 열어보면 알겠지만 건당 수행 결과와 측정 요소들의 값들이 로그로 잔뜩 찍혀 있는 것을 볼 수 있다. 이것은 두말 할 것 없이 한 눈에 보기가 불가능하다.

하지만 'GrinderAnalyzer' 라는 툴을 사용하면 위의 정보들을 종합하여
보기좋게 결과 리포트를 생성해준다.

아래에서 다운 받는다

http://track.sourceforge.net/analyzer.html

다운 받은 파일을 압축 해제 하면 아래와 같은 구조가 보일 것이다.
















일단 윈도우 커맨드 창을 이용해 위의 'analyzer.py' 파일이 있는
디렉토리까지 이동한다.

그리고 아래와 같은 명령어를 입력 해보자.
(물론 jython home 경로가 윈도우 환경변수의 'path' 에 추가되어 있어야 한다.)
> jython analyzer.py "D:\grinder\grinder-3.11\log\hong-0-data.log D:
\grinder\grinder-3.11\log\hong-1-data.log" D:\grinder\grinder-3.11\log\hong-1.log 1
'jython analyzer.py' 다음에 쌍따옴표안에는 각 data log 파일의 '절대경로' 목록을 스페이스로 구분하여 입력한다. 그 다음에는 마지막 프로세스의 로그 파일인 'hong-1.log' 파일의 절대 경로를 입력한다.

마지막 파라미터로 주어지는 값은 몇개의 머신에서 Agent를 실행 시켰는지에 대한 값인데, 하나의 로컬 PC에서 Agent를 구동 하였으므로 '1'을 입력한다

위 명령어를 실행하면 아래와 같이 콘솔창에 로그가 찍힐 것이다.



































그러고 나면 'grinderReport' 라는 폴더가 생성되어 있을 것이다.


















해당 폴더안에 'report.html' 파일을 브라우저로 열어보자.
아래와 같이 테스트 수행 결과가 보기좋게 그래프와 표로 정리되어 나타난다.



















마치며...



이것으로 그라인더 설치, 설정, 테스트 수행, 결과 리포트 산출까지 모든 정리를 마쳤다.

이외에도 그라인더를 다양한 방법과 스크립트를 이용해 사용할 수 있지만, 차차 기회가 되면 정리해보도록 하겠다.

2016년 2월 2일 화요일

[Performance] The Grinder 3 (2) - 기본 원리 및 실행 환경 설정

기본 원리



그라인더는 크게 3가지 Process로 나뉜다





  • Worker Processes :
    Jython 으로 작성된 테스트 스크립트를 Interpret하고 테스트를 수행한다
    다수의 Worker 스레드가 병렬적으로 동시에 테스트를 수행하게 된다
  • Agent Process :
    Worker 스레드의 실행/중지를 수행한다
    Console로부터 전달 받은 테스트 스크립트를 캐싱한다
  • The Console :
    위 2가지의 프로세스들을 제어 한다
    스크립트 작성과 배포를 담당한다
    테스트 수행시, 그래프 및 현황을 보여준다


실행 환경 설정 (윈도우 기반)



1) setGrinderEnv.cmd

set GRINDERPATH=D:\grinder\grinder-3.11
set GRINDERPROPERTIES=D:\grinder\grinder-3.11\conf\grinder.properties
set CLASSPATH=%GRINDERPATH%\lib\grinder.jar
set JAVA_HOME=C:\dev_tools\Java\jdk1.7.0_65
PATH=%JAVA_HOME%\bin;%PATH%
그라인더 home 경로와 properties 파일경로, jdk 경로 등을 정의하는 스크립트이다.

2) startConsole.cmd

call D:\grinder\grinder-3.11\bin\setGrinderEnv.cmd
java -Dgrinder.console.consolePort=6372 -Dgrinder.console.consoleHost=localhost -Xms1024m -Xmx1024m -cp %CLASSPATH% net.grinder.Console 
Console을 구동하는 스크립트이다. call명령어를 이용해 setGrinderEnv에서 정의한 변수들을 활용한다. Agent와의 통신을 위해 console port와 host를 자바 옵션으로 준다. (아마 옵션으로 주지 않아도 default 설정으로 되어 있을 것이다)

3) startAgent.cmd

set GRINDERPATH=D:\grinder\grinder-3.11\bin
call D:\grinder\grinder-3.11\bin\setGrinderEnv.cmd
echo %CLASSPATH%
java -cp %CLASSPATH% net.grinder.Grinder -daemon 5 %GRINDERPROPERTIES%
Agent를 구동하는 스크립트이다. 구동시에 '-daemon 5' 라는 옵션을 주는데, Console으로부터 응답이 없다면(Console이 죽었다면) 5초 간격으로 재접속을 시도하라는 의미이다.

4) 디렉토리 추가 및 설정


위 3가지 스크립트를 생성하면, grinder 설치 폴더에 'bin' 폴더를 생성한뒤 3개 스크립트를 그쪽으로 몰아 넣는다. Agent 설정파일인 'grinder.properties' 는 최초 'examples' 폴더에 존재하는데, 이 파일 또한 grinder 설치 폴더에 'conf' 폴더를 만들어서 그쪽에 넣도록 하자.

그러면 아래와 같은 구조가 될 것이다.


grinder.properties



Agent의 설정은 grinder.properties 파일에 작성된다. 해당 properties 파일의 경로는 setGrinderEnv.cmd 스크립트에서 변수로 정의되고, startAgent.cmd 스크립트에서 그 경로를 사용한다.

grinder.properties 의 주요 설정은 아래와 같다
#
# Commonly used properties
#
# The file name of the script to run.
#
# Relative paths are evaluated from the directory containing the
# properties file. The default is "grinder.py".
grinder.script = d:/grinder/python_source/grinder/stress_test.py
 
# The number of worker processes each agent should start. The default
# is 1.
grinder.processes = 1
# The number of worker threads each worker process should start. The
# default is 1.
grinder.threads = 50
# The number of runs each worker process will perform. When using the
# console this is usually set to 0, meaning "run until the console
# sneds a stop or reset signal". The default is 1.
grinder.runs = 1000
# The IP address or host name that the agent and worker processes use
# to contact the console. The default is all the network interfaces
# of the local machine.
; grinder.consoleHost = consolehost
# The IP port that the agent and worker processes use to contact the
# console. Defaults to 6372.
; grinder.consolePort
grinder.script : 테스트 스크립트의 경로를 입력
grinder.processes : worker 프로세스의 갯수
grinder.threads : 하나의 worker 프로세스 안에서 실행되는 스레드 갯수
grinder.runs : 테스트 수행 횟수
grinder.consoleHost : 콘솔과의 TCP 통신을 위한 host
grinder.consolePort : 콘솔과의 TCP 통신을 위한 port


실행



1) Console 구동


먼저 윈도우 cmd 창에서 'startConsole.cmd'를 실행한다.



조금 기다리면 grinder 콘솔 창이 노출된다.



빨간색 박스 부분이 Agent를 제어하는 부분인데, 비활성화 되어있다.
아직 Agent를 구동하지 않았기 때문이다.

2) Agent 구동


startAgent.cmd 를 실행하여 Agent를 구동해 보자.



위 처럼 startAgent.cmd 를 실행하면 콘솔의 host:port 로 connect를 성공했다는 로그가 찍힌다. 그리고 다시 Console 창을 보자.



방금전 비활성화 되어있던 Agent 제어 버튼이 활성화 되었다.

첫번째 버튼은 Agent가 테스트를 시작/중지 할 수 있게 명령을 내리는 버튼이고,
두번째 버튼은 Agent를 reset 하는 버튼인데, 이때 Agent는 grinder.properties 의 속성들을 다시 읽어 들인다. 따라서 grinder.properties의 값을 바꿨을때 Agent를 굳이 재시작 하지 않아도 reset 버튼으로 변경된 grinder.properties의 값을 적용 시킬 수 있다.

3) script root directory 설정




빨간색 박스안에 있는 버튼을 이용해 배포될 테스트 스크립트의 저장 경로를 설정 할 수 있다. 해당 경로 밑의 모든 파일들이 worker 프로세스에 배포되므로, 리눅스 환경에서의 '/home' 이나 윈도우 환경에서의 'C:\' 와 같은 최상단 디렉토리를 설정하면 절대 안된다.

보통 grinder 설치 폴더의 'examples' 폴더로 설정하는 것이 일반적이다.


이제 기본적으로 테스트를 수행하기 위한 모든 설정은 끝이 났다.

다음 포스팅에서는 기본적인 http 테스트를 위한 Jython 스크립트 작성과,
테스트 수행, 그리고 'GrinderAnalyzer' 를 이용한 결과 리포트 산출 등을 정리하겠다.