5Jeus Performance Tuning-cover - TmaxSoft · 2019-04-09 · JEUS Performance Tuning 7 5) 슬로우 스타트 슬로우 스타트는 수신측이 최대 처리할 수 있는 데이터

WhitepaperWhitepaperWhitepaperWhitepaper

JEUS Performance Tuning

Copyrightⓒ 2001 TmaxSoft Co.,Ltd. All Right Reserved.

JEUS Performance Tuning 1

Contents

I. JEUS Performance Tuning...................................................................................................... 3

II. OS Tuning ............................................................................................................................ 4

File Descriptor ................................................................................................................... 4

TCP parameters ................................................................................................................. 5

1) 리슨 큐의 길이 ..................................................................................................... 5

2) 재전송 지연 .......................................................................................................... 5

3) CLOSE_WAIT 시간 .............................................................................................. 6

4) 연결지속 시간....................................................................................................... 6

5) 슬로우 스타트....................................................................................................... 7

III. Network Tuning .................................................................................................................. 8

IV. JVM Tuning.......................................................................................................................... 9

Java Heap Size & Garbage Collection .......................................................................... 9

HotSpot 옵션 ........................................................................................................... 10

V. JEUS Tuning........................................................................................................................ 11

Engine Container와 Engine 매핑 ..................................................................................... 11

JDBC Connection Pool...................................................................................................... 12

Security Off ..................................................................................................................... 14

VI. EJB Tuning ........................................................................................................................ 15

Local Method Invocation .................................................................................................. 16

EJB Bean Clustering ......................................................................................................... 18

EJB Bean Pooling ............................................................................................................. 19

InitCaching (Entity Bean Only) ......................................................................................... 21

Fetch Size (Entity Bean Only)........................................................................................... 21

Home Method (Entity Bean Only)..................................................................................... 22

Method Classification (Entity Bean Only) .......................................................................... 23

ENGINE 타입 선택하기 (Entity Bean Only) ..................................................................... 24

SUBENGINE 타입 선택하기 (CMP Bean Only) ................................................................. 26

Fast Deploy & EJBCompiler .............................................................................................. 28

VII. Servlet/JSP Tuning ........................................................................................................... 30

Session Routing ............................................................................................................... 30

JDBC Connection Pooling ................................................................................................. 32

WebT Connection Pooling ................................................................................................ 33

Servlet/JSP Auto Reloading .............................................................................................. 33


JSP Batch Compiler .......................................................................................................... 35

WebServer와의 연결 ....................................................................................................... 36

VIII. JEUS Application Tuning ................................................................................................. 38


I. JEUS Performance Tuning

시스템의 성능을 향상시키기 위해서는 여러 가지 사항을 고려해야 된다. 하드웨어의 사양을

높이는 방법, 네트웍 튜닝, OS의 환경변수 튜닝, JVM 환경변수를 튜닝하는 방법, 그리고 어

플리케이션 프로그램을 튜닝하는 방법 등등 어느 하나 소홀히 할 수 있는 것이 없다. 성능

향상은 어느 특정 부분만을 튜닝하여 얻는 것이라기 보다는, 시스템이 운영되는 여러 환경

을 전체적으로 이해하고 고려해야만 원하는 성능을 얻을 수 있는 것이다.

본 문서에서는 다음과 같은 튜닝 관점에 대하여 다루려 한다.

Operation System

Network

JVM

JEUS - 공통적인 부분

JEUS – EJB Engine

JEUS – Servlet Engine

Application

위에 열거한 요소들은 각 분야의 전문지식이 필요하니 튜닝을 위해 수정을 할 시에는 반드

시 각 분야의 전문가와 상의하여 결정하도록 한다.


II. OS Tuning

File Descriptor Unix 에서는 각 사용자의 Account 가 정해진 수의 file descriptor를

가진다. “ulimit” 라는 command를 사용하여 리소스 limit 을 살피고

고쳐보자. Reource limit 는 한 쌍의 값을 가지고 있고 그 값은

current limit (soft) 과 maximum limit (hard) 를 표시한다. Hard

limit 는 /etc/system 에서 고칠 수 있고 그 후엔 반드시 새로 부팅시

켜야한다.

Note : Soft limit 는 고치지 않도록 한다. 이 값은 제우스에는 반

영되지 않는다.

Hard limit 을 높이려면 루트 권한을 가진 계정을 가지고 있어야 한다

Solaris 의 경우

$ ulimit

$ set rlim_fd_max 4096 /* hard limit */

File Descriptor 와 관련된 문제점들

1. Too many open files

2. Broken pipe error

3. ClassNotFound


TCP parameters

1) 1) 1) 1) 리슨리슨리슨리슨 큐의큐의큐의큐의 길이길이길이길이

TCP 에서는 정해진 크기의 큐를 두어서 즉시 처리할 수 없는 접속을

그 큐에 넣어서 관리한다. 이런 큐를 보통 리슨큐 또는 backlog 라고

한다. 트래픽이 한꺼번에 몰리게 되었을 때 이 큐의 크기가 작을 경우

접속자를 차단하는 경우가 생기게 된다. 리슨큐를 증가 시키면 처리할

수 있는 접속 보류자 수를 늘리게 되지만 큐가 클수록 더 많은 메모리

가 필요하다는 것을 알아두어야 한다.

-Solaris 의 경우

$ ndd –set /dev/tcp tcp_conn_req_max_q 1024

-linux 2.0 의 경우

include/linux/socket/h 파일에서 SOMAXCONN의 기본값을 1024 으

로 바꾸고 커널을 다시 컴파일 하면 된다.

2) 2) 2) 2) 재전송재전송재전송재전송 지연지연지연지연

TCP 에서는 정해진 시간 내에 세그먼트 확인 응답을 받지 못할 경우

손실 된 것으로 가정하고 다시 다른 복사본을 전송한다. 이때 기본으

로 정해진 시간은 200ms 인데 지연시간이 보통 큰 인터넷의 경우에는

기본값이 작아 같은 패킷을 여러 번 전송하는 경우가 생길 수 있다.

재전송 횟수를 확인하는 방법을 확인하여 재전송 지연 값을 조절하도

록 한다.

-Solaris

재전송 횟수 확인절차

$ netstat –s

위의 명령으로 나온 결과중 tcpOutDataSegs 와 tcpRetransSegs, 그리

고 tcpOutDataBytes 와 tcpRetransBytes 를 비교하여 세그먼트 또는

바이트의 20% 이상이 재전송 되는 경우라면 재전송 지연 값을 높이도

록 한다.


재전송 지연 값 설정

$ ndd –set /dev/tcp tcp_rexmit_interval_initial 3000

3) CLOSE_WAIT 3) CLOSE_WAIT 3) CLOSE_WAIT 3) CLOSE_WAIT 시간시간시간시간

이 값은 소켓이 닫힌 이후에 다른 클라이언트가 이 소켓을 사용할 수

있을 때까지 기다리는 시간을 말한다. 너무 작게 설정되어 있을 경우

에 세그먼트가 늦게 도착하면 정상적인 데이터를 받지 못할 수도 있고

오히려 너무 크게 설정되어 있을 경우에는 접속량이 줄어드는 결과를

낳을 수도 있다. 남아있는 세그먼트가 없을 정도로만 값을 설정하는

것이 좋다. Solaris 의 경우 기본값이 4분으로 설정되어 있는데 접속

자가 많을 경우에는 성능에 큰 저하를 가져올 수 있기 때문에 60초 정

도로 설정하는 것이 바람직하다.

-Solaris

$ ndd –set /dev/tcp tcp_time_wait_interval 60000

-Solaris 2.5.1 or 2.6 ~

$ ndd –set /dev/tcp tcp_close_wait_interval 60000

4) 4) 4) 4) 연결지속연결지속연결지속연결지속 시간시간시간시간

TCP 의 접속에서는 한쪽이 다운이 되는 경우 다른 한쪽이 접속을 시

도 하기 전까지는 다운된 쪽의 상태를 확인 할 방법이 없다. 실제로

클라이언트가 정상적으로 접속을 종료하지 않는 경우가 많기 때문에

서버측에서는 리소스가 낭비 될 수 있다. 클라이언트측의 접속상태 확

