블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Stackdriver profiler

클라우드 컴퓨팅 & NoSQL/google cloud | 2018.04.08 21:44 | Posted by 조대협


Stack driver profiler


조대협 (http://bcho.tistory.com)


얼마전에 구글 클라우드의 모니터링 솔루션인 stack driver에서 profiler 기능이 발표되었다. (https://cloud.google.com/profiler) 

우리가 일반적으로 생각하는 성능 분석을 위한 profiling 도구로, 구글 클라우드 뿐만 아니라, 여러 서버에서 동작하는 Java/node.js/Go 애플리케이션의 성능을 모니터링할 수 있다.(파이썬은 곧 지원 예정)


장점은 코드 수정없이 간단하게 에이전트만 추가함으로써 프로파일러 사용이 가능하고, 프로파일링된 결과를 stackdriver 웹 콘솔에서 바로 확인이 가능하다는 것이다.


JDB등 전통적인 프로파일러가 있기는 하지만 보통 프로파일러가 적용되면, 애플리케이션의 성능이 극단적으로 느려지기 때문에, 운영환경에 적용이 불가능한데, Stack driver profiler의 경우에는 성능 저하가 미비하여 운영환경에도 적용이 가능하다.


"Stackdriver Profiler uses statistical techniques and extremely low-impact instrumentation that runs across all production application instances to provide a complete picture of an application’s performance without slowing it down."


아래는 자바 애플리케이션을 프로파일을 하기 위해서 프로파일러 바이너리를 agentPath에 추가한 형태이다


java \ -agentpath:/opt/cprof/profiler_java_agent.so=-cprof_service=user,-cprof_service_version=1.0.0 \ -jar ./User-0.0.1-SNAPSHOT.jar


아래는 자바 애플리케이션을 프로파일을 하기 위해서 프로파일러 바이너리를 agentPath에 추가한 형태이다

애플리케이션은 http://bcho.tistory.com/1247 에서 사용한 간단한 REST API를 사용하였다.

코드를 실행해서 프로파일링 데이타를 얻고 나면 아래와 같이 구글 클라우드 콘솔에서 프로파일링 결과를 확인할 수 있다.


위의 뷰는 WALL뷰로, 전체 프로그램이 수행되는 중에, 어느 코드가 시간을 얼마나 사용했는지를 프로파일링 해준결과이다.
이 외에도 CPU 시간으로 볼 수 도 있고, 메모리 사용률등 다양한 뷰
대규모 분산 서비스나 MSA 구조에 적합하도록 프로파일 결과를 볼 수 있는 범위를 선택이 가능한데, 상단의 메뉴를 보면 프로파일링 결과를 볼 서비스와, 프로파일 타입 (CPU,WALL:메서드별 실행시간, 메모리 사용률), 그리고 서비스가 배포된 클라우드 존, 서비스 버전 등에 따라서 선택이 가능하다. 아래는 언어별로 지원하는 프로파일 타입이다. 



Profiler의 뷰는 애플리케이션 타입에 상관이 없이 순수 프로그래밍 플랫폼에만 연관된 뷰로만 보여준다.
무슨이야기인가 하면, 보통 웹 애플리케이션은 멀티 쓰레드 타입으로 동작하고, REQUEST가 들어오면 쓰레드가 하나의 요청을 처리하고 빠지는 형태이기 때문에, 쓰레드별로 어떤 메서드가 순차적으로 실행되었는지등의 뷰를 선호하는데, JENNIFER나 오픈 소스 스카우터와 같은 APM (Application Peformance Monitoring)툴이 이러한 뷰를 제공한다. 

위의 샘플을 보더라도, 톰캣서버의 쓰레드들이 대부분 모니터링 될뿐 직접 코딩한 메서드들이 관측 되지는 않는다. (사용자 코드가 적고, 실행시 별로 크게 시간을 소요하지 않는 것도 원인이기는 하지만)

만약에 REQUEST에 대한 메서드별 소요 시간 모니터링 및 병목 구간 확인을 하려면, Stack driver profiler보다는 Stack driver trace를 사용하는 것이 적절하다. http://bcho.tistory.com/1245

그래서 Stack Driver는 성능 모니터링 (APM)제품군을 Trace, Profiler, Debugger 3가지로 묶고 있고, (Debugger는 나중에 시간이 되면 테스트하고 다루도록 하겠다.) 각기 다른 뷰로 상호 보완적인 관점에서 성능 모니터링이 가능하도록 하고 있다.



구글의 파이버 백본과, 글로벌 프록시 노드를 이용한 네트워크 시간 단축하기 실제 테스트 결과


앞의 글 http://bcho.tistory.com/1109 에서 언급한 바와 같이, 직접 서버를 호출 하는 것보다 구글의 클라우드 로드밸런서를 사용하게 되면, 트래픽을 가장 가까운 target proxy 서버를 통해서 그 뒤의 구글 광케이블망을 통해서 전송 받기 때문에 속도가 빠르다고 했습니다. 실제로 빠른지 간단한 테스트를 해봤습니다.


서버를 미국 중부 지역에 배포한후, 첫번째는 그 서버 IP로 직접 부하를 줘보고, 두번째는 그 서버 앞에 구글 클라우드 로드밸런서를 넣은 후, 로드밸런서를 통해서 호출하게 하였습니다.

Node.js 서버로 간단하게 서버의 네트워크 정보를 출력하는 프로그램을 만들어서 호출하였습니다. 다음과 같은 응답값이 나오고 응답값의 총 크기는 514 byte 입니다.



첫번째 시나리오는 서버로 직접 호출한 경우입니다.

서버의 IP는 104.197.165.74를 사용했습니다.


Apache ab 벤치마크 툴을 사용해서 20개의 쓰레드로 3000번 호출을 하였습니다.

결과는 다음과 같습니다.

Server Software:        

Server Hostname:        104.197.164.74

Server Port:            80


Document Path:          /

Document Length:        514 bytes


Concurrency Level:      20

Time taken for tests:   58.945 seconds

Complete requests:      3000

Failed requests:        0

Total transferred:      2154000 bytes

HTML transferred:       1542000 bytes

Requests per second:    50.89 [#/sec] (mean)

Time per request:       392.968 [ms] (mean)

Time per request:       19.648 [ms] (mean, across all concurrent requests)

Transfer rate:          35.69 [Kbytes/sec] received


Connection Times (ms)

             min  mean[+/-sd] median   max

Connect:      191  195   4.0    193     219

Processing:   192  196   4.1    194     223

Waiting:      192  196   4.1    194     223

Total:        383  392   8.0    387     427


Percentage of the requests served within a certain time (ms)

 50%    387

 66%    393

 75%    402

 80%    402

 90%    403

 95%    404

 98%    405

 99%    407

100%    427 (longest request)


전체 수행 시간이 58.945초가 소요되었습니다. 평균 처리 시간이 392ms가 나오는데, 그중에서 connection을 하는 시간이 195 ms가 나옵니다.


이번에는 로드밸런서를 통해서 구글 백본망을 통해 트래픽을 들어오게 테스트 하였습니다.


Target proxy는 전세계에 걸쳐서 배포되어 있고 Any IP 라우팅 로직에 따라서 가장 가까운 곳을 찾아서 라우팅이 됩니다. 로드밸런서는 IP는 위의 그림과 같이 130.211.11.38 을 사용했습니다.


테스트 조건은 동일하고 결과는 다음과 같습니다.

Server Software:        

Server Hostname:        130.211.11.38

Server Port:            80


Document Path:          /

Document Length:        514 bytes


Concurrency Level:      20

Time taken for tests:   47.295 seconds

Complete requests:      3000

Failed requests:        0

Total transferred:      2148000 bytes

HTML transferred:       1542000 bytes

Requests per second:    63.43 [#/sec] (mean)

Time per request:       315.298 [ms] (mean)

Time per request:       15.765 [ms] (mean, across all concurrent requests)

Transfer rate:          44.35 [Kbytes/sec] received


Connection Times (ms)

             min  mean[+/-sd] median   max

Connect:       36   41   1.7     41      56

Processing:   192  273  78.3    211     587

Waiting:      192  273  78.3    210     586

Total:        229  314  78.3    252     623


Percentage of the requests served within a certain time (ms)

 50%    252

 66%    387

 75%    389

 80%    395

 90%    404

 95%    407

 98%    420

 99%    422

100%    623 (longest request)

terrycho-macbookpro:~ terrycho$


전체 소요 시간은 47.295초, 호출당 평균 소요 시간은 314ms, Connection 시간이 많이 짧습니다. 평균 41ms 입니다.



직접 호출한경우

로드밸런서(구글백본)통해 호출한 경우

총 소요시간

58.945초 (124%)

47.295초

호출당 평균 소요시간

392ms (124%)

314ms

Connection 시간

195ms  (470%)

41ms


서버에서 처리시간은 동일하기 때문에, 연결 시간이 중요한데, 위에서 볼 수 있듯이 연결 시간은 대략 4~5배 정도 차이가 나는 것을 볼 수 있습니다.


한국 → 미국 구간 시간이지만, 글로벌 서비스를 한다고 생각할때, 이정도 시간을 줄일 수 있는 것은 애플리케이션 응답시간에 꽤나 많은 영향을 주지 않을까 싶습니다. 대략 호출 평균 시간이 80ms 정도 차이가 나는데, 애플리케이션에서는 꽤나 긴 시간으로 생각할 수 있습니다.


패킷 사이즈가 작고, 시간대역에 따라서 네트워크 상황이 달라서 정확한 결과를 얻기는 어렵습니다만 확실히 광케이블 네트웍을 통해서 성능 향상은 있고, 트래픽이 커지면 더 성능차이가 날거라고 보입니다. 

기회가 되면 파일 전송과 같은 다른 시나리오로 한번 테스트 해보도록 하지요.

Heroku에서 newrelic을 이용한 node.js 애플리케이션 모니터링 (APM)


조대협 (http://bcho.tistory.com)


Heroku에서 node.js 애플리케이션에 대한 모니터링을 살펴보자. 애플리케이션의 모니터링은 모니터링 분야에서 APM (Application Performance Monitoring)이라는 분야로, 애플리케이션에서 어떤 API 들이 호출이 되었는지, 각 로직별 응답 시간등을 추적할 수 있다. 한국에서 유명한 APM으로는 제니퍼가 있다.

Heroku에서 사용할 수 있는 APM은 여러가지가 있지만 여기서는 newrelic이라는 제품을 소개한다.

Newrelicheroku 뿐 아니라, 모니터링 시장에서 매우 유명한 제품으로 APM 기능뿐만 아니라, 서버 인프라에 대한 모니터링등 상당히 많은 기능을 제공한다.

Heroku에는 그러한 기능을 제공하지는 않고 newrelicAPM 기능만을 제공한다.

 

newrelic add-on 설치


newrelic add-on부터 설치한다. 설치 명령어는 다음과 같다.


%heroku addons:create newrelic:{상품명}


상품명은 무료 상품을 사용할 예정이기 때문에, 상품명은 ‘wayne’를 선택한다. Heroku addons 명령어를 이용해서 다음과 같이 addons를 추가 한다.



Figure 7 newrelic addon 설치

 

상품 모델은 https://elements.heroku.com/addons/newrelic#plan_selector 를 참고하면 된다.

3 dyno 모니터링에 월 49$, 300 dyno에 월 4499% 까지 다양한 상품 모델이 있다. 가격은 다른 상품에 비해서 싼편은 아니지만, APM 쪽에서 그만큼 많은 기능을 제공한다.

 

newrelic 환경 변수 설정


다음으로 추가적인 환경 설정이 필요하다. 다음과 같이 heroku config 명령어를 이용해서 다음 환경변수들을 설정한다.

 

환경변수명

설정값

설명

NEW_RELIC_APP

‘helloherokuterry’

newrelic 을 적용한 heroku 애플리케이션 이름. 여기서는  helloherokuterry 앱을 사용하기 때문에, helloherokuterry 를 사용한다

NEW_RELIC_NO_CONFIG_FILE

‘true’

newrelicnode.js에서 사용하기 위해서 원래는 newrelic.js 에 환경변수를 설정하는데, herokunewrelic에서 이 옵션을 설정하면 newrelic.js 환경에서 환경변수를 읽는데, newrelic.js를 사용하지 않고, heroku config 를 이용하여 환경 변수를 설정할 경우, 이 옵션을 ‘true’로 세팅한다.

Figure 8 newrelic 환경 변수 목록

 

다음은 heroku config 명령을 이용해서 위의 두 환경 변수를 설정한 화면이다.



Figure 9 newrelic 환경 변수 설정 화면

 

node.js 애플리케이션에 에이전트 코드 삽입


환경 변수 설정이 끝났으면, newrelic 에서 node.js 애플리케이션의 실행 정보를 수집할 수 있도록 코드를 삽입해야 한다.

에이전트는 ‘newrelic’ node.js 모듈을 설치해서 app.js 에서 로딩 하면 된다.

package.json에서 다음과 같이 newrelic 모듈에 대한 의존성을 추가한다.


{

  "name": "helloheroku",

  "version": "0.0.0",

  "private": true,

  "scripts": {

    "start": "node ./bin/www"

  },

  "dependencies": {

    "body-parser": "~1.13.2",

    "cookie-parser": "~1.3.5",

    "debug": "~2.2.0",

    "ejs": "~2.3.3",

    "express": "~4.13.1",

    "morgan": "~1.6.1",

    "serve-favicon": "~2.3.0",

    "stylus": "0.42.3",

    "newrelic" : "~1.25.5"

  }

}

Figure 10 package.json  newrelic 의존성 추가

 

다음으로 이 모듈을 애플리케이션에서 로딩해야 하는데, app.js 맨 윗줄에 아래와 같이 require(‘newrelic’) 코드를 삽입한다.

 

require('newrelic');

 

var express = require('express');

var path = require('path');

var favicon = require('serve-favicon');

Figure 11 app.jsnewrelic 에이전트 로딩 코드를 삽입

 

코드가 수정되었으면 heroku에 배포한다.

 

Newrelic을 이용한 모니터링


이제 모든 준비가 끝났다. 애플리케이션을 기동하고 heroku 대쉬보드로 들어가 보자



Figure 12 애플리케이션 선택

 

그림과 같이 대쉬보드에서 애플리케이션을 선택하면, 다음과 같이 newrelic addon이 추가된것을 확인할 수 있다.



Figure 13 newrelic APM addon이 추가된 화면

 

newrelic을 클릭해보면, 설정이 제대로 되었다면 다음과 같은 화면이 나올것이다.



Figure 14 newrelic 첫번째 접속 화면

 

상단에서 APM화면을 눌러서 APM 화면으로 들어가면 아래와 같이 애플리케이션 리스트들이 나오고, 아까 등록한 helloherokuterry 애플리케이션이 나온다.



Figure 15 newrelic에서 애플리케이션 선택

 

해당 애플리케이션을 클릭하면 다음과 같이 애플리케이션에 대한 상세 정보가 나온다.



Figure 16 newrelic APM 모니터링 화면

 

전체 응답시간(Web transation time), 초당 처리량 (Throughput), 주로 호출되는 웹 트렌젝션 목록등을 볼 수 있다.

그이에도 각 인스턴스에 대한 디테일이나 개별 트렌젝션에 대한 추적, 에러등에 대해서도 추적이 가능하다.

간단한 웹뷰 컴포넌트의 이해와 최적화

조대협(http://bcho.tistory.com)


들어가기에 앞서서


이글은 안드로이드 프로그래밍 개발을 공부하면서 공부한 내용을 정리한 글입니다. 제가 아직 안드로이드에는 전문성이 없는 초보자 수준이기 때문에, 수준이 높지 않으니, 내용을 참고만 하시기를 바라며, 더 나은 프로그래밍 방법등이 있음을 미리 알려드립니다.


Webview(웹뷰) 컴포넌트에 대해서


웹뷰는 안드로이드 프레임웍에 내장된 웹 브라우져 컴포넌트로 뷰(View)형태로 앱에 임베딩이 가능하다. 비교해서 생각하자면, 안드로이드 앱안에, HTML iframe을 넣어놓은 것이라고나 할까?

단순하게, 웹 페이지를 보기위해도 사용하지만, 안드로이드 앱 안에서 HTML을 호출하여 앱을 구현하는 하이브리드 형태의 앱을 개발하는데에도 많이 사용된다. 이러한 하이브리드 앱은 안드로이드 네이티브 앱 개발에 비해서 개발이 비교적 쉽고, 특히나 기기간의 호환성을 해결하기가 상대적으로 편하다는 장점을 가지고 있으나, HTML 기반인 만큼 상대적으로 반응성이 약하고, 애니메이션등의 다양한 UI 효과를 넣기 어렵다는 단점을 가지고 있다.

그럼에도 불구하고 SNS나 기타 서비스 앱에서는 타 웹사이트 링크로 가는 기능등을 지원하기 위해서 많이 사용되고 있다.

웹 뷰에 사용되는 브라우져 컴포넌트는 우리가 일반적으로 생각하는 웹브라우져 수준으로 생각하면 곤란하다. 일반적인 웹 브라우져를 안드로이드 OS에 맞게 일부 기능들을 제외하고 작게 만든 웹브라우져라고 생각하면 되고 그렇기 때문에 HTML5 호환성등 기능의 제약을 많이 가지고 있다.



기본적인 웹뷰 사용방법


이해를 돕기 위해서 웹뷰를 이용한 간단한 애플리케이션을 만들어보자. 이 애플리케이션은 URL을 입력 받고 Go 버튼을 누르면 웹뷰에 해당 URL을 접속하여 보여주고, 해당 URL이 로딩되는데 까지 걸린 시간을 millisecond 로 표시해주는 애플리케이션이다.




먼저 안드로이드 스튜디오에서, MainActivity하나만 있는 심플한 앱 프로젝트를 생성한 후에, MainActivity의 레이아웃을 다음과 같이 디자인하자




위의 레이아웃의 XML 코드를 보면 다음과 같다.

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent"
android:layout_height="match_parent" android:paddingLeft="@dimen/activity_horizontal_margin"
android:paddingRight="@dimen/activity_horizontal_margin"
android:paddingTop="@dimen/activity_vertical_margin"
android:paddingBottom="@dimen/activity_vertical_margin"
android:orientation="vertical"
tools:context=".MainActivity"
android:weightSum="1">


<LinearLayout
android:orientation="horizontal"
android:layout_width="match_parent"
android:layout_height="wrap_content">

<EditText
android:layout_width="252dp"
android:layout_height="wrap_content"
android:id="@+id/txtURL"
android:text="http://www.naver.com" />

<Button
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="Go"
android:id="@+id/btnGo"
android:onClick="goURL" />
</LinearLayout>

<WebView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/webView"
android:layout_weight="0.83" />

<LinearLayout
android:orientation="horizontal"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_weight="0.13">

<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:textAppearance="?android:attr/textAppearanceMedium"
android:text="Elapsed time :"
android:id="@+id/tvElapsedTime" />

<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:textAppearance="?android:attr/textAppearanceMedium"
android:text="sec"
android:id="@+id/tvSec" />
</LinearLayout>

</LinearLayout>

레이아웃이 디자인 되었으면, [GO]버튼을 눌렀을때, 웹뷰에 URL을 표시하도록 goURL(View)라는 메소드를 다음과 같이 구현하자


public void goURL(View view){
TextView tvURL = (TextView)findViewById(R.id.txtURL);
String url = tvURL.getText().toString();
Log.i("URL","Opening URL :"+url);

WebView webView = (WebView)findViewById(R.id.webView);
webView.setWebViewClient(new WebViewClient()); // 이걸 안해주면 새창이 뜸
webView.loadUrl(url);

}


사용법은 의외로 간단한데, Webview객체를 얻어와서 loadURL로 url을 로딩하면 된다. 이때 주의할점은 setWebViewClient()  메서드를 사용해야 하는데, 안드로이드에서는 디폴트로, 다른 링크로 이동하고자 할때는 안드로이드의 디폴트 외부 웹 브라우져를 통해서 이동하도록 하고 있다. 그래서 만약 setWebViewClient로 내부 웹뷰 클라이언트를 지정해주지 않으면 별도의 브라우져가 뜨는 것을 볼 수 있다.

그리고 이 애플리케이션은 외부 인터넷을 억세스하기 때문에, AndroidManifest.xml에서INTERNET 퍼미션을 추가해줘야 한다.


<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.terry.simplewebview" >
<uses-permission android:name="android.permission.INTERNET" />
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme"
android:hardwareAccelerated="true"> // 하드웨어 가속 사용
<activity
android:name=".MainActivity"
android:label="@string/app_name" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>

</manifest>


주목해서 봐야할점중 하나는 android:hardwareAccelerated  라는 필드인데, 웹 페이지를 렌더링 하는데 하드웨어 가속 기능을 사용하도록 하는 옵션으로, 이 옵션 사용 여부에 따라서 성능차이가 꽤 있기 때문에, 가급적이면 사용하도록 한다.


여기서 약간 개량을 해서, 해당 URL이 다 뜨고 나면 로딩하는데 걸리는 시간을 측정하는 로직을 추가해보자


public void goURL(View view){
TextView tvURL = (TextView)findViewById(R.id.txtURL);
String url = tvURL.getText().toString();
Log.i("URL", "Opening URL with WebView :" + url);

final long startTime = System.currentTimeMillis();
WebView webView = (WebView)findViewById(R.id.webView);

// 하드웨어 가속
// 캐쉬 끄기
//webView.getSettings().setCacheMode(WebSettings.LOAD_NO_CACHE);

webView.setWebViewClient(new WebViewClient(){
@Override
public void onPageFinished(WebView view, String url) {
super.onPageFinished(view, url);
long elapsedTime = System.currentTimeMillis()-startTime;
TextView tvSec = (TextView) findViewById(R.id.tvSec);
tvSec.setText(String.valueOf(elapsedTime));
}
});
webView.loadUrl(url);

}


setWebViewClient를 만들때, WebViewClient에 onPageFinished라는 메서드를 오버라이딩해서 종료 시간을 구할 수 있다. 이 메서드는 해당 URL이 모두 로딩되었을때 호출되는 메서드이다.


웹뷰의 개념 이해를 돕기 위해서 가장 간단한 예제를 통해서 설명하였는데, HTML 안에서 Javascript 를 사용하려면 별도의 옵션이 필요하고, 또한 javascript를 사용할때는 Javascript의 메서드를 실행하면, 안드로이드 애플리케이션내에 정의된 메서드를 수행할 수 있도록도 할 수 있다. 

기타 자세한 내용은 http://developer.android.com/guide/webapps/webview.html 를 참고하기 바란다.


웹뷰의 성능 향상과 확장


웹뷰에 대한 성능 관련 자료를 찾아보니, 성능이 안나오는 문제가 많아서 하이브리드 앱을 개발하는 쪽에는 다양한 솔루션이 제시되고 있다. 써드 파티 웹뷰 라이브러리를 이용하는 방법이나 또는 웹뷰를 커스터마이징 해서 WebSocket의 기능을 추가하거나 Canvas 성능을 개선하는 작업등이 있는데 (http://deview.kr/2013/detail.nhn?topicSeq=14) 성능 부분에 대해서는 조금 더 공부가 필요할듯 하고, 아래는 성능 관련해서 검색을 했을때 주로 많이 소개되는 내용을 정리하였다.


크롬뷰 사용


안드로이드 4.4 (API level 19)부터는 웹뷰에 대한 성능 개선의 일환으로 Chromium (http://www.chromium.org/Home

) 이라는 오픈소스( 브라우져가 사용되었는데, 별도의 설정없이도, 이 브라우져 기반의 웹뷰가 사용이 가능하다. Chromium 기반의 웹뷰는 성능 향상뿐만 아니라, HTML 호환성 개선도 같이 이루어졌다. 

https://www.google.co.kr/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=webview+performance+android&newwindow=1&start=10


일반적인 튜닝 옵션


일반적으로 웹뷰 성능 튜닝 관련 내용을 검색하면 단골로 나오는 3가지 튜닝 옵션들이 있는데 다음과 같다

  • 캐쉬 사용하지 않기 : webView.getSettings().setCacheMode(WebSettings.LOAD_NO_CACHE);로 브라우져 캐쉬를 끄는 방법이 언급되는데, 사실 캐쉬를 쓰는데 왜 성능이 올라가는지는 잘 모르겠다. 이 부분은 조금 더 살펴봐야할것으로 보이고
  • 하드웨어 가속 기능 사용하기 :렌더링에 대해서 하드웨어 가속 기능을 사용할지 여부인데, 3.0 부터 지원이 되기 시작했고, 디폴트는 false이며, 4.0부터는 default가 true이다. 앞의 예제에서와 같이 AndroidManifest.xml에서, android:hardwareAccelrated를  true로 설정해주면 된다.
  • 렌더링 우선 순위 높이기 : 강제적으로 렌더링 기능에 대한 우선 순위를 높이는 방법이다. webView.getSettings().setRenderPriority(RenderPriority.HIGH)로 설정해주면 되는데, API Level 18부터는 deprecated 되었기 때문에 하위 버전에만 적용될 수 있도록 한다.

외부 라이브러리를 이용한 웹뷰의 성능 향상


다른 성능 향상 방법으로는 써드 파티 라이브러리를 찾아봤는데, 가장 많이 사용되는 라이브러리로 크로스워크(crosswalk)라는 오픈 소스 라이브러리가 있다. https://crosswalk-project.org/documentation/getting_started.html

성능 향상은 물론이거니와, HTML5에 대한 호환성 지원도 매우 높고, 안드로이드뿐만 아니라, iOS,Tizen등 다양한 OS를 지원하기 때문에 하이브리드 앱을 개발한다면 탑재를 고려해볼만하지만, 이러한 호환성이나 성능을 높이기 위해서 렌더링 관련 기능을 모두 자체 구현하였기 때문에 앱 사이즈가 대략 30~40MB정도 커지기 때문에, 앱 크기에 대한 부담과 dex 사이즈에 대한 부담 (안드로이드 실행 파일인 dex는 메서드수가 65535개로 제한이 되어 있다.)

http://monaca.mobi/en/blog/crosswalk-performance/ 는 HTML5에 대한 호환성을 Crosswalk와 기본 웹뷰 사이에 수치를 비교한것인데, 일반 웹뷰는 278, 크로스워크는 호환성 부분에서 493 포인트를 낸것을 확인할 수 있다.


게임이나 일반 애플리케이션의 경우는 네이티브 앱 개발이 아무래도 대세가 되겠지만, SNS나 미디어성 컨텐츠는 개발의 용이성과 호환성 그리고 다양한 컨텐츠 포맷을 지원하는 점에서 HTML5 기술이 지원되는 웹뷰는 아무래도 필수적인 기술이 되지 않을까 싶다.


스파크 성능이 안나오면, 우리 회사 데이타팀 팀장왈. 먼저 파이썬으로 짰는지 확인 부터 해보라길래, 파이썬과 스칼라로 만들어진 스파크 성능 차이가 얼마나 나는지 찾아봤더니 다음과 같은 수치가 나왔다.


http://emptypipes.org/2015/01/17/python-vs-scala-vs-spark/ (원본 출처)


일단 스파크를 할려면 스칼라는 필수인듯 하다. 

간단한 프로토타입핑등에는 파이썬을 사용할 수 있겠지만 결국 프로적션은 스칼라로 최적화해야 할듯.

근데. 자바대 스칼라 성능 비교는 없네

Couchbase Server

#1 소개 및 설치

조대협 http://bcho.tistory.com


근래에 여러 NoSQL이 소개되었지만 그중에서 좋은 솔루션인데도 불구하고 그다지 국내에서는 널리 알려지지 않은 카우치베이스에 대해서 소개하고자한다. 모바일 게임중에 유명한 쿠키런의 경우 카우치베이스를 백엔드로 사용하고 있는데, 안정성이나 성능등이 매우 뛰어나고, 사용하기 또한 매우 쉽다. 오늘은 고성능 NoSQL 서버인 카우치베이스(CouchBase) 에 대해서 소개하고자 한다.


소개


예전에 메모리 캐쉬 솔루션인 memcached에 디스크 persistence 기능을 추가하여 membase라는 솔루션이 있었는데, 이 제품에 Apache의 카우치디비(CouchDB)를 기반으로 새롭게 만든 솔루션이 카우치베이스 Server 라는 NoSQL 솔루션이다.

카우치베이스는 mongoDB나, Riak과 같이 JSON document를 직접 저장할 수 있는 Document DB 형태를 가지며, NoSQL의 분산 이론인 CAP theorem에서 CP (Consistency & Partition tolerance) 의 부분에 해당하여 데이타에 대한 일관성과, 노드간의 네트워크 장애시에도 서비스를 제공할 수 있다. 근래에 들어서 600억원의 투자를 유치하는 등 가치를 인정 받고 있는데, mongoDB나 Cassandra에 가려서 그다지 주목을 받지 못하는 것 같아서, 이번 글을 통해서 소개하고자한다.


특장점


카우치 베이스는 다른 NoSQL에 비해서 다음과 같은 추가적인 특징을 더 가지고 있다.


Memcached 기반의 Level 2 캐쉬를 내장하여 빠름

카우치베이스는 앞에서도 설명하였듯이 membase를 기반으로 하였기 때문에, memcached를 자체적으로 Level 2 캐쉬로 사용하고 있다. 즉 자체적으로 메모리 캐쉬 기능을 가지고 있기 때문에 성능이 대단히 빠르다. 이번에 카우치베이스 社에서 발표한 자료에 따르면 mongoDB대비 약 6배 이상의 성능을 낸다고 한다. 


(http://info.couchbase.com/2014-Benchmark-Showdown-Results-LP.html)


모바일 디바이스와 Sync

카우치베이스 뿐만 아니라, 카우치디비 계열 DB들은 iPhone이나 Android와 같은 모바일 디바이스에 탑재 할 수 있고, 서버에 설치되 카우치디비 계열들과 Sync가 가능하다. 카우치베이스도 역시, 카우치디비 계열이기 때문에, 모바일 디바이스에 탑재할 수 있고, 서버와 Sync할 수 가 있다.


데이타 센터간 복제 가능

카우치베이스는 XACR(Cross Data Center Replication)이라는 기능을 이용하여, 물리적으로 떨어진 데이타 센터간에 데이타 복제가 가능하다.


Indexing, Grouping ,Ordering,Join 가능

아주 중요한 특징중의 하나인데, 대부분의 NoSQL은 Key/Value Store 형식으로, 개별 필드에 대한 Indexing이나, 필드별로 group by 를 해서 sum,count등을 하는 기능이나, 특정 필드별로 Sorting이 불가능하다. Indexing을 지원하는 경우도 있기는 하지만, 내부적으로 성능상 문제가 있는 경우가 많은데, 카우치베이스의 경우 이러한 성능상 문제를 해결 하면서도 RDBMS들이 지원하는 index, grouping, ordering 기능을 지원할 수 있다. 


확장이 쉬움

보통 분산 구조의 NoSQL의 경우, 노드를 확장하거나 특정 노드가 장애가 났을때의 처리가 어려운데, 카우치베이스는 장애가 손쉽게 장애 처리를 하고,새로운 노드를 추가할때 도 매우 쉽게 노드 추가가 가능하다. 이러한 장점은 운영 관점에서 큰 이점이 된다.


Built in 관리 도구 제공

마지막으로 카우치베이스는 웹 기반의 GUI 관리 도구를 기본으로 제공한다. 많은 NoSQL들이 별도의 관리, 모니터링 도구를 지원하지 않는데 반하여, 기본적으로 강력한 관리 도구를 제공하는 것은 큰 장점이 될 수 있다.


Memcached 프로토콜 지원

캐쉬 솔루션으로 유명한 Memcached 프로토콜을 그대로 지원하기 때문에, 기존의 Memcached 클라이언트를 그대로 사용할 수 있고, 기존에 사용하던 Memcached 인프라를 그대로 대체 할 수 있다.


스키마가 없는 유연한 저장 구조 (Scheme-less)

 스키마가 없는 구조는 카우치베이스뿐만 아니라 대부분의 NoSQL이 갖는 공통적인 특성이다. 스키마가 없기 때문에 하나의 테이블에 컬럼 형식이 다른 데이타를 넣을 수 있다. 즉 하나의 데이타 버켓에 데이타 구조가 다른 JSON 문서들을 넣을 수 있다는 이야기이다.

데이타 타입이 다름에도 불구하고, 공통되는 필드에 대해서, Indexing, grouping 등을 제공할 수 있다. JSON 도큐먼트에, county 라는 앨리먼트가 있는 도큐먼트들을 대상으로 grouping등을 할 수 있다는 이야기이다.

다양한 클라이언트 플랫폼 지원

자바,닷넷,PHP,루비,C,파이썬,node.js 등 다양한 클라이언트 라이브러리를 제공한다. 클라이언트 SDK는 http://www.couchbase.com/communities/all-client-libraries 에서 다운로드 받을 수 있다.


설치하기


카우치베이스를 설치하기 위해서는 www.couchbase.com에서 카우치베이스를 맞는 OS 플랫폼에 따라서 다운로드 받으면 된다. Enterprise Edition과 Community Edition이 있는데, Enterprise Edition은 별도의 상용 라이센스를 구입해야 하며 기술 지원등을 받을 수 있다. Community Edition은 무료로 개발이나 운영 환경에 사용할 수 있으나, 기술 지원등을 받을 수 없고,  Enterprise Edition에 비해서 버전이 낮다.

※ 참고로, 상용과 오픈소스 라이센스 정책을 함께 지원하는 솔루션의 경우에는 버전업이 되면서 라이센스 정책이 갑자기 바뀌는 경우가 많으니, 오픈소스의 경우 다운로드 전에 반드시 라이센스 정책을 확인하기를 바란다. 이 글을 쓰는 현재 Community Edition의 라이센스 정책 기준은 2.2.0을 기준으로 한다. 

여기서는 윈도우즈 환경을 기준으로 설명을 한다. 사이트에서 카우치베이스 server 를 다운로드 받고 실행을 하면 자동으로 설치 위자드가 실행되고, 설치가 진행된다.

 


설치가 다 끝나면, 자동으로 웹페이지가 열리면서, 카우치베이스에 대한 셋업이 시작된다.

 


설정 셋업을 시작하면 기본적인 서버 설정에 대해서 물어보는데

 


데이타 파일을 저장하는 경로와, 호스트명등을 물어본다.그리고 새로운 클러스터를 시작할지, 아니면 기존의 클러스터에 조인할지를 물어보는데, 여기서는 개인 개발 환경을 설정하는 것이기 때문에, “Start a new cluster”로 설정한다. 이때, 카우치베이스가 사용할 메모리 용량을 지정해야 한다. 개인 개발환경이기 때문에, 1G정도로 설정하자. 실제 운영환경에서는 최대한 크게 잡아줘야 한다. 카우치베이스에 저장되는 키와 데이타에 대한 메타 데이타는 모두 메모리로 로딩되기 때문에, 메모리 용량이 충분하지 않으면 제대로된 성능을 발휘할 수 없다.

인스톨이 완료된후에, 카우치베이스 웹 콘솔을 열어 보면, 다음과 같이 인스톨된 카우치베이스 서버의 상태를 볼 수 있다. 

 




자바스크립트 스터디 노트 #2

프로그래밍/JavaScript | 2014.06.19 16:52 | Posted by 조대협

실습중 코멘트

클래스 내에서 변수

var MyClass = function(){
    var local;                    // 생성자 내에서만 유효
    this.objectvalue;            // 객체 단위로 유효
}
MyClass.prototype.classvalue;    /// 클래스 단위로 유효

text와 html

$(‘#xxx’).html : <BR> 등의 HTML 태그가 반영됨
$(‘#xxx’).text : <BR> 등의 HTML 태그가 문자열로 저장됨 (실제 태그 효과가 없어짐)

JQuery

jqeury 엘리먼트는 생성자에서 객체 변수로 캐슁해서 사용하도록 하는 것이 좋다.

클래스

클내부 변수나 내부 메서드는 _를 사용하거나, _$로 시작하는 것이 좋다.
구글의 자바스크립트 네이밍 컨벤션 참고할것.

자바스크립트 엔진

싱글 쓰레드임을 명시 할것.
콜백은 비동기로 수행된다. 코드 순서대로 수행이 안되기 때문에 주의. 순차 실행이 필요한 경우, 콜백함수내에 정의할것

크롬데브툴

각 기능들에 대해서 간략하게 살펴본다.
자세한 기능은 https://developer.chrome.com/devtools/index

네트워크

헤더, 프리뷰등 리턴값을 볼 수 있고,
필터를 통해서, 헤더,바디,XHR등 특정 부분들만 보는 것도 가능하다.

소스

로딩된 자바스크립트나, CSS등을 볼 수 있다.
중요한 기능 - 소스 파일을 수정해서 반영해서 볼 수 있다. 서버에 있는 소스일지라 할지라도 가능. ADD Folder to workspace 라는 기능을 이용해서 브라우져에서 에디트해서, 추가할 수 있음. (내소스코드와 서버쪽 소스코드를 맵핑/일치 시킬 수 있다.)
디버깅하는 기능이 있음-보통 console.log로 디버깅하는데, 소스에서는 직접 소스를 봐서, 여기서 브레이크 포인트를 걸어서, 일반적인 IDE의 디버거처럼 사용할 수 있다. 브레이크 포인트를 걸때, 오른쪽 마우스 버튼을 누르면 conditional break point를 걸 수 있다. (변수나 특정 조건에 따를때만 브레이크를 거는 기능)
브레이크포인트에 걸렸을때, console에서 console.log 등을 이용해서 값들을 추척해볼 수 있다.

※ Snippet - 코드 조각을 저장하는 기능

엘리먼트

엘리먼트창에서 오른쪽에서 >= 메뉴를 누르면 에뮬레이션이라는 기능이 있음, 폰 종류를 골라서, 폰 형태에 맞춰서 보여줄 수 있음. (중요한 기능. )

타임라인

녹화 버튼을 누르면, 서버와 통신한 기록 내용을 볼 수 있음.
메모리 사용 기록 등

프로파일

CPU,메모리 힘등을 자세하게 프로파일링이 가능함
메모리 릭등을 잡을 때 사용이 가능함. (스냅샷을 여러개 찍어서, 스냅샷등을 비교할 수 있는 기능이 있음)

리소스

웹 SQL,Index SQL등을 살펴볼 수 있음.

Audit(감사)

페이지가 어떤 부분이 안좋다, 문제가 있다는 부분을 자동으로 검출해서 리포트를 출력해줌.
비슷한 기능으로 페이지 스피드라는 플러그인이 있음 (구글에서 만들어짐. )

콘솔

다양한 기능들이 있음. 단순히 console.log 를 찍는 출력이 아니라
CLI 명령을 사용할 수 도 있음.

console.time('111');
console.timeEnd('111');

00.000ms 단위까지 출력해준다. (자바스크립트는 일반적으로 ms 단위 측정만 가능한데, console은 더 미세한 측정이 가능함)

자바스크립트 라이브러리

www.jsdb.io에 들어가면 자바스크립트 라이브러리들이 잘 정리되어 있음.(분류가 잘 되어 있음)

  • 에니메이션 : 모바일에서는 3.js 정도가 유행. 특별하게 주류가 없음 보통 jquery 애니메이터를 사용함
  • 애플리케이션 툴 :
    • Angular.js,Ember,Backbone 들이 MVC 성격,
    • underscore는 유틸성으로 많이 씀.
    • underscore를 좀 더 빠르게 만든게 로우대쉬라는게 있음
    • 템플릿 엔진. Handlebar등 종류가 많음 . 템플릿 엔진은 코드와 뷰를 분리하는 관점에서 거의 필수이다.. 주로 성능이 선택 요소가 됨. (컴파일 방식이 빠름)
    • requirejs : 모듈화 툴
    • Q : Promise 패턴을 구현해놓았음. (async, callback hell등 처리) - 중첩 콜백을 간소화해서 코딩이 가능함.-
  • 오디오 : 사운드 메니져
  • 개발툴 :
    • Bower 유명은 한데, 실제로 적용하기가 어렵다. (패키지 정보등을 개인이 올리는게 아니기 때문에 )
    • JSHint 정적 검사툴 (Strict 하게 검사됨. 오류가 아닌것도 오류로 검색한다.)
    • Grunt 빌드도구
    • Jasmine 테스트
  • DOM 핸들링
    • JQuery : 가장 강력함.
    • Prototype : 도태됩
    • BootStrap : 많이 쓰는 UX
  • 이미지
    • Three JS 3D에서 유명함

자바크립트 테스팅

Jasmine,QUnit,Mocha 등이 사용됨.
Mocha는 Mocha 단독만으로는 안씀. (다른 라이브러리와 섞어 쓰는게 추세, 어떤 라이브러리?) NPM 랭킹으로는 Mocha가 더 높음
※ 자바스크립트 문서와 도구는 JSDOC을 많이 사용함

정적 검사

JSLint (이게 더 스트릭트), JSHint
실제 프로젝트에는 JSHint가 더 적용하기 좋음. 반드시 실제 프로젝트에서는 사용하도록 하자

최적화

자바스크립트도 느리다. IE8 같은것을 해보면, 느리다. 최적화가 필요하다.

Reflow

비용이 크다. (리플로우를 최소화해야 한다.)
개념을 잡을려면 유투브에서 reflow 라는 이름으로 동영상을 찾아보면 실제 화면을 렌더링 하는 동영상들이 있음.
: 화면이 렌더링 되는 과정 주로 언제 발생되냐?

  • 화면에 표시되는 구성요소의 크기,위치,표시 방법등이 변경되는 경우들과 같이 스타일을 지정하거나, 또는 스타일 값을 가져올때

    obj.style.width=
    obj.style.height=

  • 화면에 객체가 추가 제거되는 경우
  • 스크롤과 관련

어떻게 조심 하냐?

  • 객체 추가제거 : 하나씩 append하는게 아니라, body.innderHTML=”문자열” 같이 한방에 추가한다. 효과가 매우 좋음 단 실제로 객체단위로 관리가 안됨
  • documentFragment : 객체 단위로 관리를 하기 위해서 화면에 표시 되지 않는 껍데기 document를 만들어놓고, 사용함 (innerHTML 방식이 더 빠름)

    document.createDocumentFragment

  • CSS 변경 : 화면에 적용되기 전에 element를 만들어서 붙임
    예제 sudo code
    var obj = createElement()
    obj.style.width=xx
    obj.style.width=xx
    document.addElement(obj)
    
  • 캐쉬 : 속성들의 값을 가지고 오는 것을 줄이기 위해서, 캐쉬를 이용하는 방법을 쓰자. DOM 접근 비용도 크다. Parent element를 캐슁하는 것도 방법. 그 dom 까지 찾아가는 시간 까지도 줄일 수 있음.
  • CSS 변경 : 스타일 룰 방식(CSS Rule) : (자세한것은 찾아볼것)
  • CSS 클래스를 잘 활용
    ※ jsPerf라는 사이트를 이용하면, before, after의 코드 성능을 비교해볼 수 있다.
  • HTML collection은 배열처럼 보이지만, Collection은 문서에 정의된 순서대로 변환하기 위해서 그때 마다 DOM 파싱이 발생한다. 대층 객체 목록을 반환하는것 childNode, getElementByTagNames() 등등
  • CSS selector
    • 선택자는 오른쪽에서 왼쪽으로 탐색한다.
    • 선택자는 구체적이기 보다는 간단하게 하는게 더 좋다. (구체적이면 구체적으로 나열한거 다 찾는다.)
    • 아이디는 엘리먼트를 찾는 가장 빠른 방법이다.
    • 검색 범위는 줄여주는게 좋다.

자주 하는 실수

  • HTML element가 로드 되기 전에, javascript가 로드 되어서, 엘리먼트를 참조하는 사례 —> 자바스크립트를 HTML이 로딩된 다음에 로딩 되도록 <script> 태그를 body 아랫부분에 넣으면 됨

box2d 라는 물리 엔진
네이버의 collie라는 게임,에니메이션용 엔진이 있음

VisualVM을 이용한 JVM 모니터링

성능과 튜닝/JVM | 2013.09.05 23:30 | Posted by 조대협

JVM Monitoring

조대협

 

JVM 1.4 버전대에만 해도 GUI 기반으로 JVM을 모니터링 하는 도구는 거의 없었다. 콘솔로 접속해서 Thread dump GC 로그등을 분석하거나 필요할 경우 JMX 기반의 모니터링 명령어등을 만들어야 했는데, 근래에는 좋은 모니터링 도구들이 많이 나와서, 쉽게 JVM의 상태를 모니터링 할 수 있고, 메모리,CPU 사용률, Thread 현황들을 매우 쉽게 분석할 수 있다.

여기에, 여러개의 VM을 동시에 중앙에서 매우 세세하게 모니터링이 가능하게 되었다.

여기서는 몇가지 자주 사용되는 JVM 모니터링 툴을 소개하고자 한다. 

VisualVM

대표적인 도구로는 오픈소스 기반의 Visual VM이라는 도구가 있다. http://visualvm.java.net/

에서 다운로드 받을 수 있다. 여러개의 VM을 동시 모니터링이 가능할 뿐만 아니라, profiling도 가능하고, eclipse 안에 embed 해서 사용할 수 도 있다.

먼저 사용법을 알아보자. VisualVM을 다운받은 후에, 압축을 풀어놓는다.다음은 원격지에 있는 VM을 모니터링 하는 설정이다. 모니터링할 VM 서버에서 먼저 rmiregistry 서버를 기동한다.

C:\dev\lang\jdk1.7\bin>rmiregistry 1099

 

다음으로는 VM에 대한 정보를 접근할 수 있도록 permission을 허용해야 하는데, ${java.home}/bin 디렉토리에 tools.policy라는 파일을 다음과 같이 만든 후에,

grant codebase "file:${java.home}/../lib/tools.jar" {

   permission java.security.AllPermission;

};

jstatd 라는 데몬을 기동 시킨다.

C:\dev\lang\jdk1.7\bin\> jstatd -p 1099
   -J-Djava.security.policy=tools.policy

위의 설정까지 하면 기본적인 VM에 대한 상태 정보 (메모리)를 모니터링할 수 있는데, 조금 더 상세한 모니터링을 위해서, JVM JMX 설정을 on 한다.

다음은 Tomcat JMX 설정을 하기 위해서 ${tomcathome}/bin/catalina.bat를 수정한 내용이다.

JVM옵션에 다음과 같은 내용을 추가 하면 된다.



set JAVA_OPTS=%JAVA_OPTS% %LOGGING_CONFIG% -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=9983


여기 까지 했으면 모든 준비가 끝났다.

주의할점은, 실제 운영이나 개발 환경들에 이러한 설정을 적용할때, 포트가 외부에 오픈 되기 때문에, 보안상 문제가 될 수 있다. 그래서 반드시 OS (Linux) iptable 설정등에서, VisualConsole이 인스톨 되는 서버로 부터의 inbound connection 만 오픈하도록 하는 것이 좋다.

Visual VM을 실행하고, Remote Host Add하고, ip 주소와 위에서 지정한 포트를 지정하면 아래와 같이 VM을 모니터링 할 수 있다.

아래 그림은 편의상 local에 있는 JVM을 모니터링 하도록 설정하였다.



여기서는 전체 VM에 대한 Thread 개수, Class개수와 기본적인 CPU JVM 메모리 상황을 모니터링 할 수 있다.

 

다음은 Thread를 모니터링 하는 화면이다. time frame에 따라서 어떤 thread가 있고,어떤 상태인지를 모니터링이 가능하다.



 

아래는 Thread dump 추출 화면이다. 좌측 메뉴에서 JVM을 선택하고 오른쪽 마우스 버튼을 이용하면 Thread dump 추출 메뉴가 나오는데, 아래 그림과 같이 추출한 Thread dump를 저장해서 보여준다. Bottleneck 분석등에 매우 유용하게 사용할 수 있다. 



다음은 성능 튜닝 부분에서 유용하게 사용할 수 있는 기능인데, profiling 기능을 제공한다.

우측 상자에 profiling하고 싶은 class (패키지명)을 지정해놓고, start를 하게 되면, 각 패키지 또는 클래스에서 소요되는 CPU 사용량을 보여준다. 


이를 이용하면 손쉽게 CPU 소모가 많은 모듈을 찾아낼 수 있다.


 

JConsole

참고로, JVM을 인스톨 하면 default로 인스톨 되는 GUI 기반의 JVM 모니터링 툴이 있는데, ${java.home} jconsole이라는 유틸리티이다.

VMConsole 처럼 permission이나 rmi setting이 필요 없고, JMX를 이용해서 통신을 한다.

기능상으로나 UI 면에서는 개인적으로는 Visual VM이 더 났다고 판단하는데, JConsole의 경우에는 모니터링 대상 VM이 제공하는 MBean(JMX)를 모니터링 할 수 있다.

Tomcat이나 각종 자바 서버들은 MBean을 통해서 서버의 상태나 Configuration  정보를 저장하기 때문에 이 MBean 만 모니터링 하더라도 서버의 상태를 알아내는데 매우 유용하게 사용할 수 있다.

아래 그림은 JConsole을 이용하여, Tomcat MBean을 모니터링 하는 화면이다.

 


 


 2013.9.12 추가. Oracle JVM 7 최신 버전에 multiple JVM을 monitoring 할 수 있는 JMC 라는 것이 포함 되었음

http://www.oracle.com/technetwork/java/javase/2col/jmc-relnotes-2004763.html


 

'성능과 튜닝 > JVM' 카테고리의 다른 글

VisualVM을 이용한 JVM 모니터링  (0) 2013.09.05
G1GC Collector  (0) 2009.04.22
새로운 GC Collector G1.  (1) 2009.04.20
JVM 튜닝  (5) 2008.03.12
Sun JVM HeapDump 얻기  (1) 2007.11.28
-XX:PretenureSizeThreshold  (0) 2007.11.10

성능 엔지니어링에 대한 접근 방법

조대협


성능 개선, Performance Tuning, 용량 선정 과 같은 튜닝 관련 용어들은 모든 개발자나 엔지니어에게 모두 흥미가 가는 주제일 것이다. 그 만큼 소프트웨어에서 고성능을 내는 시스템은 만들기도 힘들뿐더러, 고성능 시스템이란 즉 잘 설계되고 구현된 소프트웨어를 뜻하는 것이니 관심을 가지는 것이 당연하지 않을까 싶다.

필자의 경우, 엔터프라이즈 시스템에 대한 약 6년간 장애 해결, 장애 회피 설계, 성능 개선, 고성능 시스템 설계 및 구현에 관련된 일을 해왔다.  특히 장애 해결과 성능 개선 작업은 하고 나면 뿌듯하기는 하지만, 특정한 기술이 필요하기 보다는 문제를 정의하고 접근하는 능력과 끝까지 목표를 달성할 때까지 지루한 작업을 반복적으로 할 수 있는 인내심을 필요로 하는 작업이다

이번 챕터에서는 Performance Engineering의 전반적인 접근 방법과, 용량 산정 방법 그리고 자바 기반의 서버 애플리케이션에 대한 성능 튜닝 및 병목 발견 방법에 대해서 설명하고자 한다.

Performance Engineering 의 정의와 범위

Performance Engineering은 시스템의 목표 성능 (응답 시간과 동시 접속자수)을 정의 하고, 이를 달성하기 위해서, 시스템의 구조를 반복적으로 개선하는 작업을  이야기 한다.

좁게 생각하면, 코드상의 병목을 잡고, 시스템의 설정(Configuration)을 바꿔서 성능을 올리는 튜닝으로 생각할 수 있지만, 성능 목표의 정의에서 부터, 최적의 성능을 내기 위한 디자인 및 구현과 같은 개발 초기의 설계 부분와 개발후의 운영단계에서 모니터링 까지 전과정을 포함한다.

Performance Engineering은 언제 해야 하는가?

Performance Engineering은 전체 소프트웨어 개발 과정에 걸쳐서 크게 아래와 같이 4단계에 걸쳐서 일어난다.



위의 개발 모델은 전형적인 Water fall model이다. 개발프로세스 챕터에서도 설명하였지만, 스크럼과 같은 애자일 방법론을 사용하더라도 큰 범위에서 개발 사이클은 Waterfall 모델과 크게 다르지 않게 된다. (각 단계별을 SPRINT 단위로 수행한다.)

   분석 단계

초기 요구 사항 분석 및 시스템 기획 단계에서는 성능에 대한 목표를 정해야 한다.

목표 응답시간은 어떻게 되는지, 시스템을 사용할 총 사용자수와 동시에 시스템을 사용하는 동시접속자 수가 어떻게 되는지와 같은 성능 목표를 정의한다.

또한 고려해야 하는 사항중의 하나는 성능 모델이다. 시스템에 부하가 어떤 패턴으로 들어오는지를 정의할 필요가 있다.

예를 들어 일반적인 웹컨텐츠 사이트의 경우 사용자가 들어와서 페이지 컨텐츠를 1~3분 내에 읽고 다른 페이지로 이동하다가, 20 여분 후에는 로그아웃하거나 다른 사이트로 이동한다. 즉 한 사용자의 체류 시간은 20분정도되며, 총 평균 20 페이지를 보는 트렌젝션을 발생 시키고 나간다고 할 수 있다. 한글로 만든 사이트이고, 육아나 주부를 대상으로 한 사이트라고 가정하면, 시스템의 부하는 한국 시간으로 아이들이 학교나 유치원을 간후인 10~11시와, 저녁시간대인 10~12시 사이에 몰린다고 가정할 수 있다.

다른 예로 게임 시스템을 예로 들어보자, 주로 초등학생을 타켓으로 한 게임이라면, 방과후 시간인 3~5시 대에 부하가 가장 몰릴 것이며, 게임의 종류에 따라 다르겠지만, 스타크래프트와 같은 게임의 경우 한번 플레이에 40분 정도 소요가 되고, 한 사용자가 하루에 두번정도 게임을 한다 가정 아래, 사용자당 체류 시간은 2시간, 게임 횟수는 2/. 그리고 주요 부하는 3~5시 오후대 라는 성능 모델을 만들 수 있다.

초기 성능 정의는 서비스의 종류(,게임,기업 시스템,쇼핑,뱅킹등) , 서비스를 사용하는 사용자층, 그리고 서비스를 사용하는 지역. 즉 전세계를 서비스하는 시스템이라면 시스템의 부하는 365,24시간 거의 다 걸린다고 봐야 한다. 그러나 한국만을 대상으로 서비스 하는 한국어로 된 사이트인 경우, 새벽 시간에는 일반적으로 로드가 없는 것과 같은 한국의 시간대에 영향을 받을 뿐만 아리나 명절,휴일,휴가와 같은 한국이라는 국가 특성에 따라 시스템의 부하가 영향을 받는다.

   디자인 단계

다음으로는 디자인 단계에서는 목표 성능과 용량을 달성할 수 있는 규모의 시스템으로 설계를 진행한다.

성능 관점에서 시스템 디자인은 항상 Peak Time (최대 성능)에 맞춰서 디자인이 된다. 최대 성능을 기반으로 전체 시스템이 받아낼 수 있는 용량과 응답 시간을 고려해야 한다.

특히 성능과 용량은 애플리케이션 디자인 뿐만 아니라 Technology selection에도 많은 영향을 받는다. 어떤 하드웨어를 사용할 것인지, 어떤 미들웨어나 프레임웍을 사용할 것인지이에 따라 용량과 성능의 차이가 많이 발생하기 때문에, 디자인 단계에서 부터 성능과 용량을 감안해서 시스템을 설계해야 한다.

하드웨어 관점에서는 예전에는 성능 모델을 산정한 후에, Peak Time 기준 (최대 성능 요구)으로 시스템을 설계하고, 하드웨어를 구매 하였으나, 근래에는 클라우드를 이용하여 필요시에만 하드웨어를 탄력적으로 사용하는 Auto Scale Out 모델을 많이 사용한다.

기업 내부의 업무 처럼 (예를 들어 이메일), 부하가 일정하고 예측이 가능한 경우에는 Fixed 된 사이즈의 하드웨어를 사용하도록 설계 하고, 출시 이벤트 행사 사이트와 같이 부하가 갑자기 몰리는 시스템의 경우 클라우드를 고려해보는 것도 권장할만 하다.

또한 빠른 응답 시간이 필요할 경우 SSD 디스크를 사용하거나, RAID 구성도 5보다는 1+0 등을 고려하는 등, 성능 모델에 따라서 적절한 하드웨어 선정과 구성 설계가 필요하다.

미들웨어나 프레임웍 관점에서도 정의된 성능 모델에 따라 적절한 제품군과  설계 구조를 채택해야 한다. 100,000 사용자 정도의 시스템 규모에서는 RDBMS 를 사용해도 성능이나 용량상에 문제가 없다. 그러나 50,000,000 사용자 정도를 지원해야 하는 시스템의 경우 그냥 RDBMS 를 사용할 수 없다. Sharding이나, NoSQL과 같은 다른 차원의 접근이 필요하다.

또한 빠른 응답 시간을 요구하는 경우 Redis Memcached와 같은 Cache 솔루션을 적극적으로 활용하거나, 미들웨어 부분에서는 Tomcat과 같은 일반적은 Web Application Server 보다는 Netty Vertex와 같은 고성능 미들웨어를 고려해볼 수 있다.

이러한 성능이나 용량에 관련된 제품 선정이나 설계는 돌려 보지 않으면 사실 확신을 가지기 어렵다. 그래서 가능하면, Technology selection 후에, 간단한 프로토타입을 구현한후에 시나리오가 단순한 대규모의 성능 및 용량 테스트를 해보는 PoC (Proof Of Concept)과 같은 작업을 이 단계에서 수행하는 것을 권장한다.

   개발단계

개발 단계는 개발프로세스 챕터에서 설명하였듯이, risk 가 높은 부분과 아키텍쳐에 관련되는 부분, 난이도가 높은 부분, 핵심 기능등을 개발 초기의 스프린트에서 개발한다.

초기 스프린트가 끝나고 릴리즈가 되서 성능 테스트가 가능한 QA나 스테이징 환경으로 시스템이 이전되면, Performance Engineering 역량을 이 단계에 집중하여, 시스템의 아키텍쳐와 모듈들이 성능 목표를 달성할 수 있는지 지속적으로 테스트하고 튜닝을 수행한다.

초기 단계에 성능 목표의 달성 가능 여부가 판단되어야, 아키텍쳐 변경이 가능하고, 주요 성능 이슈들을 초반에 발견해야, 발견된 성능 문제들에 대해서는 같은 문제가 발생하지 않도록 디자인 가이드나 코딩 가이드를 개발자들에게 배포하여 성능에 대한 위험도를 줄일 수 있다.

   최종 테스트 단계

앞의 단계에서 성능과 용량을 고려해서 설계가 되었고, 개발 초기 단계에서 성능과 용량 부분을 검증을 제대로 하였다면, 최종 테스트 단계에서는 개발된 최종 시스템에 대한 성능과 용량 부분의 측정과 미세 튜닝 (애플리케이션의 병목을 찾아서 부분적으로 수정하거나, 하드웨어나 미들웨어의 Configuration 하는 수준)을 하는 정도로 마무리가 되어야 한다.

이 과정에서는 실수로 잘못한 설정(configuration) 이나 잘못된 코딩으로 된 부분에 대해서 검증이 이뤄지는데, 이 경우에는 보통 2배에서 크게는 10배까지의 성능 향상이 이루어진다. 이런 경우는 대부분 실수에 의한 것이고 성능이 터무니 없이 낮게 나오기 때문에 찾기가 쉽다.

예를 들어 로그 파일을 NFS와 같은 리모트 디스크에 쓴다던지, Intel 계열의 CPU에서 하이퍼쓰레딩을 ON을 안했다던지와 같이 실수에 의한 경우가 많다.

이런 오류성의 문제들이 해결되면 실제 미세 튜닝에 들어가게 되는데, JVM 튜닝이나 톰캣의 설정 튜닝, SQL 튜닝들이 이루어지는데, 이 미세 튜닝을 통해서는 비약적인 성능향상은 이루어나지 않는다. 보통 20% 내외 정도 성능이 올라간다고 보면 된다.

   운영 단계

마지막으로 시스템이 운영 단계로 넘어가게 되면, 테스트시에 발견되지 않은 성능적인 문제가 있을 수 있기 때문에, 모니터링 도구를 사용하여 지속적으로 성능을 모니터링 하고, 성능상에 문제가 있는 부분을 지속적으로 수정해야 한다. 웹서버의 access로그에서 응답 시간을 모니터링 하거나, 제니퍼(http://www.jennifersoft.com)과 같은 전문적인 APM (Application Performance Monitoring)툴이나, Ganglia와 같은 시스템 모니터링 도구를 사용하면, 시스템의 성능 상태를 잘 알 수 있다.

더불어 용량 부분에 대해서도 운영단에서는 고민을 해야 하는데, 일반적으로 PEAK Time의 시스템 용량이 (CPU) 80% 정도에 다다르면, 시스템 용량 증설을 고려해야 한다.

그리고 업무에 특성에 맞게 미리미리 용량을 준비해놓는게 좋다. 예를 들어 대학의 수강 신청 시스템의 경우, 학기 시작하는 날에 부하가 폭주하기 때문에,  클라우드 기반일 경우 수강신청 전에 시스템 수를 미리 늘려놓는다던지, 클라우드가 아닌 경우, 수강 신청 기간을 앞뒤로 서버를 임대해서 용량을 늘려놓는 등의 대책을 미리 세워놓을 수 있다.

마지막으로, 운영 단계에서 Performance Engineering 관점으로 챙겨야 하는 부분은 운영 로그의 수집이다. 성능 및 용량 목표 설정은 매우 중요한 과정이다. 특히 용량 목표의 경우에는 기존의 업무 시스템의 사용 패턴을 분석 하는 것이 가장 효율적이기 때문에 운영 시스템의 로그를 수집하고 분석하여 운영 중인 업무 시스템의 성능 모델을 분석 및 보유 해놓는 것이 좋다.

시스템 용량 산정 (Capacity Planning)

  더 자세한 설명에 들어가기 앞서서, 성능에 관련된 용어와 함께 시스템의 목표 용량 산정 방법에 대해서 이야기 해보도록 하자.이 용어는 이 글에서 정의하는 의미의 용어이며, 다른 성능 이론에서 언급되는 용어와 다소 다를 수 있다.

l  Response Time (응답 시간) : 사용자가 서버에 요청을 한 시간에서 부터, 응답을 받을 때 까지의 모든 시간을 포함한다. 이 응답시간은 내부적으로 다음과 같이 조금 더 세분하게 분리된다.



Network Time (또는 Latency time). 서버에 요청을 했을때, Request를 보내고 받을 때 소요되는 네트워크 시간을 의미한다.

Transaction Time : 서버에서 실제 트렉젝션이 처리되는 시간을 의미 한다.

Think Time : 사용자가 요청에 대해서 응답을 받은 후에, 웹페이지를 보거나 화면을 보는 등의 작업을 하는 시간의 의미한다.

예를 들어 보면 한국의 사용자가 미국이 페이스북을 사용한다고 했을때, 사용자가 웹 브라우져에서 클릭을 하면, 요청이 서버로 도달할때 까지 걸리는 시간 Network time (Request), 서버가 요청을 받아서 처리를 하고, 응답을 하는 시간 (Transaction Time), 그리고 그 응답이 사용자의 브라우져 까지 도착하는 시간이 Network time (Response) 이다. 이 전체 시간을 합친 것이 Response Time이 된다.

응답을 받은 후에는 사용자가 페이스북 내용을 보는데 소요 되는 시간이 Think Time이 된다.

Think Time 까지 포함하여 다음 요청이 발생하기 까지의 전체 시간을 Request Interval 이라고 한다.

l  Concurrent User (동시 사용자) : 시스템을 현재 사용하고 있는 사용자를 정의한다. 웹사이트를 사용하기 위해서, 현재 브라우져를 열어놓고 웹사이트를 보고 있는 것과 같이 현재 시스템을 사용하고 있는 사용자 수를 의미 한다.



위의 그림을 보자, 5명의 사용자 A~E가 있다고 가정했을 때, 단위 시간 10분동안에 Transaction  Time Think Time중에 있는 사용자는 A,B,C 3명으로 해다 시간 10분간의 Concurrent User 3명이 된다.

l  Active User (액티브 사용자) : 현재 시스템에 트렌젝션을 실행하여 부하를 주고 있는 사용자를 정의한다.

기존에는 Concurrent User Active User간의 차이가 없었다. 이 개념은 웹이 생기면서 구체화된 개념인데, 웹 사이트를 사용하기 위해서 컴퓨터 앞에 앉아 있는다고 하더라도, 웹 페이지가 로딩 되는 순간에만 서버는 부하를 받고, 페이지가 웹 브라우져로딩 된 후에는 부하를 받지 않고 사용자는 로딩된 페이지를 보는데 시간이 발생한다. 이 시간동안에는 서버는 부하를 받지 않는다. 즉 시스템을 사용하기 위해서 웹 사이트를 열어 놓고 있는다 하더라도 지속적으로 서버에 부하를 주는 것이 아니기 때문에 Concurrent  User Active User 의 개념 차이가 발생한다.

Active User는 클릭을 발생시켜서 그 시간 당시에 서버에 트렌젝션을 발생 시키는 사용자를 의미한다.

Active User의 수는 서버에서 순간 실행되고 있는 Thread (쓰레딩 기반의 자바 서버의 경우) Process의 수와 같다. Active User의 수는 실제로 서버가 동시에 처리할 수 있는 트렌젝션의 양을 판단할 수 있는 기준이 되기 때문에 매우 중요한 성능 Factor가 된다.



위의 그림을 보자, 위의 그림에서 특정 순간에 있는 사용자는 총 5 명으로 Concurrent User 5명이지만, Transaction Time 구간중의 있는 사용자는 A,B,C , Active User 3명이 된다.

l  Transaction (트렌젝션) : Transaction이란, 사용자로 부터의 요청을 다루는 단위를 정의 한다. 이 정의가 상당히 중요한데, 성능 모델링이나 성능 테스트 시 이 Transaction의 정의에 따라서 시스템의 성능이 매우 다르게 정의 된다.

예를 들어서 사용자가 웹 페이지를 클릭했을때, 그 페이지에 대한 응답을 받는 것 까지를 하나의 트렌젝션이라고 정의 하자.

이 때, 웹페이지에는 서버에서 생생된 HTML 이외에, 여기서 참고 하는 리소스 즉, 이미지나 동영상, 자바 스크립트들이 들어있을 수 있다. 이 경우 트렌젝션에 대한 응답 시간을 측정할때, HTML 생성 이외에 이러한 리소스들을 로딩 하는 것 까지 하나의 트렌젝션으로 정의 해야 하느냐를 고려해야 한다.리소스에 로딩을 트렌젝션의 범위로 넣게 되면 전체 시스템의 응답 시간은 떨어지게 된다. (리소스를 로딩할 때 까지 기다려야 하니).

이러한 트렌젝션의 정의는 무엇을 판단 기준으로 할것인가에 따라 결정이 되는데, 예를 들어 리소스를 톰캣과 같은 WAS에서 처리하지 않고 앞단의 CDN이나 웹서버에서 처리할 경우 톰캣은 리소스에 대한 트렌젝션 요청을 받지 않기 때문에, 전체 시스템에서 비지니스 로직에 대한 처리 성능을 측정하고자 할 때는 리소스에 대한 로딩 시간을 계산하지 않고 트렌젝션을 정의 한다.  또한 리소스에 대한 로딩은 비지니스 로직에 대한 처리에 비해서 부하가 상대적으로 매우 적고, 일반적으로 브라우져에 캐쉬되기 때문에 보통 서버의 성능 측정시 이러한  리소스 로딩에 대한 부하는 트렌젝션의 단위로 처리하지 않는 경우가 많다.

l  TPS(Transaction Per Second) : 초당 처리할 수 있는 트렌젝션의 양을 정의 한다. 주로 서버의 성능 평가 기준이 된다.

Active 사용자가 순간 Transaction을 처리한다고 하면, 이를 목표 응답시간 (Response Time)으로 나눈 값이 목표 TPS가 된다. 예를 들어, Active User 50 명이고, 개당 Response Time 2초 라고 하면, 이 시스템의 TPS 25 TPS가 된다.
Network time이 미세하다고 판단하여, Network time 0으로 가정하여 계산

l  HPS(Hit Per Second) : 시스템이 처리할 수 있는 모든 웹 request의 초당 처리량이다. TPS가 비지니스 트렌젝션에 대한 처리 시간만을 정의 한다면, HPS는 리소스 (이미지, 자바스크립트)에 대한 request 처리량을 포함하기 때문에, TPS에 비해서 10~20 배 정도 높게 나온다.

l  Peak Time(피크 타임) : 서버가 순간적으로 가장 부하를 많이 받는 순간을 정의 한다. 보통 서버의 용량 산정이나 성능 설계는 이 시간의 부하량을 기준으로 한다

일반적인 업무 시스템의 경우, 출근 9~930분 사이가 가장 부하가 높다. 이 때 Peak (최고 정점)을 찍는 순간의 동시 사용자 수와 기준 응답 시간을 목표로 성능 목표를 정의 하는 것이 일반적이다.

위의 개념을 정리해서 공식화 해보자.

   TPS = (Active User) / (Average Response Time) – F1

   TPS = (Concurrent User) / (Request Interval) – F2

   Active User = TPS * (Average Response Time) – F3

   Active User = (Concurrent User) * (Average Response Time) / (Request Interval) – F4

   Active User = (Concurrent User) * (Average Response Time) / [ (Average Response Time) + (Average Think Time) ] – F5

예를 들어 Concurrent User 300명이고, 목표 응답시간이 3초 이내이며, Think Time 15초 인 시스템의 경우, F5 공식에 따라서 Active User 300*3/(3+15) = 50 이 되며, 시스템의 Thread 또는 적정 Process 양은 50개가 된다. 목표 TPS는 약 16.6 TPS가 된다.

위의 공식은 어디까지나 이론적인 공식이다. Network Latency 값은 가변적이며, Think Time 또한 유동적이다. 그러나 용량 산정에는 어느 정도의 산정 기준이 필요하기 때문에, 이 공식을 사용하면 대략적인 시스템에 대한 요구 용량을 예측할 수 있다.


Performance Engineering 의 절차

그러면 어떤 절차로 성능과 용량을 측정하고 개선하는 절차에 대해서 알아보도록 하자.

성능 목표와 모델의 정의

먼저 주요 업무 패턴이나, 튜닝의 대상이 되는 시나리오에 대한 개별 성능 목표를 정의 한다. 예를 들어 전체 성능 목표가 1,000 동시 사용자에 대해서 응답 시간 1초내의 시스템이 전체 성능 목표라고 가정하고, 전체 성능 목표를 대략 1,000 TPS (Transaction Per Second)라고 하자. 이것이 바로 성능 목표가 된다.

다음으로 성능 모델을 정의 해야 하는데, 해당 시스템의 주요 사용자 시나리오가 여러개 있을 때, 각 시나리오별의 사용 비중을 정의 해야 한다.

예를 들어 사진을 저장하는 클라우드 서비스 시나리오가 있다고 하면, 이 서비스의 주요 사용자 시나리오는

   로그인

   사진 리스트

   사진 업로드

   사진 보기

   사진 다운로드

   로드 아웃

등이 된다. 이 중에서 한 사용자가 실행하는 비율을 따져야 한다. 즉 사용자가 로그인 한후, 리스트 보기를 10, 업로드를 2, 보기를 5, 그리고 다운로드를 1번 한후에 로그 아웃 한다고 하자. 그러면 비율은 다음과 같이 된다. (전체 트렌젝션 횟수 1+10+2+5+1+1 = 20)

성능 모델 :로그인의 비율 5%, 리스트 보기 50%, 업로드 10%, 보기 25%, 로그아웃 5%

이 비율을 기준으로 복합 시나리오 (전체 시나리오를 함께 돌리는) 부하테스트를 수행하였을때, 1000 TPS가 나와야 하고, 각 개별 시나리오에 대해서 최소한, 로그인의 경우 1000 TPS 5% 50 TPS, 리스트 보기는 500 TPS를 상회 해야 한다.

부하 생성

성능 모델이 정의 되었으면, 이 모델에 따라서 부하를 생성해야 한다.

부하 생성 도구는 여러가지가 있다. 대표적인 오픈 소스 도구로는

가장 간단하게 쓸 수 있는 도구로는 Apache AB 라는 명령어 기반의 도구가 있으며, 복잡한 스크립트를 지원할 수 있는 도구로는 grinder apache JMeter 등이 있으며, NHN에서 grinder enhancement해서 만든 (GUI가 지원되는) nGrinder라는 도구가 있다.

근래에는 국내에서는 nGrinder라는 도구가 많이 사용되고 있다.

성능 모델이 단순하고, 테스트 시나리오가 간단할 경우에는 Apache ab 등으로도 가능하지만, 스크립트가 복잡해지는 경우에는 nGrinder와 같은 도구가 유리 하다.

또한 부하 생성에 사용되는 스크립트는 복잡도가 생각보다 높고, 향후 regression(회귀) 테스트에도 재 사용되기 때문에, 반드시 형상 관리 시스템을 통해서 (VCS) 관리 하는 것을 권장한다.

※ 자세한 부하 테스트에 대한 방법은 “4장 테스트의 시스템 테스트 부분을 참고하기 바란다.

 

※ 클라우드 컴퓨팅과 부하 테스트 툴 라이센스 모델에 대해서

 

예전에는 부하 테스트가 사내에서 사내에 있는 시스템을 대상으로 했었기 때문에 큰 문제가 없었다. 그러나 근래 들어서 클라우드 컴퓨팅을 사용하는 사례가 늘어남에 따라, 서비스 시스템이 회사 밖에 즉, 클라우드에 있는 경우가 많아 졌다.

상용 부하 테스트툴의 경우에는 부하 발생기의 위치와 툴 사용자에 대해서 제약을 두는 경우가 있는데, 툴을 구매했다 하더라도, 부하 테스터의 controller (부하 발생기 제외)는 반드시 사내에 있어야 하며, 사용자 역시 그 회사의 내부 직원으로만 한정하는 경우가 있다.

예를 들어, 내가 부하 테스트 도구를 서울에 있는 회사에서 구매하여, 이 툴을 Amazon 클라우드 미국에 설치하고 부하 테스트를 미국 지사 직원을 통해서 진행하는 것이 불가능 하다.

이 경우 부하 테스트 툴의 Controller는 한국 서울 사무소에 설치하고, 부하 생성기만 Amazon에 설치한후 한국 서울 사무소 직원을 통해서만 사용해야 한다.

 

간혹 (이럴리는 없어야 하겠지만) 부하 테스트 툴의 판매 회사 영업 사원이 이러한 사실을 제대로 통보하지 않아서, 툴을 잘 쓰다가 갑자기 영업 사원이 변경되거나, 부하 테스트 툴의 이전을 요청 하였을때, 갑자기 벤더로 부터, 추가 라이센스 구매 요청을 받을 수 있으니, 구매 전에 반드시 구매 조건에 사용 시나리오와  Controller 위치, 사용 주체 및 테스트 대상 시스테들에 대해서 명시적으로 기재 하고 구매 계약을 추진 하는 것이 좋다.

 

 

테스트 및 모니터링

부하 테스트 준비가 되었으면, 부하 테스트를 진행하고 진행중에 주요 성능 Factor에 대해서 지속적으로 모니터링 및 기록을 하여야 한다. 주로 모니터링해야하는 Factor들은 다음과 같다.



   애플리케이션 관점

가장 기본적으로 애플리케이션 즉 시스템의 성능을 측정 해야 한다. 주요 모니터링 Factor는 다음과 같다.

Response Time : Request 별 응답 시간

TPS (Throughput per second) : 초당 요청(Request) 처리량

Factor들이 궁극적으로 성능에 대한 최종 목표 값이 되기 때문에, 가장 중요한 성능 Factor가 되며, 부하 생성 도구를 통해서 손쉽게 측정할 수 있다.

   미들웨어 관점

미들웨어는 애플리케이션이 동작하기 위한 기본적인 솔루션이다.. Apache와 같은 웹서버나 Tomcat과 같은 Web Application 서버 , RabbitMQ와 같은 Message Queue, MySQL과 같은 데이타 베이스 등이 이에 해당한다.

각 성능 시나리오별로, 거쳐 가는 모든 미들웨어들을 모니터링해야 하는데, 이를 위해서는 각 솔루션에 대한 개별적인 깊은 이해가 필요하다.

웹서버의 경우 거의 성능 문제가 되는 부분은 없다. 성능 문제가 발생하는 부분은 대부분 Network outbound io (bandwidth)쪽이 되는 경우가 많다. 웹서버가 설치된 하드웨어의 network out bound bandwidth를 모니터링 하는 것이 유용하다.

대부분의 성능 문제는 실제 애플리케이션 로직이 수행되는 Tomcat과 같은 application server와 데이타 베이스단에서 많이 발생하는데, application server의 경우에는 Thread의 수와 Queue의 길이가 1차 모니터링 대상이 된다.

서버가 용량을 초과 하게 되면, Idle Thread수가 떨어지게 되고, Idle Thread 0이 되면 request message가 앞단의 queue에 저장되게 된다. 그래서 이 두 개를 모니터링 하면 시스템이 병목 상태인지 아닌지를 판단할 수 있다. 이 값들은 JMX (Java Management Extension) API를 이용하여 모니터링 하면 된다.

DB의 경우에는 slow query를 모니터링하면 특히 느리게 수행되는 쿼리들을 잡아서 튜닝할 수 있다. MySQL 5.6의 경우 slow queryhttp://dev.mysql.com/doc/refman/5.6/en/slow-query-log.html

를 사용하면 쉽게 잡아낼 수 있다.

Slow query를 찾았으면, EXPLAIN 명령어를 이용하여 query의 수행 내용을 분석한후 Index등의 튜닝을 수행할 수 있다.

http://dev.mysql.com/doc/refman/5.0/en/using-explain.html

   인프라 관점 : CPU, Memory, Network IO, Disk IO

다음으로 하드웨어 인프라에 대한 부분을 지속적으로 모니터링해줘야 하는데, 이는 하드웨어가 해당 성능을 내기 위해서 용량이 충분한지 그리고 하드웨어 구간에서 병목이 생기지는 않는지, 생긴다면 어느 구간에서 생기는지를 모니터링하여, 해당 병목 구간에 대한 문제 해결을 하기 위함이다.

인프라에 대한 모니터링은 Ganglia Cacti와 같은 전문화된 인프라 모니터링 도구를 사용하거나 top이나 glance, sar와 같은 기본적인 Unix/Linux 커맨드를 사용해서도 모니터링이 가능하다. (부하 테스트주에 top 등을 띄워놓고 모니터링을 하는 것이 좋다. Load Runner와 같은 상용 도구의 경우에는 부하 테스트 툴 자체에서 테스트 대상 시스템에 대한 하드웨어 사용률을 함께 모니터링할 수 있게 제공해준다.)

CPU : 일반적으로 CPU는 대부분 잘 모니터링 한다. 목표 성능을 달성할 시에는 보통 70~80% 정도의 CPU 를 사용하는 것이 좋고, 20~30%의 여유는 항상 가지고 가는 것이 좋다 이유는, 70~80% 정도의 CPU가 사용된 후에, 하드웨어를 물리적으로 늘리는 시간에 대한 여유 시간을 가지기 위함이다. 하드웨어는 특성상 주문을한다고 해도, 바로 그 시간에 증설을 할 수 있는 것이 아니고, CPU 100%가 되는 순간에는 이미 애플리케이션이 CPU 부족으로 제대로 작동을 하지 못하는 경우가 많기 때문에, 항상 여유를 남겨 놓고 성능 목표를 정의 하는 것이 좋다. 그래서 성능 목표를 잡을 때는 “CPU 70%, 500 TPS, 응답시간 1.5초 내외식으로 하드웨어에 대한 사용률을 포함하는 것을 권장한다.

Memory : 다음으로는 Memory 부분이다. Peak Time시에 Memory가 얼마나 사용되느냐가 중요한데, Java Application의 경우 특성상, 전체 JVM 프로세스가 사용할 메모리량을 미리 정해놓기 때문에, 부하 테스트 중에도 메모리 사용량 자체는 크게 변화하지 않는다. 다만 자주 놓치는 점이 swapping status 인데, Unix/Linux는 시스템의 특성상 물리 메모리 이상의 메모리를 제공하기 위해서 virtual memory 라는 개념을 사용하고 swapping space라는 디스크 공간에 자주 사용하지 않는 메모리의 내용을 dump해서 저장한 후 다시 사용할때 memory loading 하는 방식을 사용한다. 그런데 이 메모리의 내용을 디스크에 저장 및 로드 하는 과정 (swapping이라고 함)이 실제 disk io를 발생 시키기 때문에, 실제 메모리 access 성능이 매우 급격하게 떨어진다. 그래서 시스템에서 system에서 swapping이 발생하면 시스템의 성능이 장애 수준으로 매우 급격하게 떨어진다.

부하 테스트 중이나, 운영 중에 swapping이 발생하게 되면 전체 메모리 사용량을 줄이도록 튜닝을 하거나, 반대로 물리 메모리를 늘리는 증설 과정이 필요하다.

Disk IO : Disk IO는 파일 시스템에 파일을 저장하는 시나리오나, Log를 저장하는 모듈 그리고 데이타 베이스와 같이 뒷단에 파일 시스템을 필요로 하는 모듈에서 많이 발생을 한다. Ganglia와 같은 도구를 사용하면, IOPS (Input Out per Second - 초당 read/write등의 IO 발생 횟수)를 통해서 모니터링할 수 있고, 또는 iostat sar와 같은 명령어를 이용하면 iowait 를 통해서 디스크 IO pending이 발생할 경우 디스크 병목이 있는지 없는지를 확인할 수 있다.



Figure 1. iostat

또는 Process Disk IO iotop과 같은 툴을 사용하면 조금 더 상세한 정보를 얻을 수 있다.



Figure 2. iotop

[1]

Disk IO에 대한 Bottleneck은 여러가지 해결 방법이 있다. 먼저 하드웨어 인프라 ㅈ체에서 접근 하는 방식은, 디스크 자체를 SSD로 변경하거나, 버퍼가 크거나 RPM이 높은 디스크로 변경하는 방식, 인터페이스를 SATA에서 SAS SSD와 같은 높은 IO를 제공하는 디스크 인터페이스로 변경, Disk Controller iSCSI에서 FC/HBA와 같은 광케이블 기반의 고속 컨트롤러를 사용하는 방식 또는 RAID 구성을 Stripping 방식으로 변경해서 IO를 여러 디스크로 분산 시키는 방식 등이 있으며, 애플리케이션 차원에서는 데이타 베이스 앞에 memcache와 같은 캐슁을 사용하거나, 로깅의 경우에는 중간에 message queue를 써서 로그를 다른 서버에서 쓰도록 하여 IO를 분산하거나 또는 Back write와 같은 방식으로 로그 메세지가 발생할때 마다 disk writing 하는 것이 아니라 20 30개씩 한꺼번에 디스크로 flushing 하는 방식등을 이용할 수 있다.

또는 조금더 높은 아키텍쳐 레벨로는 디스크 IO가 많이 발생하는 로직의 경우 동기 처리에서 message queue를 사용하는 비동기 방식으로 시스템의 설계를 변경하는 방법을 고민할 수 있다. 예를 들어 사진을 올려서 변환하는 서비스의 경우 파일을 업로드 하는 시나리오와 변경하는 모듈을 물리적으로 분리하여, 파일 업로드가 끝나면, 사용자에게 동기 방식으로 바로 응답을 줘서 응답 시간을 빠르게 하고, 업로드된 파일은 뒷단에서 비동기 프로세스를 통해서 변환 과정을 다 끝낸 후에 사용자에게 변환이 끝나면 알려주는 방법을 사용할 수 있다.

Network IO: Network IO는 특히 고용량의 파일이나 이미지 전송에서 병목이 많이 발생하며, Reverse Proxy, NAT (Network address Translator), Router, Load Balancer 등에서 많이 발생한다. 여러가지 지점과 장비에 대해서 모니터링 해야 하기 때문에, 일반적인 unix/linux command 를 사용하는 방법보다는 Cacti Ganglia와 같은 RRD 툴이나 OpenNMS와 같은 NMS (Network Management System)을 사용하는게 좋다.

그래프를 보면서 추이를 지켜 보는 것이 중요한데, 부하를 넣으면 일정 수준이 되어도, 시스템들의 CPU나 메모리, Disk등의 기타 자원들은 넉넉한데, Network Input/Output이 일정 수준 이상으로 올라가지 않는 경우가 있다. 이 경우는 네트워크 구간의 병목일 가능성이 높다.

특히 소프트웨어 기반의 Load Balancer, 소프트웨어 기반의 NAT 장비에서 많이 발생하는데, 이미지와 같은 정적 컨텐츠는 가급적이면 CDN이나 분리된 Web Server를 이용해서 서비스 하도록 하는 것이 좋다. 클라우드의 경우에는 특히나 소프트웨어 기반의 NAT Load Balancer를 사용해서 문제가 되는 경우가 많은데, NAT의 경우에는 여러개의 NAT를 사용해서 로드를 분산하도록 하고, Load Balancer의 경우에도 충분히 큰 용량을 사용하거나 2개 이상의 Load Balancer를 배포한 후 DNS Round Robine등을 사용하는 방법을 고려 하는 것이 좋다.

개선 (Tuning)

병목을 찾았으면, 해당 병목 문제를 해결 및 반영해야 한다.

튜닝은 병목 구간이 발생하는 부분에 대한 전문적인 지식을 필요로 하지만, 기본적인 접근 방법은 거의 같다고 보면 된다.

   문제의 정의 : 성능 개선의 가장 기본은 문제 자체를 제대로 정의 하는 것이다. “그냥 느려요가 아니라, “성능 목표가 350TPS 1초내의 응답 시간인데, 현재 60 TPS 5초의 응답 시간에 WAS CPU 점유율이 100% 입니다.”와 같이 명확해야 하며, 문제점이 재현 가능해야 한다.

특히 재현 가능성은 매우 중요한 점인데, 테스트 환경이 잘못되었거나, 외부적 요인 예를 들어 부하 테스트 당시 네트워크 회선이 다른 테스트로 인하여 대역폭이 충분히 나오지 않았거나 했을 경우 결과가 그 때마다 다르게 나올 수 있다.

즉 문제 자체를 명확하게 정의할 필요가 있다.

   Break down : 다음으로는 문제가 발생하는 부분이 어떤 부분인지를 판단해야 한다. 시스템은 앞단의 로드밸런서나 미들웨어, 데이타 베이스와 같은 여러 구간에서 발생을 한다. 그렇기 때문에, 성능 저하의 원인이 정확하게 어느 부분인지를 인지하려면, 먼저 성능 시나리오가 어떤 어떤 컴포넌트를 거치는지를 명확하게 할 필요가 있다. 이 과정을 break down이라고 한다. 이 과정을 통해서 전체 성능 구간중, 어느 구간이 문제를 발생 하는지를 정의한다.

   Isolate : 다음으로는 다른 요인들을 막기 위해서, 문제가 되는 구간을 다른 요인으로 부터 분리 (고립) 시킨다. 물론 완벽한 분리는 어렵다. 애플리케이션이 동작하기 위해서는 데이타 베이스가 필수적으로 필요하다. 이 경우에는 데이타 베이스를 분리할 수 는 없다. 그러나 예를 들어 시나리오 자체가 로그인 시나리오이고 Single Sign On을 통해서 로그인 하는 시나리오라서 SSO 시스템과 연동이 되어 있다면, SSO 연동을 빼고 다른 mock up을 넣어서 SSO와의 연결성을 끊고 테스트를 하는 것이 좋다.

이렇게 문제에 대한 다른 요인과의 연관성을 최대한 제거 하는 작업이 isolation이다.

   Narrow down : 문제를 isolation을 시켰으면, 근본적인 문제를 찾기 위해서 문제의 원인을 파 내려간다. Profiling을 하거나, 코드에 디버그 정보를 걸어서 문제의 원인을 분석하는 과정을 narrow down이라고 한다. 특히나 이 narrow down 과정은 분석을 위한 여러가지 기법이나 도구들을 사용해야 하고, 현상에 대한 이해를 하기 위해서는 해당 솔루션이나 기술 분야에 대한 전문성은 필수적으로 필요하다.

   Bottleneck 발견 : Narrow down을 해서 문제의 원인을 계속 파해쳐 나가면 병목의 원인이 되는 근본적인 문제가 판별이 된다.

   해결 : 일단 병목의 원인을 찾으면 해결을 해야 하는데, 찾았다고 모두 해결이 되는건 아니다. 데이타 베이스 index를 걸지 않아서 index를 걸어주면 되는 간단한 문제도 있을 수 있지만, 근본적인 솔루션 특성이나 설계상의 오류로 인해서 문제가 발생하는 경우도 있다. 하드웨어를 늘려서 해결하는 방법도 있지만, 비지니스 시나리오 자체를 바꾸거나 UX 관점에서 해결 하는 방법도 고려할 수 있다. 예를 들어 로그인 화면이 넘어가는데 시간이 많이 걸린다고 했을때, 이 문제가 근본적으로 솔루션의 특성이라면 애플리케이션이나 솔루션 수정으로는 해결이 불가능하다. 이런 경우에는 모래 시계 아이콘이나 progress bar등을 넣어서 UX 관점에서 사용자로 하여금 체감되는 응답 시간에 대해서 느리지 않고 몬가 진행이 되고 있다고 보여주는 형태로 접근을 해서 문제를 해결할 수 도 있다.

간단한 예를 하나 들어보자. Drupal 이라는 웹 CMS 기반의 웹사이트가 있다고 하자. 성능 테스트를 수행하였는데, CPU 점유율이 지나치게 높게 나오고 응답 시간이 느리게 나왔다. 이것이 문제의 정의이다.

성능의 문제점을 찾아내기 위해서, 성능 테스트 시나리오를 검토하였다 성능 테스트 시나리오는 1) 로그인 페이지 로딩, 2) id,password post로 전송 3) 초기 화면으로 redirect 4) 로그 아웃 4가지 과정을 거치고 있었다. 1,2,3,4 과정의 응답시간을 각각 체크해서 보니, 2) 과정에서 성능의 대부분을 차지 하고 있음을 찾아 내었다. 전체적으로 성능이 안나오는 것을 인지한 후, 문제를 여러 구간으로 나누어서 접근 하는 것이 Break down이다.

2) 과정을 분석하기 위해서 성능 테스트를 다시 진행한다. 다른 시나리오가 영향을 주는 것을 방지하기 위해서, 1,3,4 시나리오를 제외 하고, 2 시나리오만 가지고 성능 테스트를 진행한다. 이렇게 문제점을 다른 변수로 부터 분리하여 고립 시키는 것을 isolation이라고 한다.

다음으로 Xhprof 라는 프로파일링 툴을 사용하여 로직중 어느 부분이 가장 성능 문제가 발생하는 지를 profiling 하였다. 대 부분의 성능 저하가 SQL 문장 수행에서 발생함을 찾아내었다. 이렇게 하나의 포인트를 깊게 들어 가면서 범위를 좁혀가는 것을 narrow down이라고 한다.

SQL 수행이 문제가 있음을 정의하고(문제의 정의), 어떤 SQL 문장이 수행되는지(Break down) 각각을 정의한후, 가장 수행 시간이 긴 SQL 문장을 찾아서 원인을 분석하였더니(narrow down) index 가 걸려 있지 않음을 찾아내었다.

해당 테이블에 index를 적용하고, 성능 테스트를 다시 수행하여 성능 목표치를 달성하였음을 해결하였다.

가상의 시나리오지만 성능 튜닝의 접근 방법은 대부분 유사 하다. 관건은 문제를 어떻게 잘 정의하고, 문제가 어떤 요소로 구성이 되어 있으며 각각이 어떤 구조로 동작을 하고 있는지 잘 파고 들어갈 수 있는 문제에 대한 접근 능력과, 점점 솔루션의 아랫부분(low level)로 들어갈 수 있는 전문성이 필요하다.

반복

튜닝이 끝났으면 다시 테스트 및 모니터링항목으로 돌아가서 성능 목표에 도달할때까지 위의 작업을 계속해서 반복해서 수행한다.

Performance Engineering을 위해 필요한 것들

그러면 성능 엔지니어링을 하기 위해서 필요한 것들은 무엇이 있을까? 먼저 도구 적인 측면부터 살펴보자.

   부하 테스트기 : 가장 기초적으로 필요한 것은 부하 발생 도구 이다. HP Load Runner와 같은 상용 도구에서 부터, nGrinder와 같은 오픈 소스 기반의 대규모 부하 발생 도구를 사용할 수 도 있고, SOAP UI같은 micro benchmark 테스트 툴을 이용해서 소규모 (50 사용자 정도)를 발생 시키거나 필요에 따라서는 간단하게 Python등의 스크립트 언어로 부하를 발생시킬 수 도 있다.

   모니터링 도구 : 다음으로는 모니터링 도구이다. 어느 구간이 문제가 있는지 현상이 어떤지를 파악하려면 여러 형태의 모니터링 도구들이 필요하다.

   프로파일링 도구 : 그리고, 문제되는 부분을 발견했을때, 그 문제에 대한 근본적인 원인을 찾기 위해서 프로파일링을 할 수 있는 도구들이 필요하다.

우리가 일반적으로 이야기 하는 프로파일링 도구들은 IDE와 같은 개발툴에서 debug 용도로 사용은 가능하지만, 대부분 대규모 부하 환경에서는 사용이 불가능한 경우가 많다.그래서 그런 경우에는 해당 시스템의 상태에 대한 스냅샷을 추출 할 수 있는 dump 도구들을 많이 사용하는데, unix process의 경우에는 ptrace를 통해서 system call을 모니터링 하거나, pmap을 이용하여 메모리 snapshot등을 추출할 수 도 있고, 자바의 경우에는 thread dump를 추출해서 병목 당시 애플리케이션이 무슨 동작을 하고 있었는지를 찾아낼 수 있다.

다음이 이 글에서 정말 언급하고 싶은 내용인데, 앞에서 도구를 언급했다면 다음은 엔지니어로써의 역량이나 지식적인 부분이다.

   역량 : 당연한 것이겠지만, 기술적인 역량은 필수적이다. netstat를 통해서 TCP 소켓이 FIN_WAIT가 발생하였는데, FIN_WAIT가 의미하는 것이 무엇인지 모르면 아무리 모니터링을 잘해도 소용이 없다. 기본적인 엔지니어로써의 컴퓨터와 프로그래밍, OS등에 대한 넓은 이해는 필수적이다.

   하드웨어 인프라, 미들웨어 , 애플리케이션에 대한 지식 : 다음은 사용하는 특정 솔루션에 대한 전문적인 지식이다. 톰캣의 내부 구조가 어떻게 되어 있으며, JVM의 동작원리가 어떻게 되는지와 같은 특정 지식인데, 사실 이러한 지식은 오랜 경험이나 습득할 시간이 없으면 가지기가 어렵다. 이런 경우는 해당 솔루션 제품 엔지니어를 통해서 지원을 받는 방법도 고려해볼만 하다.

   그리고 경험 : 성능 엔지니어링에 대한 경험인데, 대략 시스템의 상태마 봐도 어느 부분이 의심이 되는지 경험이 많은 엔지니어는 쉽게 접근을 한다. 성능 문제는 넓어보이기는 하지만, 결국 발생되는 패턴이 거의 일정하다. 그리고 특정 솔루션에 대한 지식이 없다하더라도, 문제에 대한 접근 하는 방법이나 모니터링 방법, 툴등은 사용법이 다르다 하더라도 그 의미하는 방법은 거의 비슷하기 때문에, 다른 기술로 구현되어 있는 시스템이라고 하더라도, 경험이 있는 엔지니어는 문제를 접근해서 풀어나가는 방식이 매우 익숙하다.

   마지막으로 인내심 : 그리고 마지막으로 강조하고 싶은 점이 인내심인데, 사실 성능 엔지니어링은 상당히 지루한 작업이다. 반복적인 테스트와 모니터링 및 분석을 거쳐야 하고, 해당 솔루션에 대한 전문적인 지식이 없을 경우에는 보통 제품 문제라고 치부하고 하드웨어 업그레이드로 가는 경우가 많은데, 어짜피 솔루션이라고 해도 소스코드로 만들어진 프로그램이다. 디컴파일을 하건, 덤프를 추출하건, 꾸준히 보고, 오픈 소스의 경우 소스코드를 참고해서 로직을 따라가다 보변, 풀어낼 수 있는 문제가 대부분이다. 결국은 시간과 인내심의 싸움인데, 꾸준하게 인내심을 가지고 문제를 접근하고 풀어나가는 것을 반복하면 문제는 풀린다.


원본 : http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html


아마존 S3를 이용하는 시스템에 대한 성능 테스트를 할때, 성능이 Leanear 하게 증가하지 않는데, 그 원인을 보면 다음과 같은 원리가 작용한다.


원인 분석

S3는 내부적으로 여러개의 파일을 저정하기 위해서 물리적으로 파일을 여러개의 디스크에 분할 저장하는데, 이 분할 하는 로직을 파일명을 가지고 해쉬를 사용한다. 그래서 파일명이 유사하게 되면, 같은 파티션(디스크)에 파일이 써지기 때문에, 하나의 파티션에 많은 물리적인 IO를 유발하고 결과적으로 성능이 떨어지게 되는 것이다.


원리

S3는 파일명을 가지고 hashing을 하여 파일을 분산 저장한다고 했다. 더 정확하게 이야기 하면 파일명의 앞부분인 prefix를 가지고 분산 키로 사용한다.

즉 예를 들어 파일명이

server.2012-12-31

server.2012-12-30

server.2012-12-29

server.2012-12-28

과 같이 앞의 prefix가 같다면, 파일은 같은 파티션에 저장될 가능성이 많다.

그래서 앞의 file prefix를 다양한 이름으로 바꿔 주는 것이 좋다.

예를 들어 일정 디렉토리 (디렉토리명으로도 파티셔닝이 된다.)로 다음과 같이 구분한다

a/server.2012-12-31

b/server.2012-12-30

c/server.2012-12-29

d/server.2012-12-28

위와 같은 구조를 취하면, 최소 4개 파티션에 분할 저장된다.
또는 위의 파일명의 경우 맨 마지막이 날짜로 rotation되는 형태이기 때문에, 다음과 같은 파일명으로 저장해도 파티셔닝 효과를 볼 수 있다.
13-21-2102.server
03-21-2102.server
92-21-2102.server
:
S3에서 내부적으로 어떤 원리로 partitioning을 하는지는 정확하게 나와 있지 않다. 단지 prefix를 이용한다고만 나와 있는데, 최소한 파일명(또는 디렉토리명)을 다른 문자로 시작하게 하면, 골고루 파티션에 분산하여 저장할 수 있다고 가이드 하고 있다.

최소한 50 TPS 이상의 S3 IO를 요구할 경우에는 파티션을 권장하고 있다.
이 키 기반의 파티셔닝은 단지 S3 뿐만 아니라, NoSQL이나 HDFS와 같은 분산 파일 시스템에도 동일한 원리로 적용되기 때문에 반드시 참고하기 바란다.


NoSQL 하드웨어 구성에 있어서, DISK IO에 대한 메모.
RAID 구성은 5가 정답
NoSQL의 N-Value를 통한 장애 대처 능력은 노드간 장애를 대처하기 위함이지, 노드의 디스크 장애 극복은 불가능함.
아주 큰 클러스터가 아니면 RAID 5가 정답, 아니면 스트라이핑 기반의 RAID 0가 정답(대규모 클러스터의 경우, 단 이 경우, 디스크 장애는 해당 노드의 장애를 의미함, 검출도 어려울듯...)

IO Scheduler가 성능 튜닝 포인트라고는 하는데...
오늘 구글링에서 본 자료로는 Scheduler 바꾼다고 IO 자체 성능이 큰 차이가 없는 듯.. 이건 한번 테스트 해봐야 할듯.

결국은 네트워크 분리,캐쉬 튜닝을 어떻게 하느냐가 가능 큰 팩터가 될듯.

DB VM에 올릴 때 첫번째로 고려할 사항은 수직적 확장성이다. 수평적인 확장성은 DBMS 자체가 제공하는 클러스터 기능을 이용해야 한다. (MS SQL의 경우 수평 확장 불가, ORACLE의 경우 RAC를 이용하여 수평확장 가능). 만약에 DBMS 자체 클러스터링에 대한 확장이 불가능하다면 애플리케이션 단에서 Database Sharding등을 이용하여 확장을 하는 안을 고려할 수 있다.

수직적 확장의 경우 현재까지 Hyper-V가 최대 CPU 4 코어까지만 지원하기 때문에, 더 이상의 용량이 필요한 경우 분리된 Physical Machine을 사용하는 방법을 사용해야 한다.

 

DBMS VM에 올릴 경우 가상화에 대한 Cost로 인하여 성능이 떨어지는데, 그 중에서 성능에 가장 큰 영향을 미치는 것이 Disk에 대한 부분이다. DB VM에 배포할 때 Disk에 대해서 아래와 같이 3가지 옵션을 선택할 수 있다.

       Dynamic Size VHD : 가상 디스크의 사이즈를 동적으로 지정하여 Runtime에서 변경되도록 하는 옵션

       Fixed Size VHD : 가상 디스크의 사이즈를 정해놓고, 공유하는 방안

       Pass-through Disk : 물리적인 디스크를 직접 VM에 마운트 하는 방안

 

먼저 Fixed Size VHD Pass-through Disk (이하 PTD)의 성능 차이를 보면

 

Random IO의 경우 Read/Write 모두 큰 차이는 없고 Sequential Write 부분에서 Fixed Size Disk 가 성능이 떨어지는 것을 볼 수 있다.

일반적인 OLTP성의 트렌젝션 처리 성능을 비교해보면


 1.       Baseline: a native Windows Server 2008 environment with Hyper-V role disabled. The virtual network switch is not turned off.

2.       Root partition: a root partition in Windows Server 2008 with Hyper-V enabled.

3.       VM_PT: a guest virtual machine configured with pass-through disks, four logical processors, and 14 GB RAM.

4.       VM_VHD: guest virtual machine configured with fixed-VHD disks, four logical processors, and 14 GB RAM.

5.       Overhead is calculated by comparing with Baseline ((Baseline Batches/CPU – VM Batches/CPU)/ Baseline Batches/CPU)

위의 테스트 결과와 같이 전혀 가상화를 하지 않은 상태 (Baseline) 대비 PTD를 사용했을 때와 Fixed Size VHD의 성능을 비교하면 10~20% 정도의 차이가 나는 것을 볼 수 있고, Fixed Size VHD PTD사이의 차이는 소량의 트렌젝션에서는 PHD가 약간 우세를 나타내며, 대량의 트렌젝션에서는 큰 차이가 없는 것으로 나타난다.


다음 자료는 하나의 MS SQL 인스턴스가 독립된 PTD를 사용하고, 다른 하나는 Fixed Size VHD를 사용하는데, 해당 디스크 볼륨이 다른 VM과 공유되는 상황에 대한 비교이다.

위의 표에서와 같이 Dramatic한 성능 차이는 나지 않는다.

 

결론적으로 PTD Fixed Size VHD 사이의 성능 차이는 미미하기 때문에 성능 최적화 측면에서는 PTD를 공간 활용면에서는 Fixed Size VHD를 사용한다.

 가상화에 올린 DB Physical 서버에 직접 올린 DBMS강의 성능 차이는 약 10~20% (가상화로 인한 오버헤드)정도로 판단하고 디자인에 참고해야 하며, 가상화에 올릴 시에는 최대 4개의 코어 까지만 지원하기 때문에 4 코어 이상의 성능이 필요한 경우 가상화 환경이 아닌 분리된 DBMS 하드웨어를 사용해야 한다.

(분석 리포트 출처: http://www.microsoft.com/hosting/dynamicdatacenter/Resources.html#SQLServer_)


XML 변환 성능

프로그래밍/XML 관련 | 2009.04.17 19:41 | Posted by 조대협
SOA 프로젝트를 진행하면서 가장 골치거리 중의 하나가 XML 변환에 소요되는 CPU와 응답시간이다.
통상 SOA나 요즘의 많은 Remote call들이 XML을 기반으로 하다보니, 특히나 XML 메세지 변환에 대한 요건이 많다.

자료들을 찾아보니 몇가지 흥미로운 자료들이 있는데,
XSLT가 전체적으로 변환에는 가장 많이 사용되는 듯 (OSB의 경우 XQuery가 편해서 XQuery를 많이 사용하긴 하지만.)한데 그중 흥미로운것인 XSLT를 compile time에 translet이라는 것으로 변환해서 사용할 수 있는 프레임웍

그리고 재미있는 것중의 하나가 Intel에서 만든 XML 변환 가속기인데, Native 코드로 이부분을 구현하여 Intel CPU에서 최적화된 성능을 낼 수 있게 해준다.
 사실 성능이 얼마나 늘어날지는 미지수지만 http://cache-www.intel.com/cd/00/00/34/42/344227_344227.pdf
그래도 Itaniuem 기반의 OS에서만이라도 사용할 수 있다면 꽤나 아키텍쳐 설계에서 유연성을 얻을 수 있지 않을까?
www.intel.com/software/XML

'프로그래밍 > XML 관련' 카테고리의 다른 글

XML 변환 성능  (0) 2009.04.17
Soap Handler  (0) 2009.04.17
WebLogic Workshop을 이용한 웹서비스 프로그래밍  (0) 2009.04.17
XMLBean  (3) 2008.12.22
JAX-WS를 이용한 쉬운 웹서비스 개발 방법  (0) 2008.12.12
XML에서 Namespace 제거하는 XSLT  (0) 2008.12.10

Java File Writing 성능 비교

성능과 튜닝/자바 성능팁 | 2009.03.31 17:39 | Posted by 조대협
JAPM을 업그레이드 할까 싶어서 Log Writing 부분을 개선하고자 해서
File Writing을 어떻게 하는 것이 제일 빠를까 테스트를 해봤다.
크게 아래 케이스인데.

1. FileWriter fw = new FileWriter(LOG_HOME+"writer.log");
2. BufferedWriter bw = new BufferedWriter(new FileWriter(LOG_HOME+"writer.log"));
3. FileOutputStream fos = new FileOutputStream(LOG_HOME+"outputstream.log");
4. BufferedOutputStream fos =  new BufferedOutputStream(new FileOutputStream(LOG_HOME+"bufferedoutputstream.log"));
5. FileChannel fc =(new FileOutputStream(new File(LOG_HOME+"filechannel.log"))).getChannel(); + Byte Buffer 매번 생성
6. FileChannel fc =(new FileOutputStream(new File(LOG_HOME+"filechannel.log"))).getChannel(); + ByteBuffer 재사용

테스트의 정확성을 위해서 측정중에 GC가 발생하지 않도록 NewSize와 HeapSize를 크게 해놓고 테스트를 하였다. Vm 옵션은 -XX:NewSize=480m -ms768m -mx768m -verbosegc 이다.
환경 : Windows XP, Sun JVM 1.5, Centrio VPro Dual core, IBM Thinkpad X61s

결과는 다음과 같다.
   1K  2K  5K  10K  50K  
 FileWriter  31  32  94 203  1281  
 FileWriter + BufferedWriter  15  31  94  188  1000  
 FileOutputStream  32 47  109  188  1063  
 FileOutputStream + BufferedOutputStream  31  47  109  203  1578  
FileChannel  47  63  109  219  2906  
FileChannel + Byte Buffer 재사용 31 47 188 250 2766

(해당 레코드를 1000번씩 write)

예상하기로는 NIO의 FileChannel이 가장 빠를것이라 생각했는데, 의외로 FileWrite와 FileOutputStream의 성능이 높게 나왔다. NIO의 경우 JVM 벤더에 종속성이 있겠지만 이런 결과가 나오는것은 약간 의외였다.
 오히려 프로그래밍 기법을 내서 FileChannel을 사용할 경우 최대 3배까지 성능이 나쁜 경우가 올 수 있으니. 이런건 차라리 모르는게 나을 수 도 있겠다~~ 싶다.. ^^

BufferedWriter등의 경우 GC를 유발하는 문제가 있을 수 있기 때문에 또 다른 성능 저하 요인이 될 수 는 있겠지만, 현재까지 테스트 결과로는 Windows Platform에서는 FileWriter + BufferedWriter의 경우가 성능이 제일 좋은것 같다.
아래는 테스트에 사용한 소스 코드
==
package bcho.filewriter.test;

import java.io.BufferedOutputStream;
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileOutputStream;
import java.io.FileWriter;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

import junit.framework.TestCase;

public class FileWriterTest extends TestCase {
final static int loop = 1000;
final static String LOG_HOME="c:/temp/";
static String LOG_STRING="";
static {
}
public void testSuite() throws Exception{
int stringSize[]={100,200,500,1000,5000};
for(int i=0;i<stringSize.length;i++){
LOG_STRING="";
for(int j=0;j<stringSize[i];j++) LOG_STRING+="1234567890";
log(stringSize[i]+"0 bytes");
testFileWriter();
System.gc();
testBufferedWriter();
System.gc();
testFileOutputStream();
System.gc();
testFileBufferedOutputStream();
System.gc();
testFileChannel();
System.gc();
testFileChannelOneBuffer();
System.gc();
}
}
public  static void log(String str){
System.out.println(str);
}
// java.io.FileWriter
private void testFileWriter() throws Exception {
FileWriter fw = new FileWriter(LOG_HOME+"writer.log");
long st = Timer.getCurrentTime();
for(int i =0;i<loop;i++){
fw.write(LOG_STRING);
}
log("FileWriter :"+Timer.getElapsedTime(st) +"ms");
fw.close();
}
// java.io.BufferedWriter
private void testBufferedWriter() throws Exception {
BufferedWriter bw = new BufferedWriter(new FileWriter(LOG_HOME+"writer.log"));
long st = Timer.getCurrentTime();
for(int i =0;i<loop;i++){
bw.write(LOG_STRING);
}
log("BufferedWriter :"+Timer.getElapsedTime(st) +"ms");
bw.close();
}
// java.io.FileOutputStream
private void testFileOutputStream() throws Exception{
FileOutputStream fos = new FileOutputStream(LOG_HOME+"outputstream.log");
long st = Timer.getCurrentTime();
for(int i=0;i<loop;i++){
byte[] buf = LOG_STRING.getBytes();
fos.write(buf);
}
log("FileOutputStream :"+Timer.getElapsedTime(st) +"ms");
fos.close();
}
// java.io.FileOutputStream
// + java.io.BufferedOutputStream
private void testFileBufferedOutputStream() throws Exception{
BufferedOutputStream fos = 
new BufferedOutputStream(
new FileOutputStream(LOG_HOME+"bufferedoutputstream.log"));
long st = Timer.getCurrentTime();
for(int i=0;i<loop;i++){
byte[] buf = LOG_STRING.getBytes();
fos.write(buf);
}
log("FileBufferedOutputStream :"+Timer.getElapsedTime(st) +"ms");
fos.close();
}
private void testFileChannel() throws Exception {
FileChannel fc =(new FileOutputStream(new File(LOG_HOME+"filechannel.log"))).getChannel();
long st = Timer.getCurrentTime();
for(int i=0;i<loop;i++){
byte[] buf = LOG_STRING.getBytes();
ByteBuffer bytebuffer = ByteBuffer.allocate(buf.length);
bytebuffer.put(buf);
bytebuffer.flip();
fc.write(bytebuffer);
}
log("FileChannel  :"+Timer.getElapsedTime(st) +"ms");
fc.close();
}
private void testFileChannelOneBuffer() throws Exception {
FileChannel fc =(new FileOutputStream(new File(LOG_HOME+"filechannelonebuf.log"))).getChannel();
int BUF_SIZE=1000;
long st = Timer.getCurrentTime();
ByteBuffer bytebuffer = ByteBuffer.allocate(BUF_SIZE);
for(int i=0;i<loop;i++){
byte[] buf = LOG_STRING.getBytes();
int offset=0;
int length= buf.length;
while(offset < length){
int chunkSize = BUF_SIZE > length-offset ? length-offset-1 : BUF_SIZE;
bytebuffer.put(buf, offset, chunkSize);
bytebuffer.flip();
offset+=BUF_SIZE;
fc.write(bytebuffer);
bytebuffer.clear();

}
}
log("FileChannel with reusing buffer:"+Timer.getElapsedTime(st) +"ms");
fc.close();
}


}


'성능과 튜닝 > 자바 성능팁' 카테고리의 다른 글

Java File Writing 성능 비교  (8) 2009.03.31
이번에는 앞에서 설명한 Aspect J와 JMX를 이용하여 초간단 APM을 만들었습니다.
JAPM (Java Application Performance Monitor)
상용 APM 툴 설치하기 어렵거나, 간단하게 Tracing하고 싶을때 사용하시면 됩니다.
소스코드와 설치 메뉴얼등을 첨부합니다.

JMX를 이용하여 Thread 별 CPU 시간을 측정하는 방법

==
 ThreadMXBean mbThread = (ThreadMXBean) ManagementFactory.getThreadMXBean();
 
 long[] ids = mbThread.getAllThreadIds();
 for (long id: ids)
 {
  System.out.println(mbThread.getThreadInfo(id).getThreadName());
  System.out.println(" CPU Time(" + id+ ")" + mbThread.getThreadCpuTime(id));
  System.out.println(" User Time(" + id+ ")" + mbThread.getThreadCpuTime(id));
 }

==
AOP에서 before에서 자기 Thread의 CPU 시간을 저장한후 after에서 다시 측정하여 결과를 빼면 해당 메서드의 CPU  사용 시간을 측정할 수 있다.

참고 : 단위는 nano second ( /1000,000 = milisecond)

이형봉과장 아저씨 아이디어인데.
메가사이즈급 포탈을 하더니 경험이 많이 늘어나신것 같다.

포탈에서 성능상 가장 문제가 되는 부분은, 로그인 과정에서 개인화시에 컨트롤 트리 빌딩하는 과정이 많은 시간을 잡아먹게 된다. 이부분이 주요 성능 FACTOR가 되는데.

결과적으로 컨트롤 트리에 바인딩되는 컨트롤의 수를 줄이는것이 가장 키 포인트다.
다른 방법으로 접근은 컨트롤 트리란 데스크탑 단위로 렌더링이 되기 때문에, 업무 별로 데스크탑을 나누는 것이다.
여기까지는 다 아는 사실이고

업무에서 개인화를 하는 사람이 있고 하지 않는 사람이 있다.
로그인했을때 무조건 개인화 페이지를 보여주는것이 아니라, 개인화 페이지를 따로 만들어서 개인화 탭을 눌렀을때만 개인화 페이지를 보여주는 방법이다. 개인화 페이지의 구조를 조정함으로써 개인별 컨트롤 트리의 사이즈를 조정할 수 있고, 또 개인화 페이지에 대한 요청이 있을때만 컨트롤 트리를 만드니 얼마나 좋은가?

데스크탑을 만들때, ROOT 데스크탑을 전체의 틀로 만들고
안에 공용 데스크탑 (개인화를 하지 않는)과 개인화를 하는 데스크탑을 따로 만들면된다.
포탈 구조 잡을때 매우 유용하게 사용할 수 있을것 같네.

봉과장님 감사
      

Bytecode instrument with Weblogic

분류없음 | 2007.08.08 16:42 | Posted by 조대협
http://besee.sourceforge.net/extension/weblogic.html

디버깅할때 매우 유용하겠다.
TAG APM, 성능