자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기 정리 13 ~ 23

IT_Programming/Java

자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기 정리 13 ~ 23

JJun ™ 2009. 10. 10. 12:38

-----------------------------------------------------------------------------------------------

13. DB를 사용하면서 발생할 수 있는 문제점

애플리케이션의 응답속도를 지연시키는 대부분의 요인은 DB쿼리 수행 시간과 결과를 처리하는 시간이다.

DB connection을 할 경우에는 반드시 공통 유틸을 사용할 것.
각 모듈 별 DataSource를 사용하여 리소스가 부족한 현상이 발생하지 않도록 할것.
반드시 connection, statement 관련 객체, ResultSet을 close 할 것.
페이지 처리를 하기 위하여 ResultSet 객체.last() 메소드를 사용하지 말것.

try
    {
        Class.forName( "orcla.jdbc.driver.OracleDriver");
        Connection con = DriverManager.getConnction( "jdbc:oracle:thin:@ServerIP:1521:SID","ID","PassWord");
        PreparedStatement ps = con.prepareStatement( "SELECT ... where id=?");
        ps.setString( 1, id);
        ResultSet rs = ps.executeQuery();
        // 중간 데이터 처리 부분 생략
    }
    catch( ClassNotFoundException e)
    {
        System.out.println( "드라이버 Load Fail");
        throw e;
    }
    catch ( SQLException e)
    {
        System.out.println( "Connction fail");
        throw e;
    }
    finally
    {
        rs.close();
        ps.close();
        con.close();
    }

위의 예제에서 수행 순서는

드라이버 로드 한다.
DB 서버의 IP와 ID,PW등의 DriverManager 클래스의 getConnection 메소드를 사용하여 Connection 객체로 만든다.
Connection 으로 부터 PreparedStatement 객체를 받는다.
executeQuery 를 수행하여 그 결과로 ResultSet 객체를 받아서 데이터를 처리한다.
모든 데이터를 처리한 이후에는 finally 구문을 사용하여 ResultSet, Prepared, Statement, Connection 객체들을 닫는다. 물론 각 객체를 close할 때 예외가 발생할 수 있으므로, 해당 메소드에서는 예외를 던지도록 처리해 놓아야 한다.

Connection 객체를 생성하는 부분에서 부분에서 발생하는 대기 시간을 줄이고,

네트워크의 부담을 줄이기 위해서 사용하는 것이 DB Connection pool이다.

[ JDBC를 사용하면서 유의할 만한 몇가지 팁 ]

- setAutoCommit() 메서드는 필요할 때만 사용하자.

: setAutoCommit() 메서드는 자동 커밋 여부를 지정하는 역할

- 배치성 작업은 executeBatch() 메서드를 사용하자.

: 배치성 작업을 할 때에는 Statement인터페이스에 정의되어 있는 addBatch() 메서드를 사용하여 쿼리를

지정하고, executeBatch() 메서드를 사용하여 쿼리를 수행하자. 여러 개의 쿼리를 한번에 수행할 수 있기

때문에 JDBC 호출 횟수가 감소되어 성능이 좋아진다.

- setFetchSize() 메서드를 사용하여 데이터를 더 빠르게 가져오자.

: 한번에 가져오는 열의 개수는 JDBC의 종류에 따라서 다를 것이다. 하지만 가져오는 데이터의 수가

정해져 있을 경우에는 Statement와 ResultSet 인터페이스에 있는 setFetchSize() 메서드를 사용하여

원하는 개수를 정의하자. 하지만 너무 많은 건수를 지정하면 서버에 많은 부하가 올 수 있으니

적절하게 사용해야 한다.

- 한 거만 필요할 때에는 한 거만 가져오자 .

-----------------------------------------------------------------------------------------------

14. XML도 잘 쓰자

XML(eXtensible Markup Language)의 약자 이다.

XML의 큰 장점은 누구나 데이터의 구조를 정의하고 그 정의된 구조를 공유함으로써

일관된 데이터 전송 및 처리를 할 수 있다는 점이다. 이러한 특성 때문에 파싱해야한다.

약어	의미	패키지
JAXP	Java API for XML Processing	javax.xml.parsers
SAX	Simple API for XML	org.xml.sax
DOM	Document Object Model	org.w3c.dom
XSLT	Xml Stylesheet Language for Transformations	javax.xml.transform