인을 일정시간동안마다 하게 되는데 그 간격을 조절함으로써 성능을

향상시킬 수 있다. 기본 시간 간격은 보통 2시간에서 8시간정도로 되

어있는데 클라이언트가 많을 경우에는 줄여서 설정해야 한다.

-Solaris

$ ndd –set /dev/tcp tcp_keepalive_interval 900000


5) 5) 5) 5) 슬로우슬로우슬로우슬로우 스타트스타트스타트스타트

슬로우 스타트는 수신측이 최대 처리할 수 있는 데이터 양까지 한 개

의 세그먼트부터 다시 두개 그리고 네개, 이런식으로 보내는 방식이다.

장점은 최적의 송신량을 알 수 있다는 점이지만 접속 횟수가 많고 지

속 시간이 짧은 웹 환경에서는 오히려 느릴 수도 있다.

윈도우를 사용하는 클라이언트에게 슬로우 스타트를 사용하게 되면 문

제가 생길 수 있는데 윈도우 클라이언트는 한 개의 패킷이 아닌 두개

의 패킷을 처음부터 기다리기 때문이다. 한 개의 패킷이 보내진 후 클

라이언트는 아무런 응답없이 두번째의 패킷을 기다리게 되며 서버측에

서는 첫번째 보낸 패킷의 응답을 기다리고 있기 때문에 종료시간이 되

고 나서야 두번째의 패킷전송이 시작되게 되고 따라서 많은 시간이 필

요하게 된다. 이런 이유로 슬로우 스타트의 처음 패킷을 2개부터 시작

하게 해야 할 필요성이 있다.

-Solaris

$ ndd –set /dev/tcp tcp_slow_start_initial 2

슬로우 스타트의 최대치 역시 조절해줄 필요가 있는데 이는 기본값이

요즘의 데이터 전송량에 비해 너무 작기 때문이다.

-Solaris

$ ndd –set /dev/tcp tcp_cwnd_max 65536


III. Network Tuning

네트워크 자원이 모자라 성능이 저하되는 경우가 있을 수 있다. 특히

많은 클라이언트의 접속을 허용하는 웹서버의 경우에는 네트워크의 성

능은 아주 중요하다. 네트워크의 상태를 잘 파악하고 혹시 네트워크가

서버의 처리량을 못 따라가는 것이 아닌지 확인할 필요가 있다.

충분한 Bandwidth 를 확보하는 것은 아주 중요하다. 클라이언트가 많

을 경우 많은 접속을 허용할 수 있어야 하고 서버 역시 다른 Tier 에

있는 Database등을 접속해야 하므로 이 모두를 소화할 수 있는

Bandwidth를 가지고 있어야 한다.

충분한 Bandwidth 를 가지고 있는 경우에 여전히 네트워크가 제우스

서버의 성능을 저하시킨다고 판단되는 경우 네트워크 하드웨어나 소프

트웨어에 문제가 있는지 확인해본다. 네트워크 전문가와 상의하여 이

부분의 문제점을 찾아 해결하도록 한다.

위의 자원들을 다 확인하고 나서 여전히 문제점이 있다면 네트워크 인

프라의 구조를 다시 살펴보아야 한다. 디자인이 안정적이지 않다면 접

속량과 처리량이 많을 경우에 문제가 야기될 수 있다. 시스템을 더 늘

리는 방법으로 일반적으로 해결될 수 있으나 심한 경우에는 인프라 구

조를 다시 디자인 해야 할 수도 있다.


IV. JVM Tuning

Java Heap Size & Garbage Collection Java Heap 에는 자바 프로그램의 object 들이 있는 곳이다. 이 안에

는 활동중인 Object 가 있을 수도 있고 또는 아무도 point 를 안 해

Garbage 가 된 Object 들도 있다. Heap Size 의 중요성은 Garbage

Collection 과 밀접한 관계가 있다. 크기가 큰 경우에는 Garbage

Collection 이 오래 걸리는 반면 그 빈도는 적게된다. 반대로 크기가

작은 경우에는 Garbage Collection 은 짧은 반면 그 빈도는 늘어나게

된다. 가장 이상적인 Heap Size 는 Garbage Collection 에 쓰이는 시

간을 최소화 하는 크기라 할 수 있다.

서버 어플리케이션의 경우에는 기본값이 충분치 않을 수 있으므로 재

설정이 필요하다. Garbage Collection 을 수행 시 걸리는 시간이 너무

크지 않다면 시스템의 RAM 크기를 고려해 될 수 있는 한 큰 값을 설

정하도록 한다. Heap 의 크기는 1024의 배수로 1MB 이상 설정해야

한다. 일반적으로 최소치와 최대치를 같은 값으로 설정하는 것이 권장

된다. 프로세서를 늘린 경우에는 이 값을 다시 높게 설정해야 한다.

전체 Garbage Collection 을 할 때 시간이 3-4초 이상 걸리는 경우에

는 Size 를 줄일 필요성이 있다. 또한 Garbage Collection 이 끝난 후

에 Heap 에 할당된 메모리가 항상 85 % 이상이 되는 경우에도 size

를 줄이는 것이 바람직하다.

-Xverbosegc 옵션은 매 Garbage Collection 의 정보를 모니터하게 해

준다. 이때의 정보를 이용하여 적절한 Heap Size 를 계산해볼 수 있

다.

-Xverbosegc:file=/tmp/gc$$.out 옵션을 주면 Garbage Collection 의

정보를 파일로 저장한다.

$ java .. –Xms512m –Xmx512m …

-Xms 옵션은 Heap 의 최소치를 설정한다.

-Xmx 옵션은 Heap 의 최대치를 설정한다.

Heap Size 가 너무 작을 경우 OutOfMemoryError 가 발생할 수도 있


다. 이런 경우에도 Heap Size 를 늘려주어야 한다.

1.3 Java HotSpot JVM 은 성능 향상을 위해 Generational Collection

방식을 사용하고 있다. Object들을 Generation 별로 나누어 각

Generation 공간이 찬 경우 Live Object 들만을 다음 Generation 으

로 옮기고 나머지들은 Garbage Collection 을 하는 방식이다. 대부분의

Object 들이 생성된 직후에 Garbage 가 되기 때문에 향상된 성능을

가져온다. Generation 별로 공간이 있기 때문에 그 크기 역시 지정해줄

수 있다. 전체 Heap Size 와 비례하게 설정을 하고 프로세서를 늘린

경우에는 이 값들의 재설정이 필요하다.

$ java .. –XX:NewSize=128m –XX:MaxNewSize=128m –XX:SurvivorRatio=8 …

-XX:NewSize 옵션은 New generation 의 heap size 를 설정한다. 전

체 Heap 사이즈의 25% 정도로 설정하는 것이 보통이다.

-XX:MaxNewSize 옵션은 New generation 의 heap size 최대값을 설

정한다.

-XX:SurvivorRatio 옵션은 New generation 안에서 Eden 과

Survivor 사이의 비율을 설정한다.

HotSpot 옵션옵션옵션옵션 HotSpot 에는 많은 종류의 옵션들을 설정해줄 수 있는데 이중에서 성

능을 향상시키는데 도움이 되는 몇 가지를 살펴보도록 하겠다.

-oss 이 옵션은 Java Thread Stack Size 를 설정할 때 쓰인

다. 이 값을 2MB 이상으로 설정하는 경우 성능의 저하를

초래할 수 있다.

-ss 이 옵션은 Native Thread Stack Size 를 설정할 때 쓰

인다. 이 값 역시 2MB 이상으로 설정하는 경우 성능의 저

하를 초래할 수 있다.

-Xnoclassgc 이 옵션은 클래스에 대한 Garbage Collection

을 끄는데 쓰인다. 이 옵션을 설정한 경우에는 더 큰 Heap

Size 가 필요하다.


V. JEUS Tuning 본 장에서는 JEUS시스템 전체적인 Performance향상 방법을 다루고자

한다..

다룰 내용은 아래와 같다.

Engine Container와 Engine 매핑

JDBC Connection Pool

Local Transaction Optimization

Security Off

