performance issues in jeus - tmaxsoftkr.tmaxsoft.com/img/service/pdf/form/performance_issues... ·...

WhitepaperWhitepaperWhitepaperWhitepaper

Performance Issues

in JEUS

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

Performance Issues in JEUS 1

Contents

1 I.Performance Improvement........................................................................................... 2

Local Method Invocation Optimization........................................................................... 2

Local Transaction Optimization...................................................................................... 4

Data Modification Detection in a Transaction ............................................................... 5

Adaptive Management in JNDI ....................................................................................... 6

Session Manager for Web Container ............................................................................. 7

Engine Mapping on JVM ............................................................................................... 10

WebtoB Connector ........................................................................................................ 11

Exclusive Access in EJB Engine .................................................................................. 11

2 II. Configurability .......................................................................................................... 12

Light Weight Connection Pool in Web Container ........................................................ 12

Various Engine Models in EJB Engine......................................................................... 13

1) EXCLUSIVE_ACCESS........................................................................................ 13

2) SINGLE_OBJECT ............................................................................................... 15

3) MULTIPLE_OBJECT.......................................................................................... 16

Data Locking in EJB Engine ......................................................................................... 19


I.Performance Improvement JEUS는 전체시스템의 성능을 향상시킬 수 있도록 다양한 최적화 기법

을 제공한다.

Local Method Invocation Optimization J2EE 플랫폼에서 business 로직은 EJB를 기반으로 구현되고, EJB

Container 에 의하여 운영된다. JEUS 에서는 두 로직의 상대적 위치에

따라 최적의 메커니즘을 선택하여 통신이 이루어 지도록 한다.

두 로직이 서로 다른 물리적 노드에 존재

소켓통신이 가장 적당하다. 고성능의 물리적 네트웍을 적용하거나 네트

웍으로의 빠른 접근이 가능한 API를 적용하여 성능을 높일 수도 있지

만 이것은 모든 J2EE WAS 에 공통적으로 적용될 수 있는 사항이므로

이 문서의 논의 대상이 아니다.

두 로직이 같은 물리적 노드 내에 서로 다른 프로세스에서 동작

중일 때

위의 경우에서처럼 소켓을 사용할 수도 있고, OS 에서 제공하는

IPC(Inter-Process Communication)를 사용할 수도 있다. 대표적인

IPC 로는 PIPE 가 있다. JEUS 개발팀의 자체 측정에 의하면 OS 에

따라 조금씩 차이가 있기는 하지만 PIPE 는 소켓을 사용하였을 때보

다 2 – 3 배 정도 빠르다. JEUS 에서는 두 개의 로직이 같은 노드에

있는 경우에는 이것을 자동으로 감지하여 PIPE 로 처리하여 성능을

향상 시킨다. 이 경우 소켓을 사용하였을 때의 많은 오버헤드가 제거

된다.

두 로직이 같은 물리적 노드 내의 같은 프로세스에 존재할 때

소켓과 PIPE 의 사용이 물론 가능하지만 최적은 Call-By-Value로

처리되는 method invocation을 이용하는 것이다. 소켓이나 PIPE 와


같은 IPC를 사용하면 자체로도 많은 추가 작업을 하여야 하고, OS 시

스템내의 코드를 사용하게 되어 OS 코드로 들어가기 위한 추가 오버

헤드를 감수 하여야 한다. Method invocation은 오직 어플리케이션 코

드에 의해 동작하여 그 성능이 IPC 를 사용하였을 때보다 훨씬 빠르

다. 구체적인 성능차이는 통신상의 데이터 양에 따라 크게 다르다.

두 로직이 같은 물리적 노드 내의 같은 프로세스에 존재하며,

Call-By-Value semantics 를 요구하지 않을 때

method invocation시에 argument와 return value 가 오고 가게 되는

데 EJB 통신 메커니즘의 기본이 되는 RMI(Remote Method

Invocation) 표준에서는 Call-By-Value 로 이것을 처리하도록 하고

있다. 즉 두 로직의 통신에 method invocation이 사용된다 하더라도

invocation 시에 argument와 return value 가 모두 copy가 되어 건내

져야 한다는 것이다. JEUS 에서는 시스템 관리자가 특정 EJB Bean

에 대해 Call-By-Reference semantics 가 적용될 수 있다는 설정을

하면 다른 로직이 이 EJB Bean 에 접근하였을 때 두 로직이 같은 노

