EJB 컨테이너 조정

EJB(Enterprise JavaBeans) 컨테이너 캐시의 크기에 영향을 미치는 애플리케이션을 사용하는 경우, 애플리케이션의 성능이 잘못된 크기 설정의 영향을 받을 수 있습니다. EJB 3.x 모듈에서 엔티티 Bean이 지원되지 않는 것을 아는 것도 중요하지만 이 주제에서는 컨테이너 관리 지속성(CMP)이 다뤄집니다.

EJB 캐시 크기

Tivoli® 성능 뷰어를 모니터하여 EJB 컨테이너 캐시 크기 설정이 사용자의 애플리케이션에 대해 올바르게 조정되는지 여부를 진단할 수 있습니다.

애플리케이션이 캐시를 모두 채워 축출 현상이 발생하게 되면 Tivoli 성능 뷰어가 높은 비율로 호출되고 있는 ejbStores 메소드를 표시하고 이는 워크스테이션 시스템에서 예상되는 프로세스 사용량보다 낮을 수 있습니다.

다음 공식의 결과가 2000 이상인 경우 엔터프라이즈 Bean을 사용하는 모든 애플리케이션은 이 설정의 기본값이 조정되도록 해야 합니다.
EJB_Cache_Size = (Largest number of Option B or C entity beans enlisted in a 
transaction * maximum number of concurrent transactions) + 
(Largest number of unique Option A entity beans expected to be accessed during 
typical application workload) + 
(Number of stateful session beans active during typical workload) + 
(Number of stateless session bean types used during typical workload)

여기에서: Option B and C entity beans are only held in the EJB cache during the lifetime 
of the transaction they are enlisted in. Therefore, the first term in the formula 
computes the average EJB cache requirements for these types of beans.

Option A entity beans are held in the EJB cache indefinitely, and are only removed
 from the cache if there starts to become more beans in the cache than the cache 
size has been set to. 
If your application uses Read Only Beans, consider them to be 
Option A beans for this tuning calculation. 

Stateful session beans are held in the EJB cache until they are removed by the 
application, or until their session timeout value is reached.

Only a single stateless session bean instance for each EJB type is held in the 
cache during the time any methods are running on that stateless session 
bean. If two or more methods are being implemented simultaneously on the same 
stateless session bean type, each method runs on its own bean instance, but 
only one cache location is used for all of these instances. 

이 공식은 애플리케이션 서버 내에서 동시에 활성인 최대 엔터프라이즈 Bean 수에 대한 상한을 계산합니다. EJB 컨테이너 캐시는 성능 최적화를 위해 이러한 모든 Bean을 포함하도록 빌드되기 때문에 이 캐시 크기를 이전 공식에서 얻은 값보다 크게 설정하여 최고의 성능을 얻을 수 있습니다.

서버 > 서버 유형 > WebSphere Application Server > server_name > EJB 컨테이너 설정 > EJB 캐시 설정 아래 관리 콘솔에서 EJB 캐시 크기를 설정할 수 있습니다.

또한 EJB 캐시 크기를 조정하는 동안 애플리케이션의 필요에 맞게 EJB 컨테이너 관리 스레드 매개변수를 조정할 수 있습니다. 관리 스레드는 정리 간격 설정을 통해 제어됩니다. 이 설정은 캐시 크기 이내로 Bean 인스턴스 수를 유지하기 위해 제품 내 디먼 스레드가 캐시에서 최근에 사용된 Bean 인스턴스 제거를 시도하는 빈도를 제어합니다. 이 동작은 EJB 컨테이너가 캐시에서 항목을 배치하고 검색할 수 있도록 합니다. 이 간격 설정은 기본값으로 유지하십시오. 그러나 일부 경우에 이 간격을 줄이는 것이 유리한지 확인할 필요가 있습니다.