Engine Container와와와와 Engine 매핑매핑매핑매핑 JEUS 시스템은 EJB 엔진, Servlet 엔진, JMS 엔진 의 세가지 엔진을

Engine Container라는 단위로 자유로이 설정할 수 있다. 바꿔말하면

하나의 Engine Container는 하나의 JVM에 매핑되므로 엔진을 JVM 단

위로 설정이 가능하다는 얘기이다. 이것은 전체 시스템의 성능 및 리소

스 관리 차원에서 매우 중요하다.

여러 엔진을 같은 JVM에 할당할 시 얻는 성능 및 리소스 이용 측면에

서의 장점을 들자면

Local Method Invocation 기능을 이용하여 프로세스간 통신을 로

컬 메쏘드 콜 형태로 바꾸어 성능을 향상시킬 수 있다.

복수 개의 엔진이 하나의 JVM에 할당되므로, 각 엔진을 각 JVM

에 할당하여 운영하는 것보다 시스템 리소스를 적게 잡고서도 운

영이 가능하다.


JDBC Connection Pool 데이터베이스에 JDBC Connection을 생성하는 작업은 상당히 느린 작

업이다. Connection Pool을 이용하지 않는 에플리케이션의 경우 JDBC

Connection을 맺고 끊고 하는 작업을 반복한다면 이는 성능을 떨어뜨

린다. JEUS는 Connection Pool을 제공함으로써 물리적 JDBC

Connection을 끊지 않고, 논리적 JDBC Connection만 끊게 함으로서

실제 데이터베이스와의 물리적 JDBC Connection을 재사용하게 해 준

다. JDBC Connection Pool 기술은 앞서 말한 JDBC Connection 생성

작업을 거의 없앰으로서 시스템의 성능을 향상시킨다.

JeusMain.xml의 <DataSource> 항목에 DataSource에 대한 환경을 설

정할 수 있는 데, 파라미터를 설정할 때, 몆가지 사항을 고려해야 한다.

(파라미터의 자세한 설명은 JEUS JDBC Guide를 참조하기 바란다.)

먼저, <MinPoolSize>와 <MaxPoolSize>를 동시 접근 유저수를 고려하

여 적절히 잡아야 된다. Pool Size가 너무 작다면 동시 접근 유저가

Connection을 얻기 위해 블록킹되는 시간이 길어져 성능을 떨어뜨리고,

너무 크게 잡는다면 Connection등 리소스의 낭비 뿐 아니라 불필요한

서버프로세스가 데이터베이스에 살아있어 성능을 저하시킨다. Pool

Size는 원칙적으로 동시에 Connection Pool에 Access하여 Connec-

tion을 얻어서 데이터베이스에 작업하려고 하는 쓰레드의 개수 만큼을

잡는 것이 좋다.

두 번째로, DataSource타입중 상대적으로 부하가 큰 XA DataSource의

사용 필요성을 고려해 보아야 한다. 복수개의 데이터베이스를 이용하는

데 분산 트랜잭션이 필요없거나, 단일 데이터베이스만 사용하는 경우라

면 DataSource 타입을 XADataSource가 아닌 ConnectionPool

DataSource를 이용하여 성능향상을 꾀할 수 있겠다.


Local Transaction Optimization

기본적으로 JEUS 트랜잭션 시스템은 XADataSource 를 기반으로 동

작한다. XADataSource 로부터 얻어진 XAConnection 을 사용하는 복

수 개의 작업을 트랜잭션으로 묶어 진행하게 되면 이 트랜잭션이 이기

종 데이터베이스에 대해 작업을 하고, 복수 개의 JEUS Transaction

Manager 관리 영역을 통과한다 하더라도 모두 하나의 global 트랜잭

션을 묶여져 처리된다. 이러한 동작방식은 다양하고 복잡한 어플리케이

션 프로그램에 대해 트랜잭션 환경을 제공하지만, 실제 어플리케이션

프로그램들은 대개 하나의 데이터베이스 인스턴스에 대해 작업을 수행

하고 그 트랜잭션의 실행 영역 또한 JEUS Transaction Manager 하나

의 관리 영역을 벗어나지 않는 것이 보통이다. (하나의 JEUS

Transaction Manager 는 하나의 JVM을 관리영역으로 한다) 이 경우

JEUS 트랜잭션 시스템에서는 XAConnection 이 아닌 Pooled-

Connection 을 이용하여 보다 효율적으로 트랜잭션을 수행한다.

트랜잭션 수행을 XADataSource로 하여야 하는 이유는 트랜잭션이 복

수 개의 데이터베이스에 접근하였을 때 이 트랜잭션의 commit 시점에

서 이들 데이터베이스 인스턴스들과 2 phase commit 을 진행하여야

하기 때문이다. 만약 트랜잭션이 하나의 데이터베이스 인스턴스와만 작

업을 진행한다면 하나의 데이터베이스에 대한 복수 개의 branch들을

하나의 branch로 묶는 branch joining과 1 phase commit 프로토콜에

의해서 commit 메시지 한번으로 commit 이 처리될 수 있다. Local

Transaction Optimization 에서는 이 보다 한 걸음 더 나가 트랜잭션

을 Global 트랜잭션이 아닌 Local 트랜잭션으로 처리하는 것이다. 어플

리케이션은 트랜잭션의 시작과 종료를 선언하고 트랜잭션 진행 중 복

수 개의 Connection을 얻어 작업을 진행하는 등 Global 트랜잭션과 똑

같이 작업을 수행하지만 JEUS Connection Pool 이 JEUS Transaction

Manager의 도움을 받아 트랜잭션의 진행을 추적해 가며 하나의

PooledConnection 이 계속 사용되도록 Connection을 별도로 관리한

다. 이렇게 하면 commit 과정에서 local 트랜잭션 commit을 사용할

수 있을 뿐만 아니라 XAConnection 관리와 관련된 추가적 메시지 교

환을 하지 않아도 되어 성능을 보다 향상시킬 수 있다.

Local Transaction Optimization의 개념은 J2EE 와 Connector

Architecture 에서 제시된 바 있다. JEUS 트랜잭션 시스템의 Local

Transaction Optimization 은 이루고자 하는 바는 같지만 그 구현 방


식이 다르다. Connector Architecture 에서는 하나의 트랜잭션이

local 트랜잭션으로 처리가 가능한가를 Connector 시스템이 자동으로

감지하지만 JEUS 트랜잭션 시스템에서는 어플리케이션 시스템 관리자

가 Local Transaction Optimization 용 Connection Pool을 따로 설정

하고 이 pool을 기반으로 트랜잭션 작업이 이루어져야만 한다. 이렇게

구현한 이유는 관리자가 이러한 설정을 해 줌으로써 Local

Transaction Optimization 처리가 훨씬 간단하고 효율적으로 구현될

수 있으며 이러한 설정이 매우 간단하게 이루어 질 수 있기 때문이다.

Security Off 시스템 운영 중 JEUS에서 제공하는 보안기능을 사용하지 않는 경우

JeusMain.xml 파일의 <Engine Container>별로 설정하는

<SecuritySwitch> 항목을 false로 설정하는 것이 좋다. 이것이 true로

설정되어 있으면 엔진 내부의 작업이나 클라이언트가 요청한 작업을

엔진에서 처리할 때 인증(Authentication)과 권한체크(Authorization)

작업이 빈번히 일어난다. 이러한 보안관련 작업은 JEUS 시스템에 오버

헤드를 주므로 JEUS제공 보안기능을 이용하지 않는 경우에는 이를 사

용하지 않도록 설정하는 것이 좋다.


VI. EJB Tuning 본 장에서는 JEUS EJB 엔진에서의 성능 향상을 위한 방법을 다루어

보도록 하겠다.

앞으로 다룰 JEUS EJB 튜닝 방법의 종류를 아래에 열거하였다.

모듈간 통신 방법 관련

Local Method Invocation

클러스터링 관련

EJB Bean Clustering

Pooling 관련

EJB Bean Pooling

Entity Bean 관련

InitCaching (Entity Bean Only)

Fetch Size (Entity Bean Only)

Home Method (Entity Bean Only)

Method Classification (Entity Bean Only)

Engine 타입 선택하기 (Entity Bean Only)