드의 같은 프로세스에 있을 경우 Call-By-Reference sementics를 적

용하여 argument와 return value 를 이동시킨다. 이 경우 argument

와 return value 의 copy 오버헤드가 사라져 최적의 통신이 가능하여

최상의 성능향상을 얻을 수 있다.


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

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

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

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

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

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

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

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

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

리 영역을 벋어나지 않는 것이 보통이다.

(하나의 JEUS Transaction Manager 는 하나의 JVM을 관리영역으로

한다)

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

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

트랜잭션 수행을 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 처리가 훨씬 간단하고 효율적으로 구현될 수 있으며 이

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

Data Modification Detection in a Transaction EJB Container 에서는 하나의 EBJ Bean 에 대해 진행된 method

invocation의 history를 관리한다. 이 history는 트랜잭션 하나당 따로

관리되며 트랜잭션이 종료되면 삭제된다. EJB Container 는 이 history

를 Entity Bean 운영시 데이터베이스로의 통신량을 줄이는데 사용한다.

EJB Container 는 하나의 트랜잭션의 commit 시점에서 트랜잭션 진행

중 수정되었던 내용이 데이터베이스에 적용될 수 있도록 SQL 명령을

수행한다. EJB Container 는 트랜잭션 진행 중에 호출된 method의

history 정보를 토대로 내용을 수정하는 method가 호출된 적이 없으면

수정사항이 없는 것이므로 SQL 명령을 수행하지 않는다. 수정작업이

없는 method 의 리스트는 시스템 운영자의 설정으로부터 얻는다.


Adaptive Management in JNDI JEUS 가 운영중인 모든 노드에는 JNDI Server 가 하나씩 운영되어 해

당 노드에 대한 모든 Naming & Directory 정보를 관리한다. 각 JVM

에는 JNDI Client 가 존재하여 각 JVM의 정보를 관리하며 JVM 영역

밖의 정보도 일부 관리된다. JEUS Cluster 내의 JNDI Server들은

booting 시에 서로 연결 망을 형성하여 Cluster 내의 정보를 관리한다.

시스템의 규모가 클수록 더 많은 로직과 리소스가 사용되며 이들에 대

한 정보를 관리하는 JNDI Server, JNDI Client 의 효율적인 정보 관리

는 전체 시스템 성능 향상의 필수적 요소이다.

정보의 propagation 범위 관리

JEUS는 Naming & Directory 정보 등록시에 정보의 propagation

범위를 선택하여 줄 수 있다. JVM 내에서만 사용될 정보로 선언

하면 JVM 내에서 JNDI Client 에 의해서만 관리된다. 해당 노드

에서만 사용될 정보로 선언하면 해당 노드의 JNDI Server와

JNDI Client 가 관리한다. JEUS Cluster 어디서든 접근 가능하여

야 할 정보이면 JNDI Server 모두에게 복사된다.

Caching

JEUS Client는 클라이언트가 찾아오도록 요청한 객체를 자신의

저장 공간에 Caching하여 자주 사용되는 객체를 클라이언트가 빠

르게 찾을 수 있도록 한다. JEUS Client 는 cache를 효율적으로

관리하여 외부로부터 전달되어진 정보를 최적으로 관리한다.

정보 트리 관리의 용이함

정보의 등록과 삭제 시에 정보 트리상의 중간 정보들을 자동으로

생성 및 삭제해주어 어플리케이션의 정보 트리 관리를 용이하도

록 한다.

Container에 의한 효율적 정보 관리

어플리케이션 deploy 시에 많은 Naming & Directory 정보가 등


록되게 되는데 이러한 등록 정보의 성격을 Container 들이 자동

으로 분석하여 최적의 propagation 범위를 결정하여 등록하여 준

다.

Session Manager for Web Container WWW를 기반의 서비스가 다양해지고 복잡해짐에 따라 하나의 클라이

언트에 대한 session 정보 유지의 필요성이 대두되었다. Servlet 표준

의 Session은 session 정보를 Web Container 가 관리하여 주고

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

에 비해 네트웍 사용량을 크게 줄일 수 있다. 대규모 서비스 시스템의

경우 복수 개의 Web Container를 clustering 하여 사용하는 것이 보통

인데 이 경우 clustering 된 Web Container 간에 session 정보가 공유

되어 Cluster 내에서 session 정보가 깨지는 일이 없어야 한다.

JEUS 시스템에서는 Web Container Cluster 내의 session 정보를 효