EJB 캐시 추적 서비스를 사용하여 EJB 캐시를 조정하는 것에 대한 정보는 EJB 캐시 조정 및 추적 서비스 사용의 내용을 참조하십시오.

EJB Stateful 세션 Bean 조정

Stateful 세션 Bean 제한시간은 WebSphere® Application Server의 버전에 따라 다른 범위 및 다른 방식으로 구성됩니다.

WebSphere Application Server 버전 6.1 이전에서는 ibm-ejb-jar-ext.xmi 파일을 사용하여 Bean당 stateful 세션 Bean 제한시간의 구성을 지원합니다.

WebSphere Application Server 버전 7.0은 ibm-ejb-jar-ext.xmi 파일(EJB 2.x 모듈의 경우) 및 ibm-ejb-jar-ext.xml 파일(EJB 3.x 모듈의 경우)을 사용하여 Bean당 stateful 세션 Bean 제한시간의 구성을 지원합니다.

WebSphere Application Server 버전 8.x는 ibm-ejb-jar-ext.xmi(EJB 2.x 모듈의 경우) 및 ibm-ejb-jar-ext.xml(EJB 3.x 모듈의 경우) 파일, stateful-timeout XML 요소 및 @StatefulTimeout 어노테이션을 사용하여 Bean당 stateful 세션 Bean 제한시간의 구성을 지원합니다. 또한 com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout 시스템 특성을 사용하여 서버 전체(글로벌) stateful 세션 제한시간 값을 구성할 수 있습니다.

지원된 구성 지원된 구성: IBM® 확장 및 바인딩 파일의 경우 .xmi 또는 .xml 파일 이름 확장자는 Java EE 5 이전 애플리케이션이나 모듈을 사용하는지 또는 Java™ EE 5 이상 애플리케이션이나 모듈을 사용하는지 여부에 따라 달라집니다. IBM 확장 또는 바인딩 파일 이름은 ibm-*-ext.xmi 또는 ibm-*-bnd.xmi입니다. 여기서, *는 확장 또는 바인딩 파일의 유형입니다(예: app, application, ejb-jar 또는 web). 다음 조건이 적용됩니다.
  • 버전 5 이전의 Java EE 버전을 사용하는 애플리케이션 또는 모듈의 경우, 파일 확장자는 .xmi여야 합니다.
  • Java EE 5 이상을 사용하는 애플리케이션 또는 모듈의 경우, 파일 확장자는 .xml이어야 합니다. .xmi 파일이 애플리케이션 또는 모듈에 포함된 경우 제품에서 .xmi 파일을 무시합니다.

그러나 Java EE 5 이상 모듈은 Java EE 5 이전 파일이 포함되어 있고 .xmi 파일 이름 확장자가 사용된 애플리케이션에 있을 수 있습니다.

ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, ibm-portlet-ext.xmi 파일은 .xmi 파일 확장자를 계속 사용합니다.

sptcfg

Stateless 세션 Bean은 대화 상태가 없고 어느 특정 클라이언트 전용이 아니기 때문에 제한시간 값이 없습니다.

Rational® Application Developer를 사용하여 EJB 2.x 모듈에 있는 Bean에 대해 stateful 세션 제한시간 값을 구성하는 데 사용되는 ibm-ejb-jar-ext.xmi 파일을 업데이트할 수 있습니다. 자세한 정보는 Rational Application Developer Information Center에 있는 Bean에 대한 세션 제한시간 설정 정의의 내용을 참조하십시오.

예를 들어, stateful 세션 제한시간 값을 15분으로 설정하기 위해 생성된 XMI 코드는 다음과 같습니다.
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension_1"
  timeout="15">

ibm-ejb-jar-ext.xml 파일을 수정하여 EJB 3.x 모듈에서 Bean에 대한 stateful 세션 제한시간을 설정할 수 있습니다. 예를 들어, myBean Bean에 대해 stateful 세션 제한시간 값을 15분으로 설정하기 위한 코드는 다음과 같습니다.