SAX는 순차적 방식으로 XML을 처리한다.

DOM은 모든 XML을 읽어서 트리로 만든 후 XML을 처리하는 방식이다.

다시말하면 SAX는 각각 XML의 노드를 읽는 대로 처리하기 때문에 메모리에 부담이 DOM에 비해서

많지 않다. 하지만 DOM은 모든 XML을 메모리에 올려서 작업하기 때문에 메모리에 부담이 가게 된다.

그림과 같이 SAX는 Content, error,dtd,entity들이 순차적으로 이벤트를 처리하므로

이미 읽은 데이터의 구조를 수정하거나 삭제가 어렵다.

DOM은 모든 XML의 내용을 읽은 이후에 처리한다.

읽은 XML을 통하여 노드를 추가,수정,삭제하기 쉬운 구조이다.

XML 파서 중 서버단은 SAX, DOM이 가장 적합하다.

SAX,DOM의 자세한 정보는http://www.isr.umd.edu/~austin/ence489c.d/xml.html를 참조 바랍니다.

SAX

DOM

응답속도

1,929ms

6,468ms

메모리

56MB

292MB

: 많은 부분에서 XML을 적용하나, 빈번하게 XML을 로드하는 것은 장애의 원인이 될 수 있으므로

주기적으로 XML을 로드 하되 빈도 수를 줄이는 것을 권장함

-----------------------------------------------------------------------------------------------

15. GC가 어떻게 수행되고 있는지 보고 싶다.

jvmstat는 SUN에서 제공하는 GC 모니터링 툴이다.

단점은 NT서버와 솔라리스서버에서만 사용이 가능하다

툴이름	설명
jps	JVM프로세스의 목록을 보여주는 툴. 대상 시스템에서 수행중인 핫스팟 JVM들의 목록을 나타낸다.
jstat	JVM 통계 수치를 모니터링하는 툴이다. 수행 중인 핫스팟 JVM에 연결하고, 옵션에 따른 정보를 모아 로그를 남긴다.
jstatd	JVM의 jstat 데몬으로 RMI서버를 기동한다. 원격으로 JVM을 모니터링 하기 위해서 사용된다.
visualgc	비쥬얼 가비지 콜렉션 모니터링 툴이다. GC와 컴파일러, 클래스 로더를 그래프로 보여준다. 로컬이나 원격 JVM을 모니터링 할 수 있다.

* visualgc는 JDK에 기본으로 포함되어 있는 툴이 아니다. Sun에서 jvmstat로 검색하여 설치해야함.

jps는 해당 머신에서 운영 중인 JVM의 목록을 보여준다.

jps [-q] [-mlvV] [-Jopion] [<hostid>]

-q : 클래스나 jar 파일명, 인수등을 생략하고 내용을 나타낸다.
-m : main 메소드에 지정한 인수를 나타낸다.
-l : 애플리케이션의 main 클래스나 애플리케이션 JAR파일의 전체 경로 이름을 나타낸다.
-v : JVM에 전달된 자바 옵션 목록을 나타낸다.
-V : JVM의 플래그 파일을 통해 전달된 인수를 나타낸다.
-Joption : 자바 옵션을 이 옵션 뒤에 지정할 수 있다.

jstat는 GC가 수행되는 정보를 확인하기 위한 명령어

jstat -<option> [-t] [-h<lines>] [vmid] [<interval>] [<count>]

-t : 수행 시간을 표시한다.
-h:lines : 각 열의 섦ㅇ을 지정된 라인 주기로 표시한다.
interval : 로그를 남기는 시간의 차이(밀리초)를 의미한다.
count : 로그 남기는 횟수를 의미한다.

option
class : 클래스 로더에 대한 통계
compiler : 핫스팟 JIT 컴파일러에 대한 통계
gc : GC 힙 영역에 대한 통계
gccapacity : 각 영역의 허용치와 연관된 영역에 대한 통계
gccause : GC의 요약 정보와 마지막 GC와 현재 GC에 대한 통계
gcnew : 각 영역에 대한 통계
gcnewcapacity : Young 영역과 관련된 영역에 대한 통계
gcold : Old와 Perm 영역에 대한 통계
gcoldcapacity : Old 영역의 크기에 대한 통계
gcpermcapacity : Perm영역의 크기에 대한 통계
gcutil : GC에 대한 요약 정보
printcompliation : 핫스팟 컴파일 메소드에 대한 통계