율적으로 관리하고 Web Container간 load balancing 및 failover 를

보장하기 위해 Session Manager 를 도입하였다. 하나의 Web

Container 에서 session 이 생성되면 해당 Web Container 는 session

을 자신의 Session Cache 에 저장하고 설정된 Session Manager에게

session 정보를 전달한다. 클라이언트의 요청에 대한 처리가 끝나면

Cookie에 Session Key와 해당 Web Container 의 정보를 붙여 응답을

전송한다. 클라이언트가 다시 Web Container Cluster 에 접근하면,

Web Server 단에서 Cookie에 포함된 Web Container의 정보가 해석

되어 session 을 생성하였던 Web Container 에게 클라이언트 요청이

전달된다. Web Container 정보 분석 작업은 당사의 Web Server 제품

인 WebToB일 경우는 엔진 내에서, Apache 와 연동하였을 경우는

Apache 모듈에서 이루어진다. 클라이언트의 요청을 전달 받은 Web

Container는 Session Key를 이용하여 자신의 Session Cache로부터

session 정보 찾아내어 session 정보를 유지하게 된다.


Primary

Session

Manager

Backup

Session

Manager

Web

Server

Web

Container 1

Web

Container 2

session key 5

session object

Buffered backup

session key 5

container ID 2

Primary

Session

Manager

Web

Server

Web

Container 1

Web

Container 2

session key 5

container ID 2

Primary

Session

Manager

Web

Server

Web

Container 1

Web

Container 2

session key 5

container ID 1

No information

session key 5 session object

Primary

Session

Manager

Web

Server

Web

Container 1

Web

Container 2

session key 5

container ID 2

session key 5

container ID 2

Session Cache Hit

At Web Container 2

NextNextNextNext

accessaccessaccessaccess

FailureFailureFailureFailure

At Web Container 2At Web Container 2At Web Container 2At Web Container 2

failoverfailoverfailoverfailover


Session Manager 가 관리해 주어야 할 session 정보가 많을 경우

session 정보가 메모리에 계속 누적되면 메모리 리소스 소모가 심해진

다. 보다 효율적인 메모리 관리를 위하여 JEUS Session Manager 는

passivation 과 Auto-Removal 메커니즘을 사용한다. Session의 마지

막 사용이후 passivation timeout 동안 사용하지 않으면 이 session 정

보는 file로 옮겨지게 되며, 사용 요청이 있을 때 다시 메모리 상으로

올라온다. Session이 auto-removal timeout 까지도 사용되지 않으면

해당 session 정보는 Session Manager 로부터 자동 삭제된다.

Web Container Cluster 중의 한 Web Container 에 failure 가 발생하

면 Cluster 내의 임의의 Web Container로 클라이언트 요청이 redirect

된다. 요청을 받은 Web Container의 Session Cache 에는 해당

session 정보가 없으므로 Web Container는 Session Manager로부터

session 정보를 가져오게 된다. 이 정보는 Session Cache 에 저장되고

Cookie의 Web Container 정보가 수정되어 이후의 session 정보 관리

는 이 Web Container 가 담당하게 된다. (앞장의 그림 참조)

Session Manager 에도 failure 가 발생할 수 있다. 이를 위해 JEUS

에서는 Session Manager 의 backup 설정 기능이 있다. Backup 이 설

정되어 있으면 Session Manager는 Web Container 로부터 전달되는

모든 session 정보를 backup Session Manager 에게도 buffering 하여

전달한다. 이 backup Session Manager는 Web Container 에도 설정되

어 primary Session Manager로의 접근이 실패할 경우 backup

Session Manager로의 접근을 시도한다.


Engine Mapping on JVM JEUS 시스템은 어플리케이션의 운영을 담당하는 Web Container, EJB

Container, JMS Container 가 동작할 JVM을 관리자가 자유로이 설정

할 수 있도록 한다. 이것은 어플리케이션의 성능 및 리소스 관리 차원

에서 매우 중요하다. Web Container와 EJB Container 가 하나의 JVM

에서 동작하도록 설정하면 Servlet 과 EJB Bean를 기반으로 개발된

서비스의 경우 Servlet과 EJB Bean 간 통신이 Call-By-Reference 로

이루어질 수 있어 Web Container와 EJB Container가 서로 다른 JVM

에서 동작할 때보다 엄청난 성능 향상 효과를 볼 수 있다. 이러한 장점

