웹 계층 성능
이 콘텐츠에서는 웹 계층에 대한 성능 조정을 설명합니다.
casso127kkr
이 콘텐츠에서는 웹 계층에 대한 성능 조정을 설명합니다.
2
에이전트가 웹 또는 응용 프로그램 서버로 전송된 요청을 가로챌 때 에이전트는 정책 서버에 대해 다음 호출을 실행합니다.
- isProtected
- isAuthenticated
- isAuthorized
이러한 각 호출에 의해 웹 계층의 에이전트와 응용 프로그램 계층의 정책 서버 간에 트래픽이 생성됩니다. 다음 설정이 웹 계층의 성능을 조정하는 데 도움이 될 수 있습니다.
- 정책 서버 요청의 시간 만료 간격을 변경합니다.
- 에이전트가 정책 서버 연결에 사용할 수 있는 소켓 수를 변경합니다.
- 에이전트 캐시를 사용하여 에이전트가 정책 서버에 대해 수행하는 호출 수를 줄입니다.
다음 그림에 음영으로 표시된 항목에는 웹 계층의 성능에 영향을 주는 설정이 포함되어 있습니다.

서버 성능
지원되는 여러 웹 및 응용 프로그램 서버에 에이전트를 설치할 수 있습니다. 호스트 서버의 성능에 따라
Single Sign-On
웹 계층의 성능이 결정됩니다. Single Sign-On
과 함께 작동하는 웹 서버의 성능에 영향을 미치는 항목은 다음과 같습니다.- 웹 서버의 프로세서 속도
- 웹 서버의 메모리 양
에이전트 성능
에이전트 성능에 영향을 미치는 요소는 다음과 같습니다.
- 웹 또는 응용 프로그램 서버 CPU 및 사용 가능한 메모리
- 정책 서버 지연(정책 서버가 에이전트 요청에 응답하는 속도)
요청 수를 처리하는 데 사용할 수 있는 웹 서버의 수가 너무 적으면 다음과 같은 유형의 문제가 발생할 수 있습니다.
- 사용자 로그인이 지연되거나 불가능합니다.
- 사용자가 요청한 리소스를 수신할 때 지연이 발생합니다.
- CPU 사용량이 최대 용량이거나 최대 용량에 근접합니다.
최고 기간에 각 웹 또는 응용 프로그램 서버가 처리하는 요청 수를 예측하면 환경에 적합한 웹 서버 수를 결정하는 데 도움이 됩니다.
요청 수를 추정하려면 다음 방법 중 하나를 사용하십시오.
- 용량 계획을 세웁니다.
- 환경의 각 웹 에이전트에 대한Single Sign-On작업 보고서를 생성합니다.
- 웹 서버에 대한 성능 보고서를 생성합니다.자세한 내용은 웹 서버 공급업체에서 제공하는 설명서를 참조하십시오.
웹 계층 소켓 사용
에이전트가 시작될 때 정책 서버에서 호스트 구성 개체의 MinSocketsPerPort 매개 변수로 지정된 수의 소켓을 엽니다. 더 많은 요청이 수신되면 에이전트는 최대 소켓 수에 도달할 때까지 지정된 수의 새 소켓을 연결 풀에 추가합니다. 모든 소켓이 사용되면 다음 이벤트 중 하나가 발생할 때까지 추가 요청(최대 300개)이 큐에 유지됩니다.
- 소켓 쌍이 사용할 수 있게 되고 요청이 정책 서버로 전송됩니다.
- 요청 시간이 초과되고 사용자가 리소스 액세스를 다시 시도해야 합니다.
정책 서버의 호스트 구성 개체에는 사용되는 소켓의 수를 제어하는 매개 변수가 포함되어 있습니다.
부하가 높을 때 요청 시간 만료 간격 늘리기
네트워크가 다음 조건 중 하나라도 해당하는 경우 에이전트의 요청이 정책 서버 큐에 유지되는 시간을 늘리는 방법을 고려하십시오.
- 트래픽 양이 많음
- 연결 속도가 느림
정책 서버 호스트 구성 개체의 RequestTimeout 매개 변수는 에이전트가 정책 서버의 응답을 대기하는 시간을 제어합니다. 간격이 너무 짧으면 요청이 시간 만료되고 사용자에게 오류 메시지가 표시됩니다.
에이전트에서 사용 가능한 소켓의 양 늘리기
용량 계획의 추정에 따라 에이전트당 사용자 요청의 수가 특정 순간 60개(처리 중인 요청 20개 및 큐의 요청 40개)를 초과할 것으로 예상되는 경우에는
MaxSocketsPerPort
매개 변수의 값을 늘리십시오.관리 UI에서 MaxSocketsPerPort 매개 변수의 값을 늘린 후에는 정책 서버 관리 콘솔의 "최대 연결 수" 설정이 환경의 모든 에이전트 프로세스를 수용할 수 있을 정도로 충분히 높은지 확인하십시오. 이 설정에 따라 특정 정책 서버에서 사용할 수 있는 최대 연결 수가 결정됩니다.
참고
프리포크(pre-fork) 모드의 Apache 기반 서버와 같은 다중 프로세스 웹 서버의 경우 이 소켓의 수를 하나로 줄일 수 있습니다. 각 프로세스에서는 하나의 스레드만 사용하여 정책 서버와 통신하기 때문에 소켓이 하나만 필요합니다.NewSocketStep 설정 늘리기
최고 부하 상태에서 에이전트에 연결 풀의 추가 소켓이 필요한 경우 매번 가져오는 소켓의 수는 NewSocketStep 매개 변수에 의해 결정됩니다.
NewSocketStep 매개 변수의 값이 너무 낮게 설정되면 에이전트가 소켓 연결을 만드는 데 더 많은 시간이 소요되므로 최고 부하 상태의 응답 시간이 느려집니다.
응답 시간이 느려지는 것을 방지하려면 용량 계획을 통해 에이전트가 처리하는 요청의 수를 파악한 다음 그에 따라 NewSocketStep 매개 변수의 값을 늘리십시오.
이 매개 변수의 이상적인 값은 웹 또는 응용 프로그램 서버의 부하가 증가함에 따라 에이전트가 요청을 위한 소켓을 만드는 데 너무 많은 시간을 소비하지 않을 정도의 값입니다.
환경에서 가장 적합하게 작동할 때까지 여러 설정을 실험해 보는 것이 좋습니다.
참고
프리포크(pre-fork) 모드의 Apache 기반 서버와 같은 다중 프로세스 웹 서버의 경우 이 소켓의 수를 하나로 줄일 수 있습니다. 각 프로세스에서는 하나의 스레드만 사용하여 정책 서버와 통신하기 때문에 소켓이 하나만 필요합니다.포트당 최소 소켓 설정
에이전트가 시작될 때 정책 서버에서 호스트 구성 개체의 MinSocketsPerPort 매개 변수로 지정된 수의 소켓을 엽니다. 이 소켓은 정책 서버에 대한 지속적인 연결을 유지 관리합니다.
웹 및 응용 프로그램 서버 유형 대부분에 대해(Worker 모드의 Apache 기반 서버를 포함하여) 이 매개 변수를 기본 설정으로 두는 것이 좋습니다. 이 매개 변수를 늘리면 에이전트가 리소스 요청을 수신하지 않을 때도 소켓이 열려 있으므로 추가적인 소켓이 불필요하게 점유됩니다.
참고
프리포크(pre-fork) 모드의 Apache 기반 서버와 같은 다중 프로세스 웹 서버의 경우 이 소켓의 수를 하나로 줄일 수 있습니다. 각 프로세스에서는 하나의 스레드만 사용하여 정책 서버와 통신하기 때문에 소켓이 하나만 필요합니다.소켓 설정 간 관계의 예
사용 중인 웹 서버의 유형에 따라 정책 서버의 소켓 할당 매개 변수 간의 관계가 결정됩니다.
단일 프로세스 다중 스레드 웹 서버는 다중 프로세스 단일 스레드 웹 서버와 다르게 작동하므로 웹 서버 유형에 따라 정책 서버에서 소켓의 할당이 달라집니다.
웹 서버의 유형을 확인하려면 공급업체의 설명서를 참조하십시오.
다음 그림은 단일 프로세스 다중 스레드 웹 서버에 대한 공식을 보여 줍니다.