jstatd는 원격지에서 모니터링을 할 수 있다.

jstatd [-nr] [-p port] [-n rminame]

nr : RMI registry가 존재하지 않을 경우 새로운 RMI 레지스트리를 jstatd 프로세스내에서 시작하지 않는 것을 정의하기 위한 옵션
p : RMI 레지스트리를 식별하기 위한 포트 번호
n : RMI 객체의 이름을 지정한다. 기본이름은 JStatRemoteHost 이다.

실행하기 위해서는 자바가 설치되어 있는 서버 내 디렉토리의 lib/security/java.policy 파일에

아래의 허가 명령어를 추가해야한다.

grant codebase "file:${java.home}/../lib/tools.jar"{
permission java.security.AllPermission;
};

visualgc는 JDK의 기본 포함된 툴이 아니다. visualgc.bat 파일을 열어서 아래의 옵션을 추가한다.

set JVMSTAT_HOME=c:\jvmstat

set JVMSTAT_JAVA=c\jdk1.5

실행 방법은 visualgc 2904@minspc:2020 vmid와 호스트명, 포트번호를 지정한다.

위와 같은 화면이 표시된다.

verbosegc 자바 수행 시에 간단히 -verbosegc 옵션으로 GC를 분석할수 있는 간단한 명령어이다.

참고로 HP장비에서 1.3.1이상의 버젼에서는 -Xverbosegc, HP장비에서 1.4.0이상의 핫스팟 VM을

사용할 경우는 -Xloggc JDK 1.4.X 이상의 버젼에서는 -XX:+PrintTLE

JDK 5.0 이상의 버젼에서는 PrintTLE 옵션 사용 불가

PrintGCTimesStamps : GC 발생 시간을 알수 있음.
PrintHeapAtGC : GC의 많은 정보를 표시하나 분석의 어려움

(edem, survivor,old,전체 영역의 메모리 할당 상황을 표시함)
PrintGCDetails : GC의 간결한 정보를 표시한다.

추가적인 분석툴

GC Analyzer : Sun에서 제공하는 GC 분석 툴, 펄스크립트를 기반으로 분석결과를 정리해준다.
IBM GC 분석기(IBM Pattern Modeling and Analyer Tool for java Garbage Collector) : IBM에서 제공하는 GC 분석 툴
HPjtune : HP에서 제공하는 GC 분석 툴

-----------------------------------------------------------------------------------------------

16. 서버를 어떻게 세팅해야 할까?

웹기반의 시스템에서 성능에 영향을 줄 만한 세팅은 아래와 같다.

웹 서버 세팅
WAS 서버 세팅
DB 서버 세팅
장비 세팅

웹서버 세팅
웹 서버는 반드시 WAS 앞에 두어야 한다. WAS를 웹 서버로 사용하면 안된다. 왜냐하면 WAS는 Web Application Server 이기 때문이다. 웹에서 사용하는 애플리케이션 서버지 웹 서버가 아니다. 정적인 부분은 웹서버에서 처리해야 한다. 그렇지 않으면 WAS서버에서 웹서버의 역활까지 수행해야한다. 웹서버에서 WAS 서버앞에 두지 않으면 이미지,CSS,JS,HTML등을 처리하느라 아까운 WAS 서버의 스레드를 점유하게 된다.

아파치 웹 서버는 MPM(Multi-Processing-Module)이라는 것을 사용한다.

여러개의 프로세싱 모듈기반의 서비스를 제공한다는 의미이다.

conf 디렉토리 하단의 httpd.conf 파일을 확인한다.

....

ThreadsPerChild 250

(웹서버가 사용하는 스레드의 개수를 지정, 아파치 프로세스 하나당 250개의 스레드가 만들어짐)

MaxRequestsPerChild 0 (최대 요청 개수를 지정함, 0이면 그 수의 제한이 없음)

....

스레드에 관련된 내용을 보다 세밀하게 지정하려면

httpd.conf 파일의 "Include conf/extra/Httpd-mpm.conf"를 찾아서 주석을 해제하고 수정을 한다.