<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension"
  timeout="15">
    <enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#MyBean"/>
 </ejbExtensions>

StatefulTimeout 어노테이션을 사용하여 stateful 세션 Bean 제한시간을 구성할 수 있습니다. 이 @StatefulTimeout 어노테이션은 제한시간의 기간을 나타내는 필수 값 매개변수 및 선택적 단위 매개변수를 사용합니다. 선택적 단위 매개변수가 지정되지 않으면 기본 단위는 분입니다. @StatefulTimeout 어노테이션은 EJB 3.1의 일부로 소개됩니다.

StatefulTimeout 어노테이션을 사용하여 제한시간 값을 100초로 선언하는 경우를 예로 들면 다음과 같습니다.

@StatefulTimeout(value=100 unit=java.util.concurrent.TimeUnit.SECONDS)

ejb-jar.xml 배치 디스크립터의 stateful-timeout XML 요소를 사용하여 stateful 세션 Bean 제한시간을 구성할 수 있습니다. stateful-timeout 요소는 EJB 3.1의 일부로 소개됩니다.

예를 들어, 100초로 제한시간 값을 설정하려는 경우:

<stateful-timeout>
     <timeout>100</timeout>
     <unit>Seconds</unit>
</stateful-timeout>

EJB 3.1부터 StatefulTimeout 어노테이션 및 stateful-timeout XML 요소는 Bean당 제한시간 값을 선언하기 위한 스펙 정의 메커니즘입니다. EJB 3.1 이전에는 Bean당 stateful 세션 제한시간을 선언하기 위한 스펙 정의 방식이 없습니다. stateful-timeout XML 요소 또는 @StatefulTimeout 어노테이션 사용 시 값이 -1이면 이 Bean은 제한시간을 초과하지 않음을 의미하며 값이 0이면 이 Bean을 즉시 제거할 수 있음을 의미합니다.

com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout 시스템 특성을 사용하여 글로벌(서버 전체) 기준으로 stateful 세션 Bean 제한시간을 구성할 수 있습니다. com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout의 시간 단위는 분입니다. 지정되는 값은 0 이상이어야 하고 올바르지 않은 값이 지정되는 경우 기본값인 10분이 대신 사용됩니다. 글로벌 제한시간 값은 XML 또는 어노테이션을 사용하여 구성할 수 없습니다. 글로벌 제한시간 값은 EJB 2.x 또는 EJB 3.x 모듈의 stateful 세션 Bean을 포함한 모든 stateful 세션 Bean에 적용됩니다.

WebSphere Application Server 버전 8.x에서 Bean 레벨 stateful 제한시간 설정은 서버 전체 제한시간 설정에 우선합니다. 서버 전체 제한시간 설정은 기본(미지정) 제한시간에 우선합니다. 다음 우선순위는 WebSphere Application Server 버전 8.x에서 실행되고 있는 Bean의 stateful 세션 제한시간 값을 판별하는 데 사용됩니다.
  1. stateful-timeout XML 요소
  2. @StatefulTimeout 어노테이션
  3. ibm-ejb-jar-ext.xml 또는 ibm-ejb-jar-ext.xmi
  4. com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout 시스템 특성
  5. Bean 레벨 또는 서버 전체 제한시간 값이 명시적으로 지정되지 않으면 제한시간 기본값인 10분이 적용됩니다.

Dcom.ibm.websphere.ejbcontainer.poolSize

애플리케이션이 풀에서 대부분의 Bean 인스턴스를 사용하는 경우 Tivoli 성능 뷰어는 다음을 표시합니다. 대다수의 Bean 인스턴스를 사용 중인 경우 JVM의 사용자 정의 특성 태그에 이 매개변수를 추가하여 소진되고 있는 해당 Bean 풀의 크기를 늘리십시오. 예를 들면, 다음과 같습니다.

