EJB 컨테이너 조정
EJB(Enterprise JavaBeans) 컨테이너 캐시의 크기에 영향을 미치는 애플리케이션을 사용하는 경우, 애플리케이션의 성능이 잘못된 크기 설정의 영향을 받을 수 있습니다. EJB 3.x 모듈에서 엔티티 Bean이 지원되지 않는 것을 아는 것도 중요하지만 이 주제에서는 컨테이너 관리 지속성(CMP)이 다뤄집니다.
EJB 캐시 크기
Tivoli® 성능 뷰어를 모니터하여 EJB 컨테이너 캐시 크기 설정이 사용자의 애플리케이션에 대해 올바르게 조정되는지 여부를 진단할 수 있습니다.
애플리케이션이 캐시를 모두 채워 축출 현상이 발생하게 되면 Tivoli 성능 뷰어가 높은 비율로 호출되고 있는 ejbStores 메소드를 표시하고 이는 워크스테이션 시스템에서 예상되는 프로세스 사용량보다 낮을 수 있습니다.
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을 포함하도록 빌드되기 때문에 이 캐시 크기를 이전 공식에서 얻은 값보다 크게 설정하여 최고의 성능을 얻을 수 있습니다.
아래 관리 콘솔에서 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 세션 제한시간 값을 구성할 수 있습니다.

그러나 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 파일 확장자를 계속 사용합니다.
sptcfgStateless 세션 Bean은 대화 상태가 없고 어느 특정 클라이언트 전용이 아니기 때문에 제한시간 값이 없습니다.
Rational® Application Developer를 사용하여 EJB 2.x 모듈에 있는 Bean에 대해 stateful 세션 제한시간 값을 구성하는 데 사용되는 ibm-ejb-jar-ext.xmi 파일을 업데이트할 수 있습니다. 자세한 정보는 Rational Application Developer Information Center에 있는 Bean에 대한 세션 제한시간 설정 정의의 내용을 참조하십시오.
<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에 적용됩니다.
- stateful-timeout XML 요소
- @StatefulTimeout 어노테이션
- ibm-ejb-jar-ext.xml 또는 ibm-ejb-jar-ext.xmi
- com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout 시스템 특성
- 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이 사용된 후 풀에 배치될 때 인스턴스의 수가 증가합니다.
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에 사용할 기본 키 오브젝트의 작성을 처리하는 방식을 이해해야 합니다.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true

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

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

-Dcom.ibm.ws.pm.batch=true
이러한 최적화 작업에 따른 성능 이점은 애플리케이션마다 다릅니다. 애플리케이션이 CMP Bean을 아예 또는 거의 업데이트하지 않거나 트랜잭션당 단일 Bean만 업데이트하는 경우 성능상의 이점이 없습니다. 애플리케이션이 트랜잭션당 다중 Bean을 업데이트하는 경우 이 매개변수를 통해 애플리케이션 성능상의 이점을 얻을 수 있습니다.
데이터베이스 | 일괄처리 업데이트 지원 | 낙관적 동시성 제어로 일괄처리 업데이트 지원 |
---|---|---|
DB2® | yes | no |
Oracle | yes | no |
DB2 유니버셜 드라이버 | yes | yes |
Informix® | yes | yes |
SQLServer | yes | yes |
Apache Derby | yes | yes |

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

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

'com.ibm.ws.pm.grouppartialupdate=true' and 'com.ibm.ws.pm.batch=true'