Subengine 타입 선택하기 (CMP Bean Only)

Deploy 관련

Fast Deploy & EJBCompiler

각각의 의미를 명확히 이해하여 구축하려 하는 시스템이 최적화된 성

능을 내도록 하자.


Local Method Invocation 이전에는 한 Bean에서 같은 엔진내의 다른 Bean의 메쏘드를 호출할 경우, 이는 엔진 밖의 클라이언트가 호출하는 경우와 마찬가지로 RMP 또는 RMI./IIOP 형태의 프로토콜을 이용하여 메쏘드콜을 해야만 했었

다. 이런 형태의 메쏘드 콜은 리소스를 많이 사용할 뿐만 아니라 속도

도 느리다.

Jeus-ejb-dd_<모듈명>.xml 파일의<isLocalInvocationOptimized> 항

목을 true로 설정하여 같은 엔진내의 Bean간의 호출을 로컬 메쏘드 콜

로 바꾸어 성능을 향상시킬 수 있다. 메쏘드 호출이 되어질 Bean에 이

항목을 설정하도록 한다.

EJB 메쏘드 콜은 기본적으로 Call-By-Value이지만 jeus-ejb-dd_<모

듈명>.xml 파일의 <isLocalInvocationOptimized> 항목이 true로 설정

된 Bean을 호출할 경우는 Local Method Call이 되어 Call-By-

Reference로 동작함을 주의하여야 한다. 파라미터가 레퍼런스 형태로

동작함을 인지하고 주의깊게 사용하여야 한다.

구체적으로 JEUS내에서 Local Method Invocation이 가능한 통신 경우

를 살펴보자.

Servlet <–> EJB

Servlet 엔진과 EJB 엔진이 동일한 JVM에 위치하고 Servlet에서

EJB Bean을 메쏘드 콜할 경우.

EJB <–> EJB

서로 다른 엔진이 동일한 JVM에 있고, 각 엔진내의 EJB Bean간

의 통신의 경우. 또는 같은 엔진 내의 두개의 EJB Bean간이 통신

JMS <–> Message-Driven Bean

JMS Server로 부터 메시지을 받아 동작하는 Message-Driven

Bean의 경우 메시지 교환이 Local Method Call로 이루어 질 수

있다.


Jeus-ejb-dd_<모듈명>.xml 파일의 설정 예는 아래와 같다.

<jeus-ejb-dd>

<module-info />

<beanlist>

<stateless>

<ejb-name>test</ejb-name>

<export-port>0</export-port>

<export-name>testApp</export-name>

. . .

<isLocalInvocationOptimized>

true

</isLocalInvocationOptimized>

. . .

</stateless>

</beanlist>

</jeus-ejb-dd>


EJB Bean Clustering 하나의 Bean을 여러 개의 Engine에 동시에 Deploy하여 클러스터링할

수 있다. Jeus-ejb-dd_<모듈명>.xml 파일의 <clustering>항목에 클러

스터링 정보를 설정할 수 있다. Bean을 클러스터링 함으로써, 클라이언

트 요청을 클러스터링된 Bean에 부하를 분산시켜 동시접근 유저수를

증가시키고, 리소스를 효율적으로 사용할 수 있게 한다.. 또한 failover

옵션을 설정함으로써 Fail-Over 기능이 되게 할 수도 있다.

EJB Bean Clustering 기능을 이용하여 성능(Performance), 확장성

(Scalibility), 안정성(Stability) 그리고 가용성(Availability) 모두를 향

상시킬 수 있다.


<jeus-ejb-dd>

<module-info>

<module-name>Module1</module-name>

</module-info>

<beanlist>

<stateless>

<ejb-name>Bean1</ejb-name>


<export-name>Name1</export-name>

<export-iiop>false</export-iiop>

. . .

<clustering>

<cluster-name>ActiveStubLink</cluster-name>

<cluster-export-name>Name1</cluster-export-name>

<cluster-export-name>Name2</cluster-export-name>

<home-clustered>true</home-clustered>

</clustering>

. . .

</stateless>

</beanlist>

</jeus-ejb-dd>


EJB Bean Pooling 풀링은 클라이언트의 요청을 처리할 때 인스턴스 및 쓰레드의 생성 오

버헤드를 피하고 이를 재사용하여 리소스 사용 효율을 높힘으로써 시

스템 성능을 향상시키는 기술이다. EJB 모듈을 Deploy할 때, jeus-

ejb-dd_<모듈명>.xml 파일에 아래 세가지 값을 설정하여 EJB Bean별

로 풀링의 크기, 증가단위 및 Resizing 주기를 설정할 수 있다.

<bean-pool>

EJB Bean의 풀링 최소값, 최대값, 증가단위, Resizing 주기를 설

정한다.

<connect-pool>

EJB Object 의 풀링 최소값, 최대값, 증가단위, Resizing 주기를

설정한다.

<thread-pool>

특정 Bean을 동시에 수행할 수 있는 쓰레드의 최소값, 최대값,

증가단위, Resizing 주기를 설정한다.

<bean-pool> <connect-pool> 은 인스턴스 재사용을 위한 풀링 설정

이다. 클라이언트에서 EJB Bean을 생성하고 삭제하는 작업을 하는 경

우 <pool-max>를 크게 잡는 것이 성능 향상을 위해 좋다.

하지만 <thread-pool>은 엄밀히 말해 쓰레드의 재사용 설정이 아니다.

쓰레드의 생성 및 소멸은 RMI 런타임내에서 제어를 하기 때문에 JEUS

EJB 엔진에서는 이를 제어할 수 없다. 다만 RMI 런타임에서 시작된

쓰레드가 EJB 엔진 내의 EJB Bean을 수행할 때 동시에 수행될 수 있

는 쓰레드의 개수 및 Resizing 주기를 EJB Container에서 제어할 수

있는데 이에 대한 설정을 <thread-pool>항목에 해주면 된다.

<thread-pool>과는 달리 <bean-pool>, <connect-pool>에서의 풀링할

최대값 <pool-max>은 다른 의미를 가진다. <bean-pool>, <connect-

pool> 에서 설정한 <pool-max>값의 EJB Bean 인스턴스, EJB Object

인스턴스가 풀에서 모두 사용되어 풀이 비어 있는 경우, 이후에 추가적

인 클라이언트 요청이 오면 사용된 인스턴스가 풀에 반환되는 것을 기

다리지 않고 추가적인 인스턴스를 만들어 제공한다. 하지만 사용되어진

추가적인 인스턴스는 풀에 반환되지 않고 버려진다.

Stateless Session Bean의 경우 <bean-pool> 설정만을 하는데, 이는


<connect-pool>, <thread-pool> 도 동일한 값으로 설정됨을 의미한다.

Stateless Session Bean은 그 특성상 EJB Bean 인스턴스의 풀링 개수

가 EJB Object 인스턴스 개수 및 동시수행 가능한 쓰레드의 개수와 같

다. 때문에 Stateless Session Bean의 경우 세가지 중 하나인 <bean-

pool> 항목의 설정만으로 세가지의 풀링 설정을 하는 것이다.

위의 항목을 설정할 때, 전체 Bean의 개수를 고려하여 그 숫자를 상대

적으로 결정하여야 한다. <thread-pool>를 너무 작게 잡으면 CPU 사

용이 효율적이지 않게 된다. <thread-pool>를 너무 크게 잡으면 유저

요청이 많을 때, 시스템에 동시에 수행되는 thread가 많아져 스케쥴링

및 리소스 할당으로 인한 부하가 커져 전체적인 성능이 떨어질 수 있

으므로 설정값에 주의를 요한다.


<jeus-ejb-dd>

<module-info>

<module-name/>

</module-info>

<beanlist>

<container-managed>

<ejb-name>pkproduct</ejb-name>


<export-name>pkproductApp</export-name>

. . .

<bean-pool>

<pool-min>2</pool-min>

<pool-max>4</pool-max>

<resizing-period>600000</resizing-period>

</bean-pool>

<capacity>100000</capacity>

<connect-pool>




</connect-pool>

<thread-pool>



<pool-step>1</pool-step>


</thread-pool>

. . .

</container-managed>

</beanlist>

</jeus-ejb-dd>