은 JMS Server 와 EJB Container 가 하나의 JVM 에서 동작할 경우도

마찬가지로 JMS Server로부터 메시지를 받아 동작하게 되는

Message-Driven EJB Bean의 경우 메시지 교환이 method invocation

으로 이루어 질 수 있다. 또한 Engine 들을 하나의 JVM 에서 구동함

으로써 JVM의 기본 오버헤드가 줄어들며 Transaction Manager,

Scheduler등 JEUS 시스템 모듈을 같이 사용하게 되어 리소스 사용량

을 더욱 줄일 수 있다.

JEUS 에서는 모든 모듈이 하나의 JVM 에서 동작하도록 하는 옵션도

제공하는데 이것은 debugging을 보다 쉽게 하기 위한 것이다. 어플리

케이션이 복수 개의 JVM 에 분산된 환경에서의 debugging이 복잡할

뿐 아니라, multi-process 환경에서의 debugging을 지원하는

debugger를 구매하여야 하는 어려움이 따른다. 이 옵션은 오직 개발

단계에서만 사용하도록 권장한다. 실제 시스템 운영 중에는 예상치 못

한 failure 가 발생할 수 있고, 모든 모듈이 하나의 JVM 에 있으면

failure 가 모든 모듈로 전파될 수 있기 때문이다.


WebtoB Connector WebtoB는 JEUS의 Web Server 단을 담당하는 모듈로 C/C++ 로 구

현되었다. 이 모듈은 TmaxSoft의 Web Server 제품인 WebtoB를

JEUSdml 기능 요구사항에 맞추어 최적화하여 가볍고 빠르다. WebtoB

와 Web Container의 연결을 담당하는 WebtoB Connector는 클라이언

트 요청량을 감시하여 Web Container 로의 connection 수와 Web

Container의 서비스 처리를 위한 쓰레드의 수를 증가 또는 감소 시켜

최적의 연동 상태를 유지하도록 한다. 통신에 사용되는 프로토콜 또한

대용량 클라이언트 요청 처리에 용이하도록 설계되었다.

Exclusive Access in EJB Engine EJB 표준에 정의된 Entity Bean 은 Persistent Storage(실제로는 대부

분 데이터베이스) 에 존재하는 데이터를 EJB Bean 의 필드와 매핑시켜

객체상태로 접근이 가능하도록 해준다. EJB Container는 Entity Bean

에 대한 트랜잭션 시작 시에 객체 필드 값을 Persistent Storage의 값

으로 update하고 트랜잭션 종료시에는 수정된 필드 값을 Persistent

Storage 에 update 하여야 한다. 트랜잭션 완료 후 새로운 트랜잭션이

시작되면 해당 EJB Bean의 필드 값들을 다시 update 하여야 하는데

이것은 Cluster 된 다른 EJB Container 에 존재하는 EJB Bean, 또는

Persistent Storage에 접근할 수 있는 다른 수단들에 의해 Persistent

Storage 상의 값이 바뀌어 있을 수 있기 때문이다.

JEUS EJB Container는 EJB Container 하나가 Persistent Storage 에

대한 접근 권한을 모두 가지는 Exclusive Access 엔진 모델을 제공한

다. 이 경우 모든 데이터변경 작업은 이 EJB Container가 관리하는

EJB Bean에 의해 이루어져 EJB Bean의 필드 값이 Persistent

Storage의 값보다 항상 최신이다. 이 경우 트랜잭션의 시작 시에도

EJB Bean의 값이 항상 최신이므로 Persistent Storage 로부터 값을

읽어들이는 작업을 하지 않아도 된다. 만약 Persistent Storage가 데이

터베이스일 경우 트랜잭션 시작과 종료시에 각각 SQL 명령을 수행하

게 되는데 Exclusive Access 의 경우는 트랜잭션 시작시에 SQL 명령

을 수행하지 않게 되어 SQL 명령 수행 수가 절반으로 줄어들어 성능

을 크게 향상시키게 된다.


II. Configurability JEUS는 어플리케이션 구성 및 특성에 따라 시스템을 최적화 할 수 있

는 다양한 기능을 제공한다. 앞에서 설명된 Performance Improve-

ment를 위한 기능들 외에도 어플리케이션에 맞추어 JEUS 시스템을 재

구성하여 성능 개선의 효과를 볼 수 있다.

Light Weight Connection Pool in Web Container

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