.....

StartServers 2 (서버를 띄울때 프로세스의 개수를 지정)

MaxClients 150 (최대 처리 가능한 클라이언트 수를 지정)

MinSpareThreads 25 (최소 여유 스레드 수를 지정)

MaxSpareThreads 75 (최대 여우 스데르 수를 지정)

ThreadsPerChild 25

MaxRequestsPerChild 0

</IfModule>

.....

KeepAlive on ( off 하게 되면 매번 Http 연결을 맺었다가 끊었다가 하는 작업을 반복함)

KeepAliveTimeout 15 (초 단위로 KeepAlive가 끊기는 시간을 설정하기 위한 부분)

DB Connection pool 및 쓰레드 갯수 설정

대부분 WAS에서 두 설정값의 기본 개수가 10~20개 정도이다. 따라서 이 기본값으로 오픈하면 서버가

원하는 요청량을 처리하지 못하게 된다. DB Connection pool은 보통 40~50개로 지정한다.

스레드개수는 이보다 10정도 더 지정한다. 이렇게 지정하는 이유는 스레드 개수가 DB Connection Pool의

개수보다 적으면 적은 수만큼의 연결은 필요 없기 때문이다.

WAS 인스턴스 개수 지정

: 특별히 정해진 법칙이 있는 것은 아니지만, 단독 인스턴스를 구성하여 사용하는 것은 서버에 예기치 못한

상황이 발생했을 때 서비스가 불가능해지므로 되도록 피해야 한다. 장비가 한 대여도, 두 개 이상의

인스턴스가 서로 클러스터링 하도록 지정하여 사용자의 세션 정보를 공유하도록 하는 것이 좋다.

그리고 스레드나 DB Connection Pool의 개수를 100개 이상으로 설정하려고 할 때에는 보통 인스턴스를

두 개로 분리한다. (하지만 인스턴스의 수를 증가시켜서 성능이 좋아진 경우는 거의 없다.)

Session Timeout 시간 설정

WEB-INF 폴더 하단의 web.xml 파일에 설정하는 서블릿 스펙에 정의된 표준 설정값이다.

....

<session-timeout>30</session-timeout>

GC 값 세팅 및 메모리 설정 방법

1. java ... -Xmx512m -Xms256m ...

: Xmx는 최대 힙 메모리, Xms는 최소 힙 메모리를 지정한다.(m:메가바이트, k:킬로바이트, g:기가바이트)

2. 옵션

옵션 및 기본값	설명
-XX:+AggressiveOpts	: JDK 5.0 업데이트 6버전부터 소개된 내용. : 컴파일러 최적화를 켜는 옵션이다. : 이후 JDK 버전에서는 기본으로 사용된다.
-XX:CompileThreshold=10000	: 컴파일 전에 메서드의 수행과 분기되는 개수를 지정 : 클라이언트 버전은 기본값이 1500이다.
-XX:LargePageSizeInBytes=4m	: 자바 힙에서 사용하는 대형 페이지의 크기 지정 : jdk 1.4 업데이트 1부터 적용된 내용이다.
-XX:MaxHeapFreeRatio=70	: 메모리 감소를 피하기 위해서 GC를 수행한 이후의 최대 힙 영역의 퍼센트를 지정한다.
-XX:MaxNewSize=size	: Young 영역의 최대 크기를 바이트 단위로 지정
-XX:MaxPermSize=64m	: Perm 영역의 크기를 지정
-XX:MinHeapFreeRatio=40	: 메모리 확장을 피하기 위해서 GC를 수행한 이후의 최소 힙영역의 퍼센트를 지정한다.
-XX:NewRatio=2	: Young 영역과 Old 영역의 크기 비율 지정
-XX:NewSize=2.125m	: Young 영역의 기본 크기를 지정
-XXReservedCodeCacheSize=32m	: 예약된 코드의 캐시 크기를 지정
-XX:SurvivorRatio=8	: Eden 영역과 Suvivor 영역 크기의 비율을 지정
-XX:TargetSuvivorRatio=50	: GC를 수행한 이후에 Suvivor 영역에서 사용하는 공간의 퍼센트를 지정한다.
-XX:ThreadStackSize=512	: 스레드의 스택 크기를 킬로바이트 단위로 지정함. 0으로 지정할 경우 기본 스택 크기를 의미함
-XX:+UserFastAccessorMethods	: 기본 자료형의 값을 가져올 때 최적화 버전을 사용