다음 그림은 다중 프로세스 단일 스레드 웹 서버에 대한 공식을 보여 줍니다.

다음 그림은 다중 프로세스 다중 스레드 웹 서버에 대한 공식을 보여 줍니다.

소켓 설정을 조정할 때 앞의 공식을 지침으로 사용하십시오.
에이전트와 정책 서버 간 트래픽 줄이기
에이전트에는 여러 개의 캐시 및 구성 매개 변수가 있으며 이를 함께 사용하여 에이전트와 정책 서버 간의 트래픽 양을 줄일 수 있습니다. 일반적으로 이러한 설정은 정책 및 URI가 대개 정적인 환경에서 가장 효율적입니다.
에이전트 캐시 작동 방식
Single Sign-On
에이전트는 정책 서버에 연결하기 전에 다음 캐시에서 필요한 정보를 검색합니다.- 리소스 캐시
- 세션 캐시
- 권한 부여 캐시
정책 서버에 연결하는 것보다 캐시에서 정보를 검색하는 것이 더 빠르기 때문에 성능이 향상됩니다. 다음 그림은 이러한 프로세스를 보여 줍니다.

리소스 캐시
각 에이전트는 리소스 캐시를 사용하여 정책 서버에서 받는 다음과 같은 정보를 임시로 저장합니다.
- 리소스가 보호되는지 여부
- 정책에 포함된 추가 응답 특성
에이전트는 리소스 캐시를 검색하여 정책 서버에 연결하기 전에 리소스가 보호되는지 여부를 확인합니다. 리소스가 캐시에 있을 경우 에이전트가 정책 서버에 대해 IsProtected 호출을 실행하지 않으므로 정책 서버에 대한 트래픽이 줄어듭니다.
리소스 캐시에는 두 가지 에이전트 구성 매개 변수가 영향을 줍니다.
Single Sign-On
배포를 계획할 때 다음 사항을 고려하십시오.- 리소스 캐시 시간 만료용량 계획 테스트 결과를 기반으로 에이전트 리소스 캐시의 시간 만료 간격을 지정하는 것이 좋습니다. 시간 만료 간격이 너무 작으면 리소스 캐시의 효율성이 제한됩니다. 에이전트 구성의 ResourceCacheTimeout 매개 변수 값이 리소스 캐시의 시간 만료 간격을 결정합니다.
- 리소스 캐시 시간 만료용량 계획 테스트 결과를 기반으로 에이전트 리소스 캐시의 시간 만료 간격을 지정하는 것이 좋습니다. 시간 만료 간격이 너무 작으면 리소스 캐시의 효율성이 제한됩니다. 에이전트 구성의 ResourceCacheTimeout 매개 변수 값이 리소스 캐시의 시간 만료 간격을 결정합니다.
리소스 캐시 및 URL 쿼리 문자열
URL 쿼리 문자열을 사용하는 응용 프로그램을 보호하려면 쿼리 문자열의 데이터를 무시하도록 웹 에이전트를 구성하여 리소스 캐시의 장점을 활용할 수 있습니다. 쿼리 문자열 데이터가 무시되면 잘려진 URL이 리소스 캐시에 저장됩니다. 웹 에이전트 구성의 IgnoreQueryData 매개 변수 값을 설정하여 쿼리 문자열을 무시할 수 있습니다.
중요!
URL 쿼리 데이터를 사용하는 정책이 있을 경우 이 설정을 활성화하지 마십시오.다음 표에서는 URL의 쿼리 문자열을 무시하여 리소스 캐시에서 해당 항목이 사용되는지, 아니면 웹 에이전트가 정책 서버에 연결해야 하는지 여부를 확인하는 방법을 보여 줍니다.
쿼리 문자열과 함께 요청된 URL
| 캐시에 저장된 잘린 URL
| 캐시된 항목이 사용됨
| 정책 서버가 연결됨
|
/exampleapplication/page1.html?user=firstuser | /exampleapplication/page1.html | 아니요 | 예 |
/exampleapplication/page1.html?user=seconduser | 예 | 아니요 | |
/exampleapplication/page2.html?user=seconduser | /exampleapplication/page2.html | 아니요 | 예 |
세션 캐시(인증)
각 에이전트는 세션 캐시를 사용하여 정책 서버가 이미 인증한 사용자의 인증 정보를 저장합니다.
에이전트는 인증을 위해 정책 서버에 연결하기 전에 세션 캐시를 검색하여 사용자가 인증되었는지 확인합니다. 세션 캐시는 정책 서버에 대한 인증 호출의 수를 줄여서 성능을 향상시킵니다.
사용자에 대한 인증은 다음 이벤트 중 하나가 발생할 때 종료됩니다.
- 사용자가 로그아웃합니다.
- 사용자와 관련된 세션이 만료됩니다.
- 캐시에 있는 항목의 기간이 60분을 초과합니다.
그러면 인증 정보가 세션 캐시에서 제거되고 삭제됩니다.
권한 부여 캐시
각 에이전트는 권한 부여 캐시를 사용하여 정책 서버가 이미 권한을 부여한 사용자의 권한 부여 ID를 저장합니다.
에이전트는 권한 부여를 위해 정책 서버에 연결하기 전에 권한 부여 캐시를 검색하여 사용자에게 권한이 부여되었는지 확인합니다. 권한 부여 캐시는 정책 서버에 대한 권한 부여 호출의 수를 줄여서 성능을 향상시킵니다.
사용자에 대한 권한 부여는 다음 이벤트 중 하나가 발생할 때 종료됩니다.
- 사용자가 로그아웃합니다.
- 사용자와 관련된 세션이 만료됩니다.
그러면 권한 부여 ID가 캐시에서 제거되고 삭제됩니다.
세션 및 권한 부여 캐시 설정
정책 서버 설정과 에이전트 구성 매개 변수의 조합을 통해 세션 캐시와 권한 부여 캐시를 제어할 수 있습니다. 용량 계획의 결과를 지침으로 사용하여
Single Sign-On
배포에서 다음 설정에 가장 적합한 값을 결정하십시오.- 세션 시간 만료다음과 같이 세션 시간 만료를 설정하는 것이 좋습니다.
- 최대 수의 사용자가 보호되는 응용 프로그램에 액세스하는 지속 기간에 맞춰 최대 세션 시간 만료를 설정하십시오.
- 유휴 세션 시간 만료를 다음 조건을 모두 충족하는 간격으로 설정하십시오.
- 사용자가 작업하는 동안 로그아웃되지 않을 정도로 충분히 긴 시간
- 사용자가 로그아웃하지 않고 컴퓨터에서 벗어나는 등 응용 프로그램이 사용되지 않을 경우 사용자를 자동으로 로그아웃하기에 충분할 정도로 짧은 시간
- 세션 캐시 크기세션 시간 만료 간격 중에 지속된 기간 동안 리소스에 액세스할 것으로 예상되는 사용자의 수를 기반으로 이 캐시의 크기를 지정하십시오. 크기 추정에 세션 시간 만료 기간 동안 로그아웃했다가 다시 로그인한 사용자를 포함하십시오. 요청 수가 비교적 적을 것으로 예상되는 사용자는 크기 추정에 포함하지 마십시오. 이러한 사용자는 세션 캐시 및 권한 부여 캐시에 거의 영향을 주지 않기 때문입니다. MaxSessionCacheSize라는 웹 에이전트 구성 매개 변수가 세션 캐시와 권한 부여 캐시 모두의 크기를 결정합니다.
캐싱 및 익명 사용자
Single Sign-On
이 제공하는 익명 인증 체계는 이 체계를 통해 보호되는 리소스에 대한 액세스 제어를 제공하지 않습니다
. 익명 인증 체계에서는 네트워크에서 식별되지 않은 사용자에 대해 다음 동작이 허용됩니다.- 사용자가 사이트로 돌아오는 빈도를 추적합니다.
- 특정 사용자가 사이트를 방문하는 동안 수행하는 작업(예: 사용자가 방문 중에 열어본 페이지)을 추적합니다.
- 특정 사용자를 위해 개인화된 콘텐츠를 표시합니다.
사용자가 익명 인증 체계로 보호되는 리소스를 요청하면 정책 서버는 GUID(전역 고유 식별자)를 할당하고 이를 관련된 사용자의 브라우저에 저장합니다.
Single Sign-On
은 이 GUID를 사용하여 사용자를 식별합니다.익명 인증 체계를 사용할 계획인 경우 다음 항목을 구현하면
Single Sign-On
환경에서 성능을 향상시킬 수 있습니다.- 익명 요청을 처리하는 웹 서버를 분리합니다.
- CacheAnonymous 매개 변수를 설정하여 익명 요청을 캐싱하도록 분리된 각 웹 서버에서 웹 에이전트를 구성합니다.
익명 사용자에 대해 별도의 웹 서버와 웹 에이전트를 사용하면 보호된 리소스에 대한 요청을 처리하는 다른 웹 서버의 캐시가 너무 자주 플러시되는 것을 방지할 수 있습니다.
웹 에이전트 성능에 영향을 미치는 다른 매개 변수
다음 매개 변수도 웹 에이전트 성능에 영향을 미칩니다.
- PSPollInterval
- IgnoreExt
- IgnoreURL
정책 서버 폴 간격 매개 변수
에이전트는 정책 서버에 주기적으로 연결하여 업데이트된 정책 또는 암호화 키를 수신합니다. 정책 서버에 연결하는 간격은 PSPollInterval 에이전트 구성 매개 변수를 변경하여 조정할 수 있습니다.
시간 간격을 늘리면 에이전트와 정책 서버 간의 불필요한 트래픽을 줄일 수 있습니다. 환경에 다음과 같은 특성이 있는 경우 간격을 늘리는 것을 고려하십시오.
- 에이전트의 수가 많은 경우
- 정책의 대부분이 정적이고 자주 변경되지 않는 경우
중요!
PSPollInterval 매개 변수를 늘리면 에이전트가 정책 변경을 실행하는 시간에도 영향을 줍니다. 예를 들어 해고된 직원에 대한 액세스 권한을 해지하도록 10시 30분에 정책을 변경하고 PSPollInterval 매개 변수의 값이 3600(초)이라고 가정합니다. 웹 에이전트는 11시 30분이 될 때까지 변경된 정책을 실행하지 않습니다.확장명 무시 매개 변수
Single Sign-On
으로 보호하려는 리소스에 보호를 원하지 않는
이미지나 파일이 많이 포함된 경우에는 특정 파일 확장명을 무시하도록 웹 에이전트를 구성하여 웹 에이전트와 정책 서버 간의 트래픽을 줄일 수 있습니다.웹 에이전트가 정책 서버에 대해 다음 호출을 하지
않으므로
성능이 향상됩니다.- IsProtected
- IsAuthenticated
- IsAuthorized
- 로그인
관련 리소스에 대한 요청이 직접 웹 서버로 전달되고 사용자에게 액세스 권한이 부여됩니다.
보호할 리소스를 먼저 식별하면 웹 에이전트에서 무시할 파일 확장명(있는 경우)을 결정하는 데 도움이 됩니다.
웹 에이전트 구성의 IgnoreExt 매개 변수에 무시할 파일 확장명을 추가합니다.
URL 무시 매개 변수
특정 하위 디렉터리의 리소스를 보호하지 않는 상태로 두려면 특정 URI(Uniform Resource Identifiers)를 무시하도록 웹 에이전트를 구성할 수 있습니다.
예를 들어 각 웹 서버에 pictures라는 하위 디렉터리가 있고 이 디렉터리를 보호하려면 웹 에이전트 구성에서 IgnoreURL 매개 변수를 설정할 수 있습니다.
웹 에이전트가 정책 서버에 대해 다음 호출을 하지
않으므로
성능이 향상됩니다.- IsProtected
- IsAuthenticated
- IsAuthorized
- 로그인
관련 리소스에 대한 요청이 직접 웹 서버로 전달되고 사용자에게 액세스 권한이 부여됩니다.
부하 분산을 통해 에이전트 성능 향상
에이전트와 정책 서버가 여러 개인 경우 동적 부하 분산을 적용하면 에이전트가 요청을 모든 정책 서버로 분산하므로 지연 시간이 감소하고 처리량이 향상됩니다. 동적 부하 분산을 통해 에이전트가 정책 서버에 보다 빠르게 액세스할 수 있게 되고 인증 및 권한 부여가 훨씬 효율적으로 수행됩니다.
Single Sign-On
은 다중 정책 서버와의 통신에 대한 소프트웨어 기반 장애 조치와 부하 분산 기능을 제공합니다. 호스트 구성 개체의 EnableFailover 매개 변수에서 다음 값 중 하나를 사용하여 웹 에이전트 연결의 처리 방법을 결정합니다.- 이 값을 yes로 설정하면 에이전트가 항상 호스트 구성 개체에 처음 나열된 정책 서버(왼쪽에서 오른쪽)에 연결을 시도합니다. 정책 서버가 여러 개 있는 경우 모든 에이전트가 첫 번째 정책 서버에 연결을 시도합니다. 목록의 첫 번째 서버를 사용할 수 없는 상태가 아니라면 목록의 다른 서버에 연결되지 않습니다. 일부 정책 서버가 많은 연결을 처리하고 다른 정책 서버는 훨씬 적은 수의 연결을 처리한다는 점에서 대규모 환경에서는 이 구성이 부하 분산보다 효율성이 떨어집니다.
- 이 값을 no로 설정하면 부하 분산이 사용됩니다. 에이전트가 호스트 구성 개체에 나열되어 있는 모든 정책 서버에 라운드 로빈 방식으로 요청을 분산시킵니다. 다중 정책 서버를 사용할 경우 더 높은 처리량을 얻으려면 이 설정을 사용하는 것이 좋습니다. 부하 분산 정책 서버 중 하나를 사용할 수 없어도 장애 조치는 계속 수행됩니다.
또한,
Single Sign-On
은 에이전트 및 정책 서버 간의 연결에서 고성능 동적 부하 분산을 제공하는 하드웨어 부하 분산 장치를 사용할 수 있도록 지원합니다. 가상 IP 주소를 통해 다중 정책 서버를 노출하도록 구성한 경우 하드웨어 부하 분산 장치가 해당 가상 주소에 연결된 모든 정책 서버 간 부하 분산을 처리합니다. 에이전트가 장애 조치나 부하 분산을 처리할 필요가 없으므로 EnableFailover 매개 변수를 yes로 설정하여 Single Sign-On
부하 분산이 사용되지 않도록 설정합니다. 호스트 구성 개체에서 정책 서버 그룹을 노출하는 단일 또는 다중 VIP를 구성합니다.다중 스레드 웹 및 응용 프로그램 서버에서 장애 조치 및 부하 분산
Sun Java System, IIS, 작업자 모드의 Apache 기반 서버, WebSphere 응용 프로그램 서버 등과 같은 다중 스레드 웹 및 응용 프로그램 서버에서 실행되는 에이전트는 시작 시 정책 서버에 대해 최소 개수의 소켓을 엽니다.
정책 서버 간 장애 조치나 부하 분산이 수행되도록 환경을 구성한 경우 에이전트는 시작 시 각 정책 서버에 대해 최소 개수의 소켓을 엽니다. 부하 분산 정책 서버의 경우 각 정책 서버가 전체 요청의 절반만 처리하기 때문에 각 정책 서버에 대해 훨씬 적은 수의 소켓이 열리지만 정책 서버에 대한 연결은 동일한 방식으로 처리됩니다.
장애 조치가 구성되어 있고 에이전트와 기본 정책 서버 간에 오류가 발생하면 장애 조치 정책 서버에 대한 연결이 사용됩니다. 장애 조치는 서비스별로 발생하기 때문에 기본 정책 서버와 장애 조치 정책 서버 모두에 대한 연결이 동시에 활성화될 수 있습니다. 기본 정책 서버가 복구된 후에도 장애 조치 서버에 대해 열린 소켓이 그대로 유지됩니다. 모든 새 소켓은 기본 정책 서버에 대해 열립니다.
다중 프로세스 웹 및 응용 프로그램 서버에서 장애 조치 및 부하 분산
프리포크(pre-fork) 모드의 Apache 기반 서버와 같은 다중 프로세스 웹 또는 응용 프로그램 서버에서 실행되는 에이전트는 장애 조치가 발생했는지 여부와 관계없이 구성된
모든
정책 서버에 대해 동일한 수의 연결을 엽니다.자식 프로세스마다 정책 서버에 대한 고유한 연결이 있기 때문에 장애 조치가 발생할 경우 각 자식에 대해 독립적으로 처리됩니다. 결과적으로 장애 조치가 발생하면 각 소켓에서 500 오류가 발생합니다. 기본 정책 서버가 복구된 후에도 장애 조치 서버에 대해 열린 소켓이 열린 상태로 그대로 유지됩니다. 모든 새 소켓은 기본 정책 서버에 대해 열립니다.
웹 서버, 웹 에이전트 및 웹 서버 프로세스
각 에이전트마다 자체 웹 서버 인스턴스가 필요합니다. 예를 들어 IIS 웹 서버는 IIS 웹 서버가 설치된 컴퓨터의 단일 인스턴스를 사용하여 작동합니다. IIS 에이전트의 수는 IIS 웹 서버의 수와 동일합니다.
컴퓨터 한 대에 여러 인스턴스를 지원하는 다른 웹 서버의 경우 각 인스턴스별로 하나의 에이전트를 설치하고 구성할 수 있습니다. 예를 들어 하나의 컴퓨터에서 세 개의 개별적인 웹 서버 인스턴스를 실행하는 경우가 있습니다. 각 인스턴스마다 자체 에이전트가 있습니다. 따라서 하나의 컴퓨터에서 세 개의 에이전트가 작동합니다.
Apache 웹 서버의 경우 다음과 같은 MRM(다중 처리 모듈)이 에이전트 프로세스가 정책 서버에 연결하는 방식에 영향을 미칩니다.
- 프리포크(pre-fork) 모드추가 요청을 처리할 자식 프로세스를 생성합니다.
- Worker 모드추가 요청을 처리하기 위해 연결 풀에서 추가 스레드를 가져옵니다.
Apache 기반 웹 서버 Worker 모드를 사용하는 웹 에이전트 및 정책 서버의 상호 작용
Worker 모드의 Apache 기반 웹 서버는 스레드를 사용하여 정책 서버 연결을 처리합니다. 부하가 높을 때 정책 서버에 대한 추가 연결을 생성하기 위하여 연결 풀에서 필요에 따라 스레드를 가져옵니다.
다음 그림은 이러한 프로세스를 보여 줍니다.