-Dcom.ibm.websphere.ejbcontainer.poolSize=<application_name>#<module_name>#
<enterprisebean_name>=<minSize>,<maxSize>

여기에서:

풀 크기를 설정 중인 Bean에서 <application_name> 요소는 엔터프라이즈 아카이브(EAR) 파일 배치 디스크립터에서 정의된 Java EE 애플리케이션 이름입니다.

풀 크기를 설정 중인 Bean에서 <module_name> 요소는 EJB 모듈의 Java 아카이브(JAR) 파일 이름입니다.

풀 크기를 설정 중인 Bean에서 <bean_name> 요소는 EJB 모듈 배치 디스크립터에서 정의된 Java EE 엔터프라이즈 Bean 이름입니다.

<minSize> 요소는 Bean이 풀에 있는 기간에 관계없이 컨테이너가 풀에서 유지보수하는 Bean의 수입니다(이 수를 초과하는 Bean은 메모리 사용을 최적화하기 위해 시간의 경과에 따라 풀에서 지워짐).

<maxSize> 요소는 일단 사용되면 풀에 더 이상의 Bean 인스턴스가 배치되지 않는 풀의 Bean 인스턴스 수입니다(즉, 풀이 이 크기가 되면 추가 Bean이 풀에 추가되는 대신 버려지며 이 경우 풀의 Bean 수에 상한이 있어 메모리 사용량이 무제한으로 증가하지 않게 됨).

풀의 인스턴스 수를 고정된 크기로 유지하기 위해서 minSize 및 maxSize 요소를 같은 수로 설정할 수 있습니다. 애플리케이션 서버에서 실행 중인 모든 EJB 유형에 대해 개별 인스턴스 풀이 존재하고 모든 풀은 인스턴스 없이 시작되며 Bean이 사용된 후 풀에 배치될 때 인스턴스의 수가 증가합니다.

컨테이너에 Bean 인스턴스가 필요하지만 풀에 사용 가능한 Bean이 없으면 컨테이너는 Bean 인스턴스를 작성하여 사용한 다음 풀에 maxSize 인스턴스가 없을 경우 이 인스턴스를 풀에 배치합니다. 예제 문:
Dcom.ibm.websphere.ejbcontainer.poolSize=ivtApp#ivtEJB.jar#ivtEJBObject=125,1327  
은 애플리케이션 ivtApp에 있는 ivtEJB.jar 파일 내에서 ivtEJBObject라는 이름의 Bean에 대해 minSize는 125로, maxSize는 1327로 설정합니다.

애플리케이션 ivtApp는 실제 애플리케이션 이름으로 대체되고 ivtEJB.jar 파일은 풀 크기를 늘려야 하는 Bean이 포함된 JAR 파일로 대체되며 ivtEJBObject는 풀 크기를 늘려야 하는 엔터프라이즈 Bean의 Bean 이름입니다. 이 풀에 보관되는 최소 Bean 수는 125입니다. 이 풀에 보관되는 최대 Bean 수는 1327입니다. 풀에서 추가 축출이 발생하지 않도록 이러한 값을 설정하십시오. 대부분의 경우 메모리가 충분하면 풀 증가 또는 감소가 발생하지 않기 때문에 이러한 값은 동일하게 설정해야 합니다.

Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation

애플리케이션이 CMP Bean 및 제품 내 Bean 관리 지속성(BMP) Bean에 사용할 기본 키 오브젝트의 작성을 처리하는 방식을 이해해야 합니다.

