EJB 3.2 성능 저하

Question

현재 EJB 프로젝트를 버전 2.0에서 버전 3.2 (모두 Stateful)로 업그레이드 중입니다. 비즈니스 로직은 동일하게 유지되며 변경 사항은 EJB 파트 (설명 자 파일을 주석으로 바꾸거나 기존 조회 대신 주입 지점을 사용하는 것 등)입니다. 요청 처리의 관점에서 모든 것이 잘 작동하는 것 같습니다. 문제는 성능입니다. 하나의 연결된 클라이언트에서 모든 요청에는 약 300ms가 걸립니다. 두 번째 클라이언트를 추가하면 평균 시간이 700ms가됩니다. 세 번째 클라이언트에서 평균은 1 초를 초과합니다. EJB 2.0 버전에서는 클라이언트가 많아도 처리 시간이 약간 (50 ~ 100ms) 증가하지만 걱정할 것은 없습니다.

성능 저하는 매우 분명합니다. 이유를 알 수 없습니다.

저는 EJB 타임 아웃, 트랜잭션 유형 등으로 놀았지만 운이 없었습니다. 나는 또한 JMC를 통해 서버 프로파일 링을 시도했지만 의심스런 것을 찾지 못했습니다.

마치 모든 요청이 순차적으로 처리되며 동시에 처리되지 않는 것처럼 보입니다.

가능한 원인에 대한 힌트를 줄 수 있습니까? 누락 된 구성이 있습니까?

참고 : 문제는 WebSphere 9와 GlassFish 4.1.1에서 모두 발생하므로 응용 프로그램의 문제점입니다.

EDIT # 1

애플리케이션의 로그를 확인 후,이 요청은 동시성을 순차적으로 처리되지되는 것을 확인할 수있다. (주차)

• 27 RUNNABLE
• 18 TIMED_WAITING
• 6 TIMED_WAITING (객체 모니터에) : 마이클의 제안에 따라
  는

  , 나는 쓰레드 덤프를 쳐다 보면서, 주어진 순간에 있었다

• 16 TIMED_WAITING (자) (오브젝트 모니터)
• 23 WAITING
• 40 WAITING (주차)

차단 된 스레드의 흔적이 없습니다.

아이디어가 있으십니까?

Answer 1

어떻게 테스트하나요?

여러 클라이언트가 동일한 stateful 세션 빈 인스턴스를 얻는 것처럼 들립니다.

컨테이너는 동일한 SFSB 인스턴스에 대한 호출을 serialize합니다. 그 일을하기로되어 있는데, 그 전에는 일어나지 않았다면이 동작을 사용하지 않는 플랫폼 종속적 인 배치 디스크립터가있을 수 있습니다.

그러나 테스트 프레임 워크를 사용하고 있고 모든 클라이언트가 동일한 세션을 사용하고 있다면 문제가있는 것처럼 보일 것입니다.

§4.3.13은 EJB 스펙의 "세션 콩 방법을 직렬화하는 것은"말한다 :

컨테이너는 각각의 상태와 상태 세션 빈 인스턴스에 대한 호출을 직렬화한다. 대부분의 컨테이너는 동시에 실행되는 세션 빈의 많은 인스턴스를 지원합니다. 그러나 각 인스턴스는 메서드 호출의 일련 화 된 시퀀스 만 볼 수 있습니다. 따라서 상태 저장 또는 상태 비 저장 세션빈은 재진입 가능으로 코딩 할 필요가 없습니다.

모든 클라이언트간에 단일 SFSB 인스턴스를 공유하는 경우 @Stateful에서 @Singleton으로 변경하는 것이 적절할 수 있습니다. 싱글 톤 EJB는 @ConcurrencyManagement 및 @Lock 주석을 사용하여 명시 적 재진입 제어를 제공합니다. 당신이 당신의 EJB의 스레드 안전을 완전히 행복 경우에 당신은 당신의 콩을 표시 멀리 얻을 수 있습니다 5+ 사용자와 부하 테스트 중에 스레드 덤프를 얻을 수

@Singleton 
@ConcurrencyManagement(ConcurrencyManagementType.BEAN) 
public class MyStatefulSessionBeanMasqueradingAsASingleton { 
    ... 
}