InitCaching (Entity Bean Only) 데이터베이스의 특정 테이블의 모든 레코드가 빈번히 쓰이고, 그 크기

가 크지 않다면 jeus-ejb-dd_<모듈명>.xml 에 <init-caching> 옵션

을 true로 설정함으로써 성능을 향상시킬 수 있다.

Deploy가 끝난 후 요청이 들어올 때 해당하는 Entity Bean이 메모리에

존재하지 않는 경우 Container는 요청을 처리하기 전에 테이블의 레코

드를 Entity Bean에 로딩하는 작업을 한다. 이 옵션을 설정하면 모듈의

Deploy 시점에 테이블의 모든 레코드를 Entity Bean에 캐쉬함으로써,

실제 서비스를 수행할 때 데이터베이스의 데이터를 Entity Bean에 로

딩하는 작업을 없애 성능을 향상시킨다.


<jeus-ejb-dd>

<module-info />

<beanlist>

<container-managed>




. . . .

<init-caching>true</init-caching>

. . .


</beanlist>

</jeus-ejb-dd>

Fetch Size (Entity Bean Only) 데이터베이스 테이블의 레코드를 Entity Bean에 로딩할 필요가 있을

경우 JDBC Connection을 이용하여 데이터를 가져온다.

이 때 jeus-ejb-dd_<모듈명>.xml 파일에 <fetch-size>항목에 적절한

값을 설정하여 JDBC를 통해 한번에 가져오는 레코드의 크기를 결정할

수 있다. 이 수치를 적절히 설정하여 Throughput을 높힘으로써 성능을

향상시킬 수 있다.

보통의 경우 그 크기를 10으로 하는 것을 권장한다.



<jeus-ejb-dd>

<module-info />

<beanlist>

<container-managed>




. . . .

<fetch-size>10</fetch-size>

. . .


</beanlist>

</jeus-ejb-dd>

Home Method (Entity Bean Only) Entity Bean의 어떤 메쏘드가 특정 Bean 인스턴스에 해당하는 메쏘드

가 아니고, Bean의 공통적으로 쓰이는 성격이라면 이를 Home Method

로 만드는 것을 고려해 본다. 비즈니스 메쏘드를 Home Method로 만

들면 메쏘드 수행시 Container에서 EJBObject 할당 없이 Anonymous

Entity Bean을 할당하여 메쏘드를 수행함으로써 약간의 성능향상을 꾀

할 수 있다.


Method Classification (Entity Bean Only) Entity Bean의 비즈니스 메쏘드는 Persistence 측면에서 두가지 종류

로 나눌 수 있다. Entity Bean의 값을 변경시키는 메쏘드와 Entity

Bean의 값을 변경하지 않는 메쏘드가 그 두가지 종류이다. Entity

Bean의 값을 변경하지 않는 대표적인 경우가 Entity Bean의 값을 읽

는(Read Only) 메쏘드이다. jeus-ejb-dd_<모듈명>.xml 파일의<non-

modifying-methods> 항목에 메쏘드를 추가함으로써 Read Only 메쏘

드라고 명시할 수 있다.

한 트랜잭션이 끝나기 직전에, Container는 이 트랜잭션과 관련된 모든

Entity Bean을 조사하여 Read Only로 설정되지 않는 메쏘드가 한번이

상 수행된 Entity Bean에 대해서만 ejbStore() 메쏘드를 호출해 준다.

Entity Bean에 Read Only 메쏘드를 명확히 명시하여 데이터베이스에

불필요한 작업을 줄임으로써 성능을 높힐 수 있다.


<jeus-ejb-dd>

<module-info />

<beanlist>

<container-managed>




. . . .

<non-modifying-methods>

getDescription()

</non-modifying-methods>

<non-modifying-methods>

getPrice()

</non-modifying-methods>

. . .


</beanlist>

</jeus-ejb-dd>


ENGINE 타입타입타입타입 선택하기선택하기선택하기선택하기 (Entity Bean Only) Entity Bean 이 표현하는 데이터베이스의 테이블이 이용되는 형태를

파악하여 세가지 중 하나의 엔진타입 설정함으로써 시스템 성능을 높

힐 수 있다. 데이터 이용 형태를 파악할 때 아래의 사항을 고려하자.

동시접근 유저는 많은가?

데이터 읽기 위주의 작업이 많은가? 아니면 데이터 수정 작

업이 많은가?

데이터 접근 경합(Contention) 이 많은가?

트랜잭션 처리의 시간은 얼마나 되는가?

엔진 타입 선택시 위에서 열거한 사항들을 고려한다. 아래는 각 엔진

타입이 어느 경우에 적당한지를 설명하였다. EJB Bean 클러스터링을

하지 않는 경우는 EXCLUSIVE_ACCESS가 적당하다.

SINGLE_OBJECT와 MULTIPLE_OBJECT는 EJB Bean을 클러스터링

할 경우에만 의미가 있다.

EXCLUSIVE_ACCESS

데이터베이스 특정 테이블의 레코드를 시스템 내의 유일한 한 개

의 EJB Bean이 캐쉬하여 트랜잭션 시작시 EJB Bean의

ejbLoad() 작업을 줄임으로서 성능을 향상시키는 옵션이다.

동시접근 유저가 적은 경우면서, 데이터 캐쉬 기능을 최대한 활용

하여 빠르고 효율적인 시스템 구성을 원할 경우 이 옵션이 적당

하다.

SINGLE_OBJECT

EXCLUSIVE_ACCESS는 EJB Bean 인스턴스를 이용할 수 있는

트랜잭션이 특정 순간(Snapshot) 단 하나밖에 없어서 확장성

(Scalibility)에 문제가 있다. SINGLE_OBJECT는 동시접근 유저가

많아 EJB Bean 클러스터링을 구성하여 확장성(Scalibility)을 높이

려 할 경우에 적당하다. 데이터베이스 특정 테이블의 레코드를 시

스템 내의 클러스터링된 여러 개의 EJB Bean이 표현하고 있다.

그래서 트랜잭션 시작시 매번 ejbLoad() 작업을 해야 하므로 각

각의 트랜잭션 작업만을 보았을 때는 Access Path가 길어져

EXCLUSIVE_ACCESS에 비해서는 비효율적이다. 하지만 동시에

진행될 수 있는 트랜잭션 수을 높힐 수 있다.


MULTIPLE_OBJECT

이 옵션은 SINGLE_OBJECT와 같이 클러스터링을 이용하여 EJB

Bean을 구성하는 경우에 사용된다. 다른 점은 특정 레코드를 표

현하는 EJB Bean 인스턴스가 다른 트랜잭션에 할당된 상태에서

다른 트랜잭션이 같은 EJB Bean 인스턴스를 요구할 경우 동일

레코드를 표현하는 새로운 EJB Bean 인스턴스를 만들어 트랜잭

션에 할당하는 방법이다. 데이터 경합(Contention)이 많아 트랜잭

션이 동일한 데이터에 대한 Access가 많을 경우

SINGLE_OBJECT에 비해 Concurrency를 더 높힐 수 있다. 트랜

잭션 길이가 길어서 하나의 트랜잭션이 진행되는 동안 다른 트랜

잭션이 블록킹 되는 일이 많아지는 경우 이 옵션을 설정하여

Concurrency를 높이는 것이 좋다.

하지만 데이터에 대한 작업성격이 읽기보다는 주로 수정 작업이

라면 데이터베이스의 데이터 접근 경합(Contention)으로 인하여

Deadlock 상황이 발생할 수 있으므로 주의를 요한다.

SINGLE_OBJECT보다 더 복잡한 객체 관리가 요구되기 때문에

엔진 오버헤드가 크다는 것도 염두에 두어야 한다.

정리하자면 클러스터링 기능으로 Scalibility을 높혀야 하는데

SINGLE_OBJECT에 비해 동시에 처리되는 트랜잭션 수를 늘리려

할 경우, 동일한 데이터에 대한 읽기작업 많으면서 데이터 경합이

심한 상황이라면 이 옵션이 적당하다.


<jeus-ejb-dd>

<module-info>

<module-name/>

</module-info>

<beanlist>

<container-managed>




. . .