EJB 컨테이너는 엔티티 Bean의 기본 키를 내부 데이터 구조 내부의 ID로 사용함으로써 성능을 최적화합니다. 그러나 내부 캐시에 저장된 오브젝트가 애플리케이션에서 사용된 오브젝트와 구분되도록 하려면 Bean에 처음 액세스할 때 EJB 컨테이너가 이러한 기본 키 오브젝트를 복사해야 합니다. 이 프로세스는 애플리케이션이 변경되거나 기본 키를 변경하는 경우 내부 구조가 일정하게 유지되도록 하기 위해 발생합니다. 애플리케이션이 엔티티 Bean 작성 및 액세스에 사용되는 기본 키가 작성된 후에는 변경하지 않는 경우 EJB 컨테이너가 기본 키 오브젝트 복사를 건너뛸 수 있도록 하는 특수 플래그를 사용하여 프로세서 주기를 단축하고 성능을 향상시킬 수 있습니다. 이 메커니즘은 사용자 책임 하에 JVM 사용자 정의 특성 필드에 –D 특성을 추가하여 사용할 수 있습니다.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true
지원된 구성 지원된 구성: 엔티티 Bean은 EJB 3.x 이상 모듈에서는 지원되지 않습니다. sptcfg

이러한 최적화 작업에 따른 성능 이점은 애플리케이션마다 다릅니다. 애플리케이션이 기본 유형의 엔터프라이즈 Bean 기본 키를 사용하는 경우, 이러한 오브젝트는 이미 변경할 수 없으며 복사 메커니즘에서도 이 방법을 고려하므로 아무런 이점이 없습니다. 그러나 애플리케이션이 여러 가지 복잡한 기본 키(기본 키 또는 다중 필드에 대한 오브젝트)를 사용하는 경우 이 매개변수를 사용하여 성능을 현저히 향상시킬 수 있습니다.

Dcom.ibm.ws.pm.deferredcreate

지속성 관리자는 CMP 엔티티 Bean에서 데이터베이스로 데이터를 유지하기 위해 EJB 컨테이너에서 사용됩니다.

ejbCreate 메소드를 호출하여 엔티티 Bean을 작성하는 경우 기본적으로 지속성 관리자는 한 개의 기본 키만 있는 비어 있는 행을 데이터베이스에 즉시 삽입합니다. 대부분의 경우 Bean을 작성했으면 작성된 Bean 또는 동일한 트랜잭션 내 다른 Bean에서 필드를 수정해야 합니다. 데이터베이스에 대한 한 개의 트립을 제거하기 위해 트랜잭션이 종료될 때까지 데이터베이스로의 삽입을 연기하려는 경우 JVM 사용자 정의 특성 필드 내부에서 –D 플래그를 설정하십시오. 데이터가 데이터베이스에 삽입되고 일관성이 유지됩니다.
지원된 구성 지원된 구성: 엔티티 Bean은 EJB 3.x 이상 모듈에서는 지원되지 않습니다. sptcfg
-Dcom.ibm.ws.pm.deferredcreate=true

이러한 최적화 작업에 따른 성능 이점은 애플리케이션마다 다릅니다. EJB 애플리케이션 트랜잭션이 삽입에 집중되는 경우 이러한 최적화로 애플리케이션은 이점을 얻을 수 있습니다. 애플리케이션이 소수의 삽입을 수행하는 경우 이 최적화의 이점은 감소합니다.

Dcom.ibm.ws.pm.batch

EJB 애플리케이션이 단일 트랜잭션 내 여러 CMP Bean에 액세스하는 경우, Bean에 대해 수행되는 조작(예: 업데이트, 삽입 및 읽기)에 따라 데이터베이스에 대해 실행되는 조작의 수는 CMP Bean에 대해 수행되는 조작과 직접적인 관련이 있습니다. 현재 사용하는 데이터베이스 시스템이 update 문의 일괄처리를 지원하는 경우, 이 플래그를 사용함으로써 단일 트랜잭션에서 셋 이상의 update 문을 포함하는 모든 데이터베이스 상호 작용에 대해 성능을 향상시킬 수 있습니다.