-----------------------------------------------------------------------------------------------

17. 반드시 튜닝 및 점검해야 하는 대상은?

가장 많이 수행하는 상위 20%의 화면을 분석 및 튜닝 대상으로 선정해야함.

로그인 및 초기화면, 가장많이 사용하는 화면을 위주로 성능을 분석하는것이 가장 현명한 방법이다.

-----------------------------------------------------------------------------------------------

18. 모니터링 API인 JMX

JMX(Java Management Extensions) 자바기반의 모든 애플리케이션을 모니터링하기 위해서 만든 기술

JDK 5.0부터 본격적으로 지원됨.

JMX의 단계

인스트루먼테이션 레벨(Instrumentation Level)
하나 이상의 MBeans혹은 MBeans를 제공한다. 필요한 리소스들의 정보를 취합하여 에이전트로 전달하는 역할
에이전트 레벨(Agent Level)
리소스를 관리하는 역할, 보통 에이전트는 모니터링이 되ㅏ는 서버와 같은 장비에 위치한다.
분산 서비스 레벨(Distributed Services Level)
JMX 관리자를 구현하기 위한 인터페이스와 컴포넌트를 제공한다.
추가 관리 프로토컬 API들(Additional Management Protocol APIs)

MBeans는 4가지 종류가 있다.

표준 MBean(Standard MBean) 변경이 많지 않은 시스템을 관리하기 윈한 MBean이 필요할 경우 사용한다.
동적 MBean(Dynamic MBean) 애플리케이션이 자주 변경되는 시스템을 관리하기 위한 MBean이 필요한 경우 사용한다.
모델 MBean(Model MBean) 어떤 리소스나 동적으로 설치가 가능한 MBean이 필요한 경우 사용한다.
오픈 MBean(Open MBean) 실행 중에 발견되는 객체의 정보를 확인하기 위한 MBean이 필요할 때 사용한다. JMX의 스펙에 지정된 타입만 리턴해야 한다.

JConsole : Sun에서 제공하는 JMX 모니터링용 툴이다. JDK 5.0 이 이상 부터 포함되어 있다.

기본적으로 힙 메모리 사용량, 스레드 개수, 로딩된 클래스 개수, CPU 사용률

원격지에서 사용하려면

-Dcom.sun.management.jmxremote.port=9003

-Dcom.sun.management.jmxremote.ssl=false

-Dcom.sun.management.jmxremote.authenticate=false

-----------------------------------------------------------------------------------------------

19. 어떤 화면이 많이 쓰이지는 알고 싶다.

웹서버가 존재하는 시스템에서 어떤 화면이 많이 호출되었는지 확인 하는 방법은 웹로그를 사용하여

분석하는 방법이다.

한화면을 구성하는 이미지,CSS,JS, 플래스 파일 등 모든 파일에 대한 요청의 결과가 이 로그 파일에 쌓인다. 대부분 하나의 클라이언트에서 동일한 파일을 한 번 다운로드 받으면 304라는 리턴 코드를 제공한다.

무료 웹로그 분석 툴

Analog : http://www.analog.cx
AWStats : http://awstats.sourceforge.net
Webalizer : http://www.mrunix.net/webalizer

-----------------------------------------------------------------------------------------------

20. 자바 기반의 배치프로그램을 튜닝했던 사례

반복되는 부분 없애기

메모리를 최대한 절약해서 사용하기

퀴리도 효율적으로 짜기

-----------------------------------------------------------------------------------------------

21. 잘되어 있는 시스템도 튜닝 대상은 있다.

중복된 코드 처리 부분을 해결하기 위해 static을 사용하는 것이 약이 될 수 있고, 독이 될 수도 있다.

만약 자주 바뀌는 코드성 데이터를 이와 같이 처리했다가는 시스템에서 엄청나게 많은 오류가 발생 할 수도

있으니, 상황에 맞게 사용하길 바란다.

-----------------------------------------------------------------------------------------------

22. 복합적인 문제가 발생한 프로젝트