<engine-type>EXCLUSIVE_ACCESS</engine-type>

. . .


</beanlist>

</jeus-ejb-dd>


SUBENGINE 타입타입타입타입 선택하기선택하기선택하기선택하기 (CMP Bean Only) 이 옵션은 CMP에서만 사용될 수 있다.

Jeus-ejb-dd_<모듈명>.xml 파일의 <subengine-type>에 아래 두가지

옵션중 하나를 선택하여 넣을 수 있다. 업무성격을 파악하여 주된 데이

터 접근 방법을 알아내어 옵션을 선택하도록 한다.

ReadLocking

Bean의 성격이 Read 작업이 많은 경우 Shared Read를 허용하여

동시에 데이터에 Access할 수 있도록 한다. Read 작업이 많은 경

우 Concurrency를 높혀 성능을 향상시킬 수 있다.

WriteLocking

Bean의 성격이 Write 작업이 많은 경우 Lock Promotion 등으로

인한 Deadlock 상황을 방지해 줄 필요가 있다. Write작업이 많을

경우 데이터를 읽을 때, Write Lock을 잡고 작업을 진행하게 하여,

Concurrency는 낮추지만 Deadlock 발생빈도를 낮춤으로써 전체

적인 성능향상을 꾀할 수 있다.


<jeus-ejb-dd>

<module-info>

<module-name/>

</module-info>

<beanlist>

<container-managed>




. . .

<engine-type>SINGLE_OBJECT</engine-type>

<subengine-type>WriteLocking</subengine-type>

. . .


</beanlist>

</jeus-ejb-dd>


Note : 엔진 타입 및 서브엔진 타입 선택에 대한 기준을 시스템 성

격에 따라 아래 그림으로 표현하였다.

동시동시동시동시 접근접근접근접근 유저수유저수유저수유저수

Exclusive Access

데이터데이터데이터데이터 접근접근접근접근 경합경합경합경합 많다많다많다많다....

트랜잭션트랜잭션트랜잭션트랜잭션 시간시간시간시간 길다길다길다길다....

아니다아니다아니다아니다

Single Object

Read

locking

Write

locking

Multiple Object

Read

locking

Write

locking

작다작다작다작다 많다많다많다많다

그렇그렇그렇그렇다다다다

Read 가가가가 많다많다많다많다 Write가가가가 많다많다많다많다. Read 가가가가 많다많다많다많다 Write가가가가 많다많다많다많다.


Fast Deploy & EJBCompiler 이 방법은 이전의 튜닝옵션과 다르게 런타임 성능향상이 목적이 아니

고, Deploy과정을 단축시켜 부팅을 빠르게 하는 방법이다.

EJB 모듈로 구성된 시스템을 생각해 보자. 엔진이 부팅될 때 마다 EJB

모듈을 Deploy해야 되는데, 보통의 경우 EJBMain.xml의

<ModuleList>항목에 EJB 모듈을 추가하여 엔진이 부팅될 때, 모듈이

Deploy되도록 설정을 한다.

모듈이 Deploy되는 과정을 살펴보면, 먼저 EJB Object와 Home

Object 그리고 Skeleton, Stub등의 코드를 생성한 후 이를 컴파일 하

고, 이 모듈의 Container 인스턴스를 하나 만들어서 이를 EJBServer

에 등록하는 과정을 거치게 된다.

위의 모듈 Deploy과정은 최초 한번은 반드시 수행되어야 된다. 이를

이후에 다시 Deploy하는 데, 모듈 수정이 없는 경우(좀 더 정확히 말

하자면, Home과 Remote의 인터페이스가 변하지 않는 경우) Deploy

과정 중에서 EJB Object와 Home Object의 코드생성 및 컴파일 과정은

다시 할 필요가 없다.

이러한 경우 (모듈의 Deploy과정이 전체적으로 한번 수행되고, 그 이

후 Home과 Remote 인터페이스가 변하지 않는 경우) EJBMain.xml의

<FastDeploy>항목을 true로 설정하면 엔진은 EJB Object와 Home

Object의 코드생성 및 컴파일 과정을 생략하고 Deploy작업을 진행한

다.

<FastDeploy> 옵션은 실제로 시스템의 운영중 Performance에는 영향

을 미치지는 않는다. 하지만 운영중 엔진을 새로이 부팅시킬 필요가 있

을 때, 빠른 시간내에 모듈을 Deploy하여 엔진의 부팅시간을 단축시킬

수 있다. 특히 많은 EJB 모듈을 가지는 시스템의 경우 이 옵션의 사용

을 권장한다. 실제로 수 백개의 EJB 모듈로 구성된 시스템의 경우 부

팅작업은 상당히 오랜 시간동안 진행된다.

시스템을 운영하다 보면 특정 EJB 모듈을 수정할 상황이 발생한다. 이

경우 모듈을 수정하고 클래스를 컴파일한다. 그 다음으로 모듈의

Redeploy 작업이 필요하다. EJB 모듈의 수정작업에서 EJB모듈의

Home과 Remote의 인터페이스가 변했다면, Deploy 작업 중 EJB

Object와 Home Object의 코드생성 및 컴파일 과정이 반드시 이루어


져야 된다.

이런 경우 EJB 모듈의 Deploy에는 세가지 방법이 있다.

첫째, ejbadmin 을 사용하여 엔진을 내리지 않고 모듈을 undeploy한

후 다시 deploy하면 된다. Deploy시 –f (FastDeploy) 옵션을 사용하지

않아야 한다.

둘째, 엔진을 내리고 EJBMain.xml의 <FastDeploy> 옵션을 false로 하

여 부팅시 코드생성 및 컴파일 과정이 일어나도록 한다.

셋째, ejbcompiler를 이용해 EJB Object와 Home Object의 코드생성

및 컴파일과정을 거치게 하고 EJBMain.xml의 <FastDeploy> 옵션을

true로 설정하여 부팅을 한다.

첫번째 방법은 Runtime에 EJB 모듈을 Redeploy하는 방법이다. 두번째

와 세번째 방법은 다음 엔진 부팅시에 수정한 모듈의 Redeploy작업을

하는 방법이다.

다음 엔진 부팅시에 수정한 모듈의 Redeploy를 원할 경우 두번째 방

법은 비효율적이다. EJBCompiler를 이용하는 세번째 방법으로 부팅시

간을 단축하는 것이 더 효율적이다.

정리하자면 EJBCompiler는 EJB Object와 Home Object의 코드생성

및 컴파일과정을 수행하는 툴이다. 이를 이해하고 적절히 사용하면 부

팅시간을 단축시킬 수 있다.

EJBCompiler 사용법은 아래와 같다.

%JEUS_HOME%\bin\ejbcompiler

ejbcompiler command

usage : ejbcompiler

[engine name]

[modulename|modulename::beanname]

[options]

options

-xml : use ejb-jar-modulename.xml and jeus-ejb-

dd_modulename.xml as deployment descriptor

-v : verbose


VII. Servlet/JSP Tuning 본 장에서는 JEUS Servlet 엔진에서의 성능 향상을 위한 방법을 다루

어 보도록 하겠다.

앞으로 다룰 JEUS Servlet 엔진의 튜닝 방법 종류를 아래에 열거하였

다.

Session Routing

Handler Thread Pool

JSP Batch Compiler

Servlet/JSP Auto Reloading

Connection Pooling 관련

JDBC Connection Pool

WebT Connection Pool

WebServer와의 연결 관련

WebToB

Apache

Session Routing Servlet 표준의 Session은 세션정보를 웹 컨테이너가 관리해 주고

Cookie에는 단지 Session Key만이 실리게 되어 기존의 Cookie 방식

에 비해 네트웍 사용량을 크게 줄여 성능을 향상시킨다.

Session Routing 기법은 JEUS 웹 컨테이너의 웹 서버로서 WebToB나

Apache를 사용하고 웹 서버에 다수의 JEUS 웹 컨테이너가 클러스터

링 되었을 경우 사용할 수 있는 기법이다. 기본 알고리즘은 Apache

Web Server와 Jserv servlet engine 사이에서 제공하는 load

balancing 기법과 동일하다. 세션 객체를 최초로 생성한 JEUS 웹 컨테