지원된 구성 지원된 구성: 엔티티 Bean은 EJB 3.x 이상 모듈에서는 지원되지 않습니다. sptcfg
이 플래그를 사용하십시오. 이 플래그는 데이터베이스에 발행되는 한 개의 단일 일괄처리 명령문에 update 문을 추가하는 지속성 관리자를 지원합니다. 이 프로세스를 통해 데이터베이스로의 라운드트립을 줄여 성능을 향상시킬 수 있습니다. 애플리케이션의 단일 트랜잭션에서 여러 CMP Bean을 업데이트하는 동작을 표시하고 데이터베이스가 일괄처리 업데이트를 지원함을 알고 있는 경우 JVM 사용자 정의 특성 필드 내에 –D 플래그를 설정할 수 있습니다. 예를 들면, 다음과 같습니다.
-Dcom.ibm.ws.pm.batch=true

이러한 최적화 작업에 따른 성능 이점은 애플리케이션마다 다릅니다. 애플리케이션이 CMP Bean을 아예 또는 거의 업데이트하지 않거나 트랜잭션당 단일 Bean만 업데이트하는 경우 성능상의 이점이 없습니다. 애플리케이션이 트랜잭션당 다중 Bean을 업데이트하는 경우 이 매개변수를 통해 애플리케이션 성능상의 이점을 얻을 수 있습니다.

다음 테이블은 일괄처리 업데이트를 지원하는 백엔드 데이터베이스를 나열합니다.
표 1. 일괄처리 업데이트를 지원하는 백엔드 데이터베이스. 다음 표는 일괄처리 업데이트를 지원하는 백엔드 데이터베이스를 나열합니다.
데이터베이스 일괄처리 업데이트 지원 낙관적 동시성 제어로 일괄처리 업데이트 지원
DB2® yes no
Oracle yes no
DB2 유니버셜 드라이버 yes yes
Informix® yes yes
SQLServer yes yes
Apache Derby yes yes
지원된 구성 지원된 구성: OCC를 사용한 일괄처리 업데이트는 액세스 목적에 의해 지정되었더라도 이를 지원하지 않는 데이터베이스에는 수행할 수 없습니다. sptcfg

com.ibm.ws.pm.useLegacyCache

제품이 javax.rmi.CORBA.UtilDelegate 인터페이스를 구현하는 데 사용하는 Java 클래스의 이름을 지정합니다.

지원된 구성 지원된 구성: 엔티티 Bean은 EJB 3.x 이상 모듈에서는 지원되지 않습니다. sptcfg
지속성 관리자에는 레거시 캐시2단계 캐시의 두 가지 유형 캐싱 메커니즘이 있습니다. 일반적으로 2단계 캐시가 이 모드에서의 최적화로 인해 레거시 캐시에 비해 보다 효율적입니다. 2단계 캐시를 권장하지만, 기본값은 레거시 캐시입니다. 다음과 같이 시스템 특성을 통해 이 구성을 설정하십시오.
com.ibm.ws.pm.useLegacyCache=false

com.ibm.ws.pm.grouppartialupdate 및 com.ibm.ws.pm.batch

부분 업데이트 기능은 특정 시나리오에서 엔터프라이즈 Bean을 사용하여 애플리케이션의 성능을 향상시킵니다. 지속성 관리자에는 레거시 캐시2단계 캐시의 사용 가능한 두 가지 캐싱 메커니즘이 있습니다. 일반적으로 2단계 캐시가 이 모드에서의 최적화로 인해 레거시 캐시보다 성능이 더 좋습니다.

지원된 구성 지원된 구성: 엔티티 Bean은 EJB 3.x 이상 모듈에서는 지원되지 않습니다. sptcfg
일괄처리 업데이트 및 부분 업데이트 둘 다를 수행해야 하는 특정 애플리케이션에서 두 업데이트의 이점을 얻으려면 다음 시스템 특성을 구성해야 합니다.
'com.ibm.ws.pm.grouppartialupdate=true' and 'com.ibm.ws.pm.batch=true'

주제 유형을 표시하는 아이콘 참조 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rprf_ejbcontainer
파일 이름:rprf_ejbcontainer.html