Sun Java System Application Server 9.1 배포 계획 설명서

성능 목표 설정

가장 단순한 의미에서 높은 성능이란 처리량 최대화와 응답 시간 감소를 의미합니다. 하지만 이러한 기본 목표를 넘어, 다음을 결정하여 특정 목표를 설정할 수 있습니다.

배포되는 응용 프로그램 및 서비스 유형과 클라이언트에서 액세스하는 방법
높은 가용성이 요구되는 응용 프로그램 및 서비스
응용 프로그램이 세션 상태를 포함하는지 여부
시스템에서 지원해야 하는 요청 용량 또는 처리량
시스템에서 지원해야 하는 동시 사용자 수
사용자 요청에 대해 허용되는 평균 응답 시간
요청 간 평균 인지 시간

이러한 메트릭 중 일부는 RBE(원격 브라우저 에뮬레이터) 도구나 예상 응용 프로그램 활동을 시뮬레이트하는 웹 사이트 성능 및 벤치마킹 소프트웨어를 사용하여 계산할 수 있습니다. 일반적으로 RBE와 벤치마킹 제품은 동시 HTTP 요청을 생성한 후 지정된 분당 요청 수에 대한 응답 시간을 보고합니다. 이렇게 산출된 수치를 사용하여 서버 활동을 계산할 수 있습니다.

이 장에 설명된 계산 결과는 절대적 결과가 아닙니다. Application Server와 응용 프로그램의 성능을 미세 조정할 때 기준으로 적용할 참조점으로 사용하십시오.

이 절은 다음 내용으로 구성되어 있습니다.

처리량 예측

넓은 의미에서 처리량이란 Application Server에서 수행되는 작업의 양을 나타냅니다. Application Server의 경우 처리량은 서버 인스턴스별 분당 처리되는 요청 수로 정의할 수 있습니다. 고가용성 응용 프로그램은 세션 상태 데이터를 정기적으로 저장하기 때문에 HADB에도 일정 수준 이상의 처리량을 요구합니다. HADB의 처리량은 분당 HADB 요청 수와 요청당 평균 세션 크기를 곱한 값인 분당 저장된 세션 데이터의 양으로 정의할 수 있습니다.

다음 절에 설명된 것처럼 Application Server의 처리량은 사용자 요청의 특징과 크기, 사용자 수, 그리고 Application Server 인스턴스와 백엔드 데이터베이스의 성능을 비롯한 많은 요소로 구성된 함수입니다. 시뮬레이트된 작업 로드를 가지고 벤치마킹함으로써 단일 시스템의 처리량을 예측할 수 있습니다.

고가용성 응용 프로그램은 데이터를 HADB에 정기적으로 저장하기 때문에 추가 오버헤드가 발생합니다. 오버헤드 크기는 데이터의 양, 변경 빈도 및 저장 빈도에 따라 결정됩니다. 처음 두 요소는 해당 응용 프로그램에 따라 결정되며 마지막 요소도 서버 설정의 영향을 받습니다.

HADB 처리량은 분당 HADB 요청 수에 요청당 평균 데이터 양을 곱한 값으로 정의할 수 있습니다. HADB 처리량이 클수록 더 많은 HADB 노드와 더 큰 저장소가 필요합니다.

Application Server 인스턴스의 로드 예측

다음 요소를 고려하여 Application Server 인스턴스의 로드를 예측합니다.

최대 동시 사용자 수

사용자는 웹 브라우저나 Java 프로그램과 같은 클라이언트를 통해 응용 프로그램과 상호 작용합니다. 클라이언트는 사용자의 작업에 따라 정기적으로 Application Server에 요청을 보냅니다. 세션이 만료되거나 종료되지 않는 한 사용자는 활성 상태로 간주됩니다. 동시 사용자 수를 예측할 때 이러한 모든 활성 사용자를 포함합니다.