JDBC 표준의 데이터베이스 Connection Pool은 Naming & Directory

서버에 등록되어 JEUS Cluster내에서는 어디에서든 접근이 가능하고

JEUS Transaction Manager와 연동하여 트랜잭션 관련 정보를 관리하

는 등 다양한 기능을 제공한다. 하지만 만약 어플리케이션이 HTML,

Servlet, JSP 등으로만 구성된 presentation 중심의 구조에 간단한 데

이터베이스 작업만을 수행한다면 Web Container 전용의 Connection

Pool을 사용할 수 있다. 이 Connection Pool은 JDBC 표준에서 제시하

는 Connection Pooling 메커니즘을 따르지 않고 보다 가볍고 간단한

구조를 사용하여 JEUS 시스템의 무게를 줄이고, 불필요한 리소스의 낭

비를 막는다.


Various Engine Models in EJB Engine JEUS의 EJB Container는 EXCLUSIVE_ACCESS, SINGLE_OBJECT,

MULTIPLE_OBJECT의 세가지 엔진 모델을 제공하여 시스템 운영자가

어플리케이션 특성에 맞추어 최적의 엔진 모델을 선택할 수 있도록 한

다. 각 엔진 모델은 Concurrent Access 를 누가 담당하느냐에 따라 구

분될 수 있다. EXCLUSIVE_ACCESS 에서는 EJB Container가

Concurrent Access 관리를 담당하고, MULTIPLE_OBJECT 에서는

데이터베이스, SINGLE_OBJECT 에서는 EJB Container와 데이터베이

스가 함께 Concurrent Access 관련 작업을 한다.

1) EXCLUSIVE_ACCESS 데이터베이스의 데이터에 대한 접근 권한을 EJB Container 하나가 독

점한다. 해당 데이터에 대한 모든 수정은 EJB Container 가 관리하는

EJB Bean의 필드 값을 수정하는 방법으로만 가능하다. 모든 수정 작업

이 EJB Bean을 통해서만 이루어지므로 EJB Bean의 필드 값이 데이터

베이스 내의 값보다 최신의 값이어서 EJB Bean이 데이터베이스의

cache 역할을 수행하게 된다. 하나의 데이터에 대해 복수 개의 트랜잭

션이 진행될 경우에는 EJB Container는 이 중 하나 만을 진행시키고

나머지는 block 시켜 EJB Bean 이 항상 독점적으로 사용될 수 있도록

한다.

EJB Container는 기본적으로 EJB Bean 의 값과 데이터베이스 값의 일

관성을 유지하기 위하여 트랜잭션의 시작 시에 데이터베이스로부터 값

을 읽어 오고, 종료 시에 EJB Bean의 필드 값을 데이터베이스에 기록

한다. 그러나 EXCLUSIVE_ACCESS 모델에서는 EJB Bean의 값이 항

상 최신이므로 트랜잭션 시작 시에 데이터베이스로부터 값을 읽어 들

일 필요가 없어 일관성 유지를 위해 사용되는 SQL 명령 수를 절반 가

까이 줄여 성능을 크게 향상 시킬 수 있다.

데이터베이스의 데이터에 대한 접근 권한을 독점한다는 가정은 두 가

지 큰 제약을 가진다. 하나는 EXCLUSIVE_ACCESS 모델은 EJB Bean

의 특성이 ReadOnly 가 아닐 경우 EJB Container Cluster 를 사용할

수 없다는 것이다. 다른 하나는 시스템 관리자가 데이터베이스에서 제

공되는 툴등을 이용하여 데이터 내용을 직접 수정한다 하여도 EJB

Container가 값을 읽어 주지를 않으므로 반영이 되지않는다는 것이다.

데이터베이스의 데이터는 오직 데이터가 최초로 EJB Container에 올라


오게 될 때만 읽힌다. 그러므로 직접 수정한 내용이 EJB Bean 에 반영

되려면 EJB Bean을 remove 하거나 EJB Container를 restart 시킨 후

수정하여야 한다.

EXCLUSIVE_ACCESS는 EJB Container가 수행하는 SQL 명령 수를

줄여 성능을 크게 올려주므로 이를 최대한 활용할 것을 권장한다.

EXCLUVISE_ACCESS 모델이 적합한 어플리케이션 시스템의 특징은

다음과 같다.

EJB Container Cluster를 사용하지 않아도 되는 경우

어플리케이션 시스템이 지원해주어야 할 동시 사용자 수가 많지 않거