우선순위를 따져서 가장 효과가 큰 부분부터 해결해 나가는 것이 현명한 방법이다.

-----------------------------------------------------------------------------------------------

23. 애플리케이션에서 점검해야 할 대상들

패턴과 아키텍처는 잘 구성되어 있는가?

너무 많은 패턴을 사용하지 않았는가?
데이터를 리턴할때 TO(혹은 VO)패턴을 사용하였는가? 아니면 Collection 관련 클래스를 사용하였는가?
서비스 로케이터(Service Locator) 패턴은 적용이 되ㅏ어 있는가?

기본적인 애플리케이션 코딩은 잘 되어 있는가?

명명 규칙은 잘 지켰는가?
필요한 부분에 예외 처리는 되어 있는가?
예외 화면은 지정되어 있는가?
예외 정보를 혹시 e.printStackTrace()로만 처리하고 있지 않는가?
System.gc() 메소드가 소스에 포함되어 있지 않은가?
System.exit() 메소드가 소스에 포함되어 있지 않은가?
문자열을 계속 더하도록 코딩하지는 않았는가?
StringBuffer나 StringBuilder 클래스도 제대로 사용했는가?
무한 루프가 작동할 만한 코드는 없는가?
static 남발하지 않았는가?
필요한 부분에 synchronized 블록을 사용하였는가?
IO가 계속 발생하도록 개발되어 있지 않은가?
필요 없는 로그는 다제거 했는가?
디버그용 System.out.println은 다 제거했는가?

웹관련 코딩은 잘 되어 있는가?

JSP의 include는 동적으로 했는가? 아니면 정적으로 했는가?
자바 빈즈는 너무 많이 사용하지 않았나?
태크 라이브러리 적절하게 사용했나?
EJB는 적절하게 사용하였나?
이미지 서버를 사용할 수 있는 환경인가?
사용 중인 프레임웍은 검증 되었는가?

DB관련 코딩은 잘 되어 있는가?

적절한 JDBC 드라이버를 사용하는가?
DB Connection, Statment, ResultSet은 잘 닫았는가?
DB Connection Pool은 잘 사용하고 있는가?
자동 커밋 모드에 대한 고려는 하였는가?
ResultSet.last() 메소드를 사용하였는가?
PreparedStatements를 사용하였는가?

서버의 설정은 잘 되어 있는가?

자바 VM 관련 옵션들은 제대로 설정되어 있는가?
메모리는 몇 MB로 설정해 놓았는가?
GC 설정은 어떻게 되어 있는가?
서버가 운영 모드인지 개발모드인지 확인 하였는가?
WAS의 인스턴스가 몇 개 기동되고 있는가?
JSP Precomplie 옵션은 지정해 놓았는가?
DB Connection Pool 개수가 스레드 개수는 적절한가?
세션 타입아웃 시간은 적절한가?
검색 서버가 있다면, 검색 서버에 대한 설정 및 성능 테스트를 하였는가?

모니터링은 어떻게 하고 있는가?

웹로그는 남기고 있는가?
verbosegc 옵션은 남기고 있는가?
각종 로그 파일에 대한 규칙은 있는가?
서버의 시스템 사용률은 로그로 남기고 있는가?
모니터링 툴은 사용 중인가?
모니터링 툴에 대한 설정은 적절하게 되어 있는가?
서버가 갑자기 코어 덤플를 발생시키지 않는가?
응답 시간이 너무 느리지 않은가?

-----------------------------------------------------------------------------------------------

Blog2Book 자바 성능을 결정짓는 코딩 습관과 .zip

0.19MB

'IT_Programming > Java' 카테고리의 다른 글

Painting in AWT and Swing - 반복적 repaint() 호출 이슈! (0)	2010.01.19
Java(JDK) 7 특징 (0)	2009.11.26
자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기 정리 3 ~ 12 (0)	2009.10.10
자바의 성능을 결정 짓는 코딩 습관과 튜닝 이야기 정리 1 ~ 2 (0)	2009.10.10
[정리] Java Application에서 점검해야 하는 대상들... (0)	2009.10.08

현재글자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기 정리 13 ~ 23

삶의 모든 순간을 즐겨라!

Today :
Yesterday :

삶의 모든 순간을 즐겨라!