Apache 기반 웹 서버 프리포크(Pre-Fork) 모드를 사용하는 웹 에이전트 및 정책 서버의 상호 작용
프리포크(Pre-Fork) 모드의 Apache 기반 웹 서버가 요청을 수신하면 웹 서버는 정책 서버와 통신하기 위해 자식 프로세스를 생성합니다. 더 많은 요청이 수신될수록 이를 처리하기 위해 더 많은 자식 프로세스가 생성됩니다. Apache 기반 웹 서버가 생성한 각 자식 프로세스는 정책 서버에 대하여 고유한 독립적인 연결을 갖습니다.
다음 그림은 이러한 프로세스를 보여 줍니다.

Apache 기반 웹 서버의 경우 httpd.conf 파일에 있는 MaxClients 매개 변수의 값에 따라 웹 서버에서 생성하는 자식 프로세스의 수가 결정됩니다. Apache 기반 웹 서버의 부모 프로세스가 자식 프로세스를 생성할 때 자식 프로세스는 정책 서버에 대한 초기 연결을 엽니다.
웹 에이전트의 수와 웹 에이전트 프로세스의 수 사이에는 중요한 차이가 있습니다. 각 웹 에이전트마다 자체 웹 서버 인스턴스가 필요합니다. 예를 들어 IIS 웹 서버는 단일 인스턴스로만 작동하기 때문에 IIS 웹 에이전트의 수는 IIS 웹 서버의 수와 동일합니다. 다른 유형의 서버에는 하나의 물리적 웹 서버 내에서 여러 포트를 수신하는 여러 서버 인스턴스가 있을 수 있습니다.
Apache 기반 웹 서버에서 정책 서버로 열린 최대 소켓 수는 MaxClients 매개 변수의 값에 웹 에이전트 프로세스 수를 곱한 값과 같습니다. 예를 들어 서버의 MaxClients 매개 변수 값이 150으로 설정되어 있고 웹 에이전트 프로세스가 다섯 개인 경우에 가능한 열린 소켓 수의 최대값은 750입니다.
다중 프로세스 웹 서버를 사용하면
Single Sign-On
환경에서 정책 서버에 대한 웹 에이전트 프로세스의 비율에 영향을 미칩니다. 초당 트랜잭션 수가 아니라 웹 에이전트 프로세스와 정책 서버 간의 연결 수가 제한 요소가 되는 경우가 많습니다.웹 에이전트를 배포하기 전에 요청을 수신하는 정책 서버가 관련 웹 서버가 열 수 있는 최대 연결 수를 처리할 수 있는지 확인하십시오.