나 한 머신 내에 CPU와 메모리가 충분하여 native thread 를 이용하

여 Clustering 된 시스템에 준하는 성능을 낼 수 있는 경우이다.

EJB 어플리케이션이 Read-Only 특성일 경우

수정이 없으므로 EJB Container Cluster 도 가능하다. EJB Container

가 데이터베이스와의 데이터 일관성 유지를 위한 SQL 명령들을 전혀

사용하지 않게 된다.

EJB Container이외의 경로로 자주 데이터를 수정하지 않는 경우

어플리케이션 설계 시부터 데이터 수정을 위한 충분한 서비스가 준비

되어 있어 시스템 관리자가 별도의 툴로 데이터에 접근할 필요가 없는

경우이다.

Client 1

Client 2

Client n Engine 1

E


2) SINGLE_OBJECT 하나의 EJB Container로 접근한 클라이언트 간의 concurrent access

는 EJB Container 가 담당하고, EJB Container Cluster 상의 서로 다

른 EJB Container 로 접근한 클라이언트 간의 concurrent access는

데이터베이스가 담당한다. 이 모델의 가장 큰 특징은 EJB Container

Cluster가 자유롭다는 점이다. 서로 다른 EJB Container를 통한 접근

이 가능하기 때문에 트랜잭션 작업의 시작과 종료 시에 EJB Container

는 SQL 명령을 사용하여 데이터베이스와 EJB Bean 의 필드 값을 일

치시킨다.

SINGLE_OBJECT 모델은 어플리케이션의 특성에 큰 영향을 받지 않

고 적용할 수 있는 가장 무난한 모델이다. 대개의 어플리케이션 시스템

은 대용량의 클라이언트 요청을 처리하기 위해 물리적 노드를 클러스

터링하고 EJB Container Cluster 를 사용하여 클라이언트 요청이 분산

되도록 한다. 또 많은 경우에 데이터베이스 내의 table의 크기가 커서

하나의 데이터를 수정하기 위해 접근하는 복수 개의 트랜잭션이 EJB

Container 하나로 동시에 집중되는 경우가 거의 없어 EJB Container

에서의 트랜잭션 병목 현상도 거의 없다.

Client 1

Client 2

Client n Engine 1

E

Client n +1

Client n +2

Client m Engine 2


SINGLE_OBJECT 모델이 적합한 어플리케이션 시스템의 특징은 다음

과 같다.

EJB Container Cluster 를 사용하는 경우

대규모 클라이언트 요청을 처리해야 하는 시스템이거나 하드웨어 구성

이 클러스터링에 중점을 맞춘 구조라면 SINGLE_OBJECT 기반의 EJB

Container Cluster를 사용하는 것이 가장 적절하다.

트랜잭션 작업의 진행 시간이 비교적 짧은 경우

하나의 EJB Container로 접근한 복수 개의 클라이언트 요청은 EJB

Container 가 concurrent access 관리를 해준다. 만약 트랜잭션 작업

하나 하나의 진행시간이 길다면 그 트랜잭션이 같은 EJB Container

로 접근하는 다른 트랜잭션 작업을 모두 block 시켜버려 clustering의

효과가 크게 감소된다. 이 경우에는 다음에서 설명할 MULTIPLE_

OBJECT를 사용하여야 한다.

3) MULTIPLE_OBJECT 데이터베이스가 concurrent access 를 전적으로 담당한다. 데이터 하

나에 대한 트랜잭션 작업이 EJB Container 하나로 동시에 몰릴 경우

EJB Container 는 작업을 blocking 시키지 않고 각 트랜잭션이 작업을

진행할 EJB Bean을 따로 생성하여 모든 작업이 parallel 하게 진행되

도록 한다. Parallel하게 진행된 작업의 serialization은 전적으로 데이

터베이스에 위임한다.

트랜잭션 작업의 진행 시간이 긴 경우에는 MULTIPLE_OBJECT 모델

을 사용하는 것이 최적이다. 데이터베이스는 복수 개의 작업을 parallel

하게 처리하는 것에 최적화되어 구현되어 있다. 트랜잭션 진행 시간이

길어 EJB Container에서의 concurrent access 가 트랜잭션 작업의

serialization 에 많이 관여하게 되면 될수록 데이터베이스는 그 효율성

이 떨어지게 된다. 하나의 데이터베이스에 대한 경합이 많은 경우도 다