다음 그림은 분당 처리되는 요청 수(처리량) 대 사용자 수를 나타내는 일반적인 그래프입니다. 처음에는 사용자 수가 증가함에 따라 처리량이 증가합니다. 그러나 동시 요청 수가 증가함에 따라 서버 성능이 포화되기 시작하고 처리량이 감소하기 시작합니다.

동시 사용자를 추가함으로써 분당 처리할 수 있는 요청 수가 감소하는 지점을 확인할 수 있습니다. 이 지점은 최적 성능에 도달한 후 처리량이 감소하기 시작하는 시점을 나타냅니다. 일반적으로, 가능한 한 높은 최적 처리량으로 시스템을 작동하도록 노력해야 합니다. 추가 로드를 처리하고 처리량을 높이기 위해 처리 용량을 추가해야 할 수 있습니다.

인지 시간

사용자는 요청을 지속적으로 제출하지 않습니다. 사용자가 요청을 제출하면 서버에서는 요청을 수신하여 처리한 후 사용자가 새 요청을 제출하기 전 시간이 소비되는 시점에 결과를 반환합니다. 한 요청과 다음 요청 사이의 시간을 인지 시간이라고 합니다.

인지 시간은 사용자 유형에 따라 다릅니다. 예를 들어 웹 서비스의 경우와 같은 시스템 간 상호 작용은 일반적으로 사람이 사용자인 경우보다 낮은 인지 시간을 포함합니다. 또한, 시스템과 인간 상호 작용의 혼합을 고려하여 인지 시간을 예측해야 할 수 있습니다.

평균 인지 시간 결정은 중요한 작업입니다. 이 기간을 사용하여 분당 완료해야 하는 요청 수는 물론 시스템에서 지원할 수 있는 동시 사용자 수를 계산할 수 있습니다.

평균 응답 시간

응답 시간이란 Application Server가 사용자에게 요청 결과를 반환하는 데 걸리는 시간을 말합니다. 응답 시간은 네트워크 대역폭, 사용자 수, 제출된 요청의 수와 유형, 그리고 평균 인지 시간과 같은 요소의 영향을 받습니다.

이 절에서 응답 시간은 중간 또는 평균 응답 시간을 나타냅니다. 각 요청 유형에는 고유한 최소 응답 시간이 있습니다. 그러나 시스템 성능을 평가할 때는 모든 요청의 평균 응답 시간을 기반으로 분석합니다.

응답 시간이 빠를수록 처리되는 분당 요청 수는 증가합니다. 하지만 다음 그림에 나타난 것처럼 분당 요청 수가 감소하더라도 시스템의 사용자 수가 증가함에 따라 응답 시간이 증가하기 시작합니다.

죄송합니다. 이 설명서 버전에서는 그래픽을 사용할 수 없습니다.

이 그림과 같은 시스템 성능 그래프에 따르면 특정 시점 이후 분당 요청 수는 응답 시간에 반비례합니다. 분당 요청 감소량이 급격할수록 응답 시간의 증가가 더 가파릅니다(점선 화살표로 표시).

그림에서 최대 로드 지점은 분당 요청 수가 감소하기 시작하는 지점입니다. 이 지점 이전의 응답 시간 계산에는 공식에 최대 수치가 사용되지 않기 때문에 반드시 정확할 필요는 없습니다. 이 지점 이후에는 분당 요청과 응답 시간 사이의 반비례 관계 때문에 관리자가 최대 사용자 수 및 분당 요청 수를 사용하여 응답 시간을 더욱 정확하게 계산할 수 있습니다.

다음 공식을 사용하여 최대 로드 시 응답 시간(초)인 T_response를 결정합니다.

T_response = n/r - T_think

여기서,

n은 동시 사용자 수입니다.
r은 서버가 수신하는 초당 요청 수입니다.
T_think는 평균 인지 시간(초)입니다.

정확한 응답 시간 결과를 얻기 위해서는 항상 수식에 인지 시간을 포함해야 합니다.

예 2–1 응답 시간 계산

다음과 같은 조건이 있는 경우