이너는 session 구분자인 Cookie에 자신의 구분자(servlet engine


identifier)를 삽입한다. 웹 서버는 이 Cookie 값을 조사하여 세션 객체

가 생성된 JEUS 웹 컨테이너로 클라이언트 요청을 routing해 준다.

Session Routing 기법은 동일한 클라이언트가 같은 웹 컨테이너에서

서비스 되도록 하여 클러스터링된 웹 컨테이너간 통신량을 줄여준다.

아래는 container.xml 파일에 SessionRouting을 설정하는 예이다.

<DistributedSession SessionRouting="true">

<SessionServer ServerName="session1"

BackupServerName="session2"

InitCapacity="1"

MaxCapacity="3"

IncrementRate="1"

TimeoutMilliSec="10000">

</SessionServer>

</DistributedSession>

Note : <Failover에 관하여>

JEUS 시스템에서는 Web Container Cluster 내의 session

정보를 효율적으로 관리하고 Web Container간 load

balancing 및 failover 를 보장하기 위해 Session Manager

를 도입하였다. 하나의 Web Container 에서 session 이 생

성되면 해당 Web Container 는 이 session을 자신의

Session Cache 에 저장하고 설정된 Session Manager에게

session 정보를 전달한다. JEUS는 이러한 방법으로 특정엔

진이나 노드가 장애 발생했을 경우에도 세션을 유지시켜 준

다.


JDBC Connection Pooling JEUS에서 JDBC Connection Pool을 이용하는 방법은 두 가지가 있다.

JEUS 시스템에서 데이터베이스로의 connection 관리를 담당하는

JDBC 표준의 DB Connection Pool은 Naming & Directory 서버에 등

록되어 JEUS Cluster 어디에서는 접근 가능하고 JEUS Transaction

Manager와 연동하여 트랜잭션 관련 정보를 관리하는 등 다양한 기능

을 제공한다. 클라이언트가 이를 이용하기 위해서는 JeusMain.xml에

설정을 하고 JNDI API를 이용해 접근한다.

하지만 만약 어플리케이션이 HTML, Servlet, JSP 등으로만 구성된

presentation 중심의 구조에 간단한 데이터베이스 작업만을 수행한다

면 Web Container 전용의 Connection Pool을 사용할 수 있다. 이

Connection Pool은 JDBC 표준에서 제시하는 Connection Pooling 메

커니즘을 따르지 않고 보다 가볍고 간단한 구조를 사용하여 JEUS 시

스템의 무게를 줄이고, 불필요한 리소스의 낭비를 막는다. 클라이언트

가 이를 이용하기 위해서는 container.xml에 설정을 하고 JDBC

DriverManager로 로딩한 후 사용한다.

아래에 container.xml에 DB Connection Pool 설정 예를 보였다.

<DBConnectionPool ConnectionPoolID="sharedOraclePool"

ConnectionPoolType="shared"

ConnectionURL="jdbc:oracle:thin:@111.111.111.111:1521:ORA815

"

DriverClassName="oracle.jdbc.driver.OracleDriver"

ConnectionArguments="user=username;password=password"

CloseLongActiveConnection="true"

MaxActiveTimeSecs="60">

<DBPoolControl InitCapacity="2"

MaxCapacity="10"

IncrementRate="2"

MaxIdleTimeSecs="300"/>

</DBConnectionPool>


WebT Connection Pooling JEUS에서 WebT 라이브러리를 이용해 TMAX를 Access할 수 있다.

이럴 경우 JDBC Connection Pooling과 마찬가지 방법으로 TMAX와의

Connection을 풀링하여 이용할 수 있다. 이에 대한 장점은 JDBC

Connection Pooling과 같다.

아래에 container.xml에 있는 WebT Connection Pooling 설정 예를 보

였다.

<WebtConnectionPool

LogLevel=”info”

LogFileName=”c:\jeus30\logs\webt.log”>

<WebtConnectionGroup

ConnectionGroupID=”tmax1”

TmaxAddress=”111.111.111.1”

TmaxPort=”8888”

InitCapacity=”10”

MaxCapacity=”40”

IncrementRate=”2”/>

<WebtConnectionGroup

ConnectionGroupID=”tmax2”

TmaxAddress=”111.111.111.2”

TmaxPort=”8888”

InitCapacity=”10”

MaxCapacity=”40”

IncrementRate=”2”/>

</WebtConnectionPool>

Servlet/JSP Auto Reloading 실제 WEB-BASED 시스템을 운영하다 보면 프리젠테이션이나 비즈니

스 로직을 수정할 경우가 발생한다. 이럴 경우 특정 모듈에 수정을 가

하고 엔진을 리부팅하는 것은 시스템의 Availibility측면에서 바람직하

지 않다. JEUS는 Servlet/JSP Auto Reloading기능을 제공하여 모듈 수

정시 엔진 리부팅을 하지 않고 해당 모듈이 속해 있는 Context만 다시

Reload를 하게 할 수 있다. 모듈이 있는 디렉토리 밑에 있는 하위 모

든 디렉토리를 모니터링하는 쓰레드가 있어 모듈 수정으로 인한 파일

의 변경이 일어났는지를 감시하고, 변경이 있다면 해당 Context를 다

시 Reload한다. 이 기능은 모듈 수정이 빈번한 경우 매우 유용한 기능

이다.

하지만 Auto Reloading을 위한 디렉토리의 파일 감시 작업도 엔진에는


오버헤드가 된다. 시스템의 수정이 없는 경우라면, 그리고 안정되고 빠

르게 운영하려 한다면 Auto Reloading을 위한 오버헤드를 없애주는 것

이 성능향상에 도움이 될 것이다.

이러한 경우 Container.xml을 아래와 같이 설정하여 Auto Reloading

기능을 사용하지 않게 할 수 있다.

<Container MonitoringIntval="300"

SessionMonitoringIntval="120"

RedirectStdOut="true"

RedirectStdErr="true">

<ContextGroup GroupName="MyGroup"

GroupDocBase="webapps"

SharedSession="true"

SessionTimeoutMinute="20"

PrintErrorToBrowser="true">

. . . .

<Context ContextName="Examples"

ContextPath="/examples"

DocBase="examples"

EnableJSP="true"

AutoReload="false">

</Context>

. . . .

</ContextGroup>

</Container>


JSP Batch Compiler 개발자가 JSP파일을 작성하고 이 JSP파일을 실제 운영 시스템에

Deploy했다고 하자. Servlet 엔진은 최초 이 JSP로의 요청이 있을 때

이 JSP파일을 파싱하고 이를 Servlet코드로 바꾸어 준다. 그 다음

Servlet코드를 컴파일하고 이를 클래스로더가 로딩하게 한 후 인스턴

스를 하나 만들고 service() 메쏘드를 실행시킨다. 이후 두번째 요청부

터는 만들어진 인스턴스의 service() 메쏘드를 부르기만 하면 된다.

위에서 보듯이 JSP의 최초 서비스 절차는 상당히 많은 절차를 거치기

때문에 클라이언트 입장에서는 비교적 긴 시간을 기다려야 결과를 볼

수가 있다. 만일 JSP의 수정이 빈번하거나 그 양이 많다면, 위에서 언

급한 절차가 엔진에 오버헤드를 줄 뿐 아니라 클라이언트 응답시간도

길어진다.

JEUS는 JSP Batch Compiler를 제공하여 JSP파싱, Serlvet코드 생성

그리고 생성된 코드 컴파일 과정을 미리 작업하도록 하여, JSP로의 최

초 요청시 엔진 오버헤드 방지 및 성능 개선을 하도록 하였다.

JSP Batch Compiler는 ContextGroup 또는 Context 단위로 해당 단위

내에 있는 JSP파일을 Servlet 클래스 파일 형태로 만들어 준다.

아래 JSP Batch Compiler의 사용법을 간략히 적어 놓았다.

%JEUS_HOME%\bin\jspc

JEUS Web Container version: 3.0.0

jspc -e engine_name [-g grpname [-c ctxname]] [-noxml]

[-f container_xml_path]

- pre-compile the jsp files of context ctxname of

contextGroup grpname

- if ctxname omitted, entire contexts of grpname will be

pre-compiled

- if ctxname and grpname omitted, entire contexts of

engine_name will be pre-compiled

-noxml configuration by .conf file

-g context group name to compile

-c context name to compile

-f config_file configuration file name

-h this message

-v version information


WebServer와의와의와의와의 연결연결연결연결 JEUS의 Web Service는 HTTP요청을 WebServer에서 받고 이를 파싱

하여 Servlet이나 JSP 요청의 경우 JEUS의 Web Container에 넘겨주

는 구조로 되어 있다. 많은 유저를 빠르고 효율적이게 처리하기 위하여

JEUS는 크게 두 가지의 아키텍쳐를 수용하고 있다.

첫쨰, ThreadPool을 사용하여 클라이언트 요청이 들어왔을 때, 매번

새로운 쓰래드 생성 오버헤드를 줄이고 쓰래드를 재사용하게 하였다.

ThreadPool 크기의 설정은 Web Container의 성능에 매우 영향이 크

다.

둘째, WebServer와 Web Container사이에 Queue를 두어서

ThreadPool에서 당장 처리할 수 없는 클라이언트 요청을 잠시 Queue

에 두고 쓰레드가 ThreadPool에 반환되는 시점에 처리가 되도록 하였

다. 이렇게 함으로써 동시에 많은 클라이언트 요청을 수용하여

Availibility를 높혔다. 앞에서 설명한 OS의 TCP레벨에서도 Backlog

크기를 늘려주는 작업도 같은 목적으로 하는 설정이다. 이 두 가지의

설정을 동시에 고려해 주어야 하겠다.


JEUS에서 사용할 수 있는 HttpServer는 크게 세가지가 있다. 각각의

경우에 대하여 간단한 설정 예를 아래에 보였다.

JEUS에 내장된 HttpServer와의 연결

<Connection ListenerType="HttpListener"

Port="8088"

ServerAccessControl="false">

<ThreadPool

MinThread="2"

MaxThread="10"

ChangeRate="2"

MaxIdleTime="300"

MaxWaitQueue="4" />

</Connection>

Apache Server와의 연결

<Connection ListenerType="ApacheListener"

Port="8007"


<ThreadPool

MinThread="2"

MaxThread="10"

ChangeRate="2"

MaxIdleTime="300"

MaxWaitQueue="4" />

</Connection>

WebToB와의 연결

<Connection ListenerType="WebtobListener"

Port="9900"

WebServerAddress="111.111.111.111"

ConnectionPortNum="2"


<ThreadPool

MinThread="10"

MaxThread="10"

ChangeRate="2"

MaxIdleTime="300"

MaxWaitQueue="4" />

</Connection>


VIII. JEUS Application Tuning 이제까지 시스템의 성능을 향상시키기 위한 OS, Network, JVM 튜능

방법 및 JEUS 엔진 튜닝 방법에 관하여 다루었다. 여기에 추가하여

Application 튜닝도 빠질 수 없는 부분이다. Application이 성능을 고려

하여 만들어지지 않았다면 위에서 언급한 모든 부분을 모두 고려하였

다 할지라도 시스템의 성능이 어떻게 나올 지는 뻔한 일이다.

Application 튜닝에 관련된 부분은 본 문서에서 다루기에는 그 범위가

너무 넓고 다양해서 구체적으로 다루지는 않겠다. 개략적인 몇 가지 만

을 다루고자 하므로 이외의 내용은 관련 문서를 참조하기 바란다.

Application 디자인 과정부터 성능을 생각하라.

Application 튜닝은 개발이 모두 끝나고 나서 하는 것만이 아니다.

디자인부터 잘못된 Application은 시스템에 치명적인 bottleneck

이 될 수 있을 뿐 아니라 쉽게 고치기도 어렵다. 복잡한 코딩으로

성능을 향상시킬 수 있는 경우보다도 간단한 디자인 하나가 성능

을 놀랄 만큼 향상시키는 예를 많이 볼 수 있다. 디자인 단계부터

성능을 생각하라.

Design Pattern을 적용하라.

Design Pattern이란 시스템 디자인 시에 자주 발생하는 문제들에

대한 ‘재사용 가능한 해결책’이라 할 수 있다. 이는 경험 많은 소

프트웨어 엔지니어들로부터 동일한 해법들을 이름을 부여하고 디

자인을 추상적으로 정리한 것이다. 이미 검증되고 적용한 사례가

많은 것이므로 이를 이용하는 것은 극히 추천할 만 하다. 엔지니

어 입장에서는 효율적이고 유용성이 좋은 디자인에 대한 해법을

짧은 시간에 익히고 얻어 이를 적용하면 자신이 디자인 하고 있

는 시스템의 안정성과 성능을 높일 수 있다.

Design Pattern에는 성능에 크게 도움을 주는 내용도 많이 있다.

특히 근래에는 J2EE아키텍쳐에서 적용할 수 있는 J2EE Pattern

들이 많이 나오고 있다. 예를 들어 모듈간의 통신시 데이터를

Coarse-Grained 하게 주고 받아 Network Traffic을 줄인다든지,

Bean간의 Coupling이 높은 경우에 Dependent Object를 고려하

여 디자인 한다든지, 비동기적(Asynchronous)으로 작업이 가능한


경우 Message-Driven Bean Façade를 사용한다 등등… 성능향

상에 도움이 되는 검증된 디자인이 많이 있다.

단지 성능 뿐 아니라 유지보수를 위해서 그리고 확장성 및 재사

용을 위해서 Design Pattern의 적용을 적극 활용하라.

J2EE Architecture를 이해하라.

너무도 당연한 이야기 이겠지만 Servlet 아키텍처를 충분히 이해

하지 않고 Servlet을 작성하는 것, EJB 아키텍처를 충분히 이해하

지 않고 EJB Bean을 작성하는 것은 상당한 위험한 일이 아닐 수

없다. 예를 들어 Servlet을 작성하는 데 Thread Safty를 제어하

는 일을 SingleThreadModel을 이용하여 처리한다면 Thread

Safty는 확실히 지켜지겠지만 성능은 매우 낮게 나올 것이다. EJB

작성시 Stateless Bean으로 작성해도 되는 일을 Stateful Bean

으로 작성하거나 Entity Bean으로 작성하면 불필요한 리소스 낭

비가 되고 낮은 성능을 낼 것이다. 원래의 J2EE 아키텍쳐가 지향

하는 바를 제대로 이해하지 못하고 이를 이용하면 효율적인 시스

템이 구축되지 않을 것이다.

데이터베이스 SQL 튜닝을 고려하라.

시스템 구축시 데이터베이스를 사용하는 경우는 비일비재하다. 데

이터베이스를 Access하는 Application의 경우 Table 디자인을

어떻게 하는가, Index를 어떻게 만드는가, SQL문장을 어떻게 작성

하는가에 따라 엄청난 속도 차이를 보이는 상황을 자주 볼 수 있

다. 데이터베이스 그리고 SQL의 데이터베이스내 처리과정등의 이

해가 깊어질수록 성능이 좋은 시스템을 구축할 수 있다.

J2EE 아키텍쳐에는 효율적인 리소스 관리, Concurrency관리, 트랜잭션

관리 등 성능을 위한 뛰어난 개념들이 많이 있다. 그리고 JEUS는 이

J2EE 아키텍쳐를 수용하고 또 추가적인 많은 성능 향상 관련 기능들을

제공하고 있다. 하지만 J2EE 아키텍쳐 그리고 JEUS는 요술방망이가

아니다. 이 Platform위에 올라가는 Application을 어떻게 작성하는가?

그리고 시스템이 운용되는 환경을 어떻게 구성해 주어야 하는가? 라는

질문에 대한 답은 넓은 부분에 있다는 것을 알 수 있었다. 다양한 튜닝

포인트를 고려하고 이를 위한 꾸준한 노력을 할수록 효율적이고 빠른

시스템을 얻을 수 있을 것이다.

Documents

5Jeus Performance Tuning-cover - TmaxSoft · 2019-04-09 · JEUS Performance Tuning 7 5) 슬로우 스타트 슬로우 스타트는 수신측이 최대 처리할 수 있는 데이터