른 모델에서는 EJB Container가 작업의 serialization에 많이 관여하게

되는데 반해 MULTIPLE_OBJECT 는 데이터베이스의 parallelism을

최대한 이용할 수 있도록 하여 시스템의 성능을 높일 수 있다.

언듯 보면 MULTIPLE_OBJECT를 사용하는 것이 SINGLE_OBJECT를

사용하는 것보다 항상 유리해 보일 수 있다. 하지만 MULTIPLE_

OBJECT는 트랜잭션 마다의 EJB Bean을 따로 관리해주어야 하는 등

EJB Container 가 부가적인 작업을 해주어야 하는 부담을 안게 된다.

SINGLE_OBJECT 모델에서의 EJB Container 의 작업 block에 의한

성능 저하와 MULTIPLE_OBJECT 에서의 EJB Container 의 추가작업

에 의한 오버헤드 중 어느 것이 중요 고려 사항인가 하는 것은 어플리

케이션 특성에 따라 달라진다.

Client 1

Client 2

Client n

Engine 1

E

Client n +1

Client n +2

Client m

Engine 2


MULTIPLE_OBJECT 모델이 적합한 어플리케이션 시스템의 특징은 다

음과 같다.

트랜잭션 작업 진행 시간이 긴 경우

데이터베이스의 parallelism 을 최대한 이용하여 전체 성능을 높일 수

있다.

전체 데이터의 량은 작지만 각 테이타에 대한 경합이 심한 경우

소수의 중요 데이터를 관리하는 table의 경우 이러한 특성을 가지게 된

다. SINGLE_OBJECT에서 데이터베이스의 parallelism을 이용하려면

복수 개의 EJB Container를 Cluster 하여야 하지만 EJB Container 각

각도 상당량의 리소스를 사용하므로 이 경우 MULTIPLE_OBJECT를

적용한 EJB Container 하나만 가지고 시스템을 운영하는 것이 더 적합

하다.


Data Locking in EJB Engine

앞에서 Entity Bean의 Persistent Storage가 데이터베이스일 경우

EJB Container는 트랜잭션의 시작과 종료 시에 SQL 명령을 수행하여

야 한다고 하였다. 트랜잭션 시작 시에는 read을 수행하는 SQL 명령

이 사용되고, 종료시에는 write를 수행하는 SQL 명령이 사용되는데 이

때 데이터베이스에는 해당 데이터에 대한 read lock, write lock이 각각

잡히게 된다. 만약 어플리케이션의 데이터 수정이 빈번하여 write lock

이 자주 잡히게 될 경우 동시에 같은 데이터를 수정하려는 두 작업이

lock promotion 에 의해 deadlock을 걸리는 경우가 자주 발생할 수 있

다. 즉 두 작업이 트랜잭션 시작 시에 shared lock인 read lock 을 잡

으며 각각 데이터를 읽어 간 후 종료 시에 수정된 내용을 반영할 때

exclusive lock인 write lock을 잡아 write를 하려 하지만 서로 상대방

의 read lock 에 의해 block 되어 양쪽 작업 모두 진행하지 못하게 되

는 것이다. 이 경우에는 read 동작 시에 read lock를 잡지 말고 차라리

write lock를 먼저 잡아버린 후 동작을 하는 것이 나을 수도 있다. 다

른 작업은 write lock에 의해 block 되지만 deadlock를 피할 수 있으

므로 시스템 전에의 성능 측면에서는 더 나은 선택이다. JEUS 에서는

트랜잭션 시작 시에 read lock을 잡을 것인지 write lock을 잡을 것인

지를 설정 할 수 있다. 어플리케이션 특성이 수정작업이 적은 경우라면

read lock을 잡고 작업을 하는 것이 lock에 의한 block을 줄여야 하고,

수정 작업이 많은 경우라면 write lock을 잡아 deadlock의 위험을 피

해야 한다.

엔진 모델과 Data Locking 을 포함한 EJB Container 에서의

configurability를 단순화 하여 표현하면 다음과 같다.


Concurrent

Client Access

Exclusive_Access

Long transaction processing time

Heavy data access contention

No

Single_Object

Read

locking

Write

locking

Multiple_Objec

Read

locking

Write

locking

small many

Yes

Read > Write

Read > Write

Read < Write Read < Write

performance issues in jeus - tmaxsoftkr.tmaxsoft.com/img/service/pdf/form/performance_issues... ·...

Documents