최대 로드 시 시스템에서 지원할 수 있는 최대 동시 사용자 수 n은 5,000입니다.
최대 로드 시 시스템에서 처리할 수 있는 최대 요청 수 r은 초당 1,000입니다.

평균 인지 시간 T_think는 요청당 3초입니다.

즉, 응답 시간은 다음과 같이 계산됩니다.

T_response = n/r - T_think = (5000/ 1000) - 3초= 5 - 3초

따라서 응답 시간은 2초입니다.

특히 최대 로드 시 시스템 응답 시간을 계산한 후 응용 프로그램에 대한 허용되는 응답 시간과 비교합니다. 처리량과 함께 응답 시간은 Application Server의 성능에 있어 중요한 기본 요소 중 한 가지입니다.

분당 요청 수

지정된 시간의 동시 사용자 수, 해당 요청의 응답 시간 및 평균 사용자 인지 시간을 알고 있으면 분당 요청 수를 계산할 수 있으며, 일반적으로 시스템에 있는 동시 사용자 수 예측부터 시작합니다.

예를 들어 웹 사이트 성능 소프트웨어를 실행한 후 관리자는 온라인 은행 웹 사이트에서 요청을 제출하는 평균 동시 사용자 수가 3,000이라는 결론을 내립니다. 이 수치는 온라인 은행 회원으로 가입한 사용자 수, 사용자의 은행 업무 트랜잭션 동작, 사용자가 요청을 제출하려고 선택한 시간대나 요일 등에 따라 결정됩니다.

따라서 이 정보를 알고 있으면 이 절에 설명된 분당 요청 수에 대한 공식을 사용하여 시스템에서 이 사용자 기준에 따라 처리할 수 있는 분당 요청 수를 계산할 수 있습니다. 최대 로드 시 분당 요청 수와 응답 시간은 반비례하므로 응답 시간 향상을 위해 허용되는 분당 요청 수를 낮출 것인지 분당 요청 수를 높이기 위해 허용되는 응답 시간을 늦출 것인지를 결정합니다.

시스템 성능을 미세 조정할 시작점에서 허용되는 분당 요청 수 및 응답 시간 임계값을 시험합니다. 그런 다음 조정이 필요한 시스템 영역을 결정합니다.

이전 절의 수식에서 r은 다음과 같이 구할 수 있습니다.

r = n/(T_response + T_think)

예 2–2 분당 요청 수 계산

조건은 다음과 같습니다.

n = 2,800 동시 사용자
T_response = 1(요청당 평균 응답 시간 1초)
T_think = 3(평균 인지 시간 3초)

초당 요청 수는 다음과 같이 계산합니다.

r = 2800 / (1+3) = 700

따라서 초당 요청 수는 700이고 분당 요청 수는 42000입니다.

HADB의 로드 예측

HADB의 로드 계산에는 다음 요소를 고려합니다.

세션 지속성 구성에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 9 장, 고가용성 세션 지속성 및 페일오버 구성을 참조하십시오.

HTTP 세션 지속성 빈도

HADB에서 수신하는 분당 요청 수는 지속성 빈도에 따라 결정됩니다. 지속성 빈도는 Application Server가 HTTP 세션 데이터를 HADB에 저장하는 빈도를 결정합니다.

지속성 빈도 옵션은 다음과 같습니다.

web-method(기본값): 서버가 모든 HTTP 응답과 함께 세션 데이터를 저장합니다. 이 옵션을 사용하면 저장된 세션 정보가 최신 상태를 유지하지만 HADB에 트래픽이 높아집니다.
time-based: 세션이 지정된 시간 간격으로 저장됩니다. 이 옵션을 사용하면 HADB에 대한 트래픽이 감소하지만 세션 정보가 최신 상태를 보장할 수 없습니다.

다음 표는 지속성 빈도 옵션의 장점 및 단점에 대한 간략한 설명입니다.

표 2–1 지속성 빈도 옵션 비교


지속성 빈도 옵션	장점	단점
web-method	항상 최신 세션 정보를 사용할 수 있습니다.	응답 시간이 증가하고 처리량이 감소할 수 있습니다.
time-based	응답 시간이 향상되고 처리량이 향상될 수 있습니다.	Application Server 인스턴스에 오류가 발생한 뒤에 최신 세션 정보를 사용하지 못할 수 있습니다.

HTTP 세션 크기 및 범위

요청당 세션 크기는 세션에 저장된 세션 정보의 양에 따라 결정됩니다.

정보 –

전체 성능을 향상시키려면 세션 정보의 양을 최대한 줄이십시오.

지속성 범위 설정을 통해 요청당 세션 크기를 미세 조정할 수 있습니다. 다음 HTTP 세션 지속성 범위 옵션 중에서 선택합니다.

session: 서버에서 세션 정보를 HADB에 저장할 때마다 전체 세션 객체를 일련화하여 저장합니다.
modified-session: 세션이 수정된 경우에만 서버에서 세션을 저장합니다. Bean의 setAttribute() 메소드에 대한 호출을 가로채 수정을 감지합니다. 이 옵션은 내부 객체에 대한 직접 수정을 감지하지 않으므로 이 경우 setAttribute()를 명시적으로 호출하도록 SFSB를 코딩해야 합니다.
modified-attribute: 서버에서 세션이 마지막으로 저장된 이후 수정(삽입, 업데이트 또는 삭제)된 속성만 저장합니다. modified-session과 동일한 단점을 갖지만 제대로 적용될 경우 HADB 쓰기 처리량 요구 사항을 크게 줄일 수 있습니다.

이 옵션을 사용하려면 응용 프로그램이 다음을 충족해야 합니다.

세션 상태를 수정할 때마다 setAttribute() 또는 removeAttribute()를 호출합니다.
속성 간에는 상호 참조가 없어야 합니다.
여러 속성에서 세션 상태를 분배하거나 최소한 읽기 전용 속성 및 수정 가능한 속성 간에 세션 상태를 분배합니다.

다음 표는 지속성 범위 옵션의 장점 및 단점에 대한 간략한 설명입니다.

표 2–2 지속성 범위 옵션 비교


지속성 범위 옵션	장점	단점
modified-session	세션 상태를 수정하지 않고 요청에 대한 향상된 응답 시간을 제공합니다.	일반적으로 웹 메소드 `doGet()` 또는 `doPost()`를 실행하는 동안 응용 프로그램은 다음 세션 메소드를 호출해야 합니다. 속셩이 변경된 경우 `setAttribute()` 속성이 제거된 경우 `removeAttribute()`
session	응용 프로그램에 대한 제약 조건이 없습니다.	`modified-session` 및 `modified-attribute` 옵션에 비해 처리량과 응답 시간이 저하될 수 있습니다.
modified-attribute	수정된 세션 상태 비율이 낮은 요청에 대한 처리량과 응답 시간이 향상됩니다.	지정된 요청에 대해 수정된 세션 상태 비율이 60%에 가까우면 처리량과 응답 시간이 저하됩니다. 이 경우 속성을 개별 레코드로 분할하는 오버헤드 때문에 성능이 다른 옵션보다 더 저하됩니다.

Stateful Session Bean 검사점 지정

SFSB 세션 지속성의 경우 HADB의 로드는 다음에 따라 결정됩니다.

검사점 지정을 위해 활성화된 SFSB 수
검사점 지정을 위해 선택된 SFSB 메소드 및 사용 빈도
세션 객체 크기
트랜잭션 메소드

트랜잭션이 롤백되는 경우에도 검사점 지정은 일반적으로 SFSB 관련 트랜잭션이 완료된 후에 수행됩니다.

성능을 향상시키려면 검사점 지정을 위해 소수의 메소드 집합을 지정합니다. 검사점 지정되는 데이터 크기와 검사점 지정 빈도에 따라 지정된 클라이언트 상호 작용에 대한 응답 시간의 추가 오버헤드가 결정됩니다.