[z/OS]

최적화된 로컬 어댑터 성능 고려사항

z/OS® 용 WebSphere® Application Server 최적화 로컬 어댑터 API를 사용하는 경우, 성능과 관련하여 고려해야 할 여러 영역이 있습니다.

최적화된 로컬 어댑터 API는 외부 주소 공간과 z/OS용 WebSphere Application Server 의 애플리케이션 간 호출을 위한 최적의 성능을 제공하도록 설계되었으며, 이러한 환경에서 애플리케이션 간의 세분화된 상호작용을 지원하는 새로운 종류의 애플리케이션 패턴을 설정할 것으로 예상됩니다. 다음 정보는 최적화된 로컬 어댑터 및 성능에 관련하여 알고 있어야 하는 문제에 대해 설명합니다. 이 컨텐츠는 최고의 성능을 위해 최적화된 로컬 어댑터를 사용하는 구성 옵션을 이해하는 데 도움이 되도록 디자인되었습니다. WebSphere Application Server 와 HTTP를 통한 SOAP와 같은 동일한 시스템의 외부 주소 공간 간의 동기 호출을 위해 최적화된 로컬 어댑터를 다른 기술과 비교하는 벤치마크 결과는 여기에 설명되어 있지 않습니다. 이 정보는 z/OS 용 WebSphere Application Server 성능 보고서를 읽으십시오.

등록 API 호출에 대해 연결 최소 및 최대 연결 값을 선택하십시오.

등록 API 호출에서 연결 매개변수에 대해 너무 높은 값으로 최소 값을 선택하는 것은 권장되지 않으며 성능을 저하시킬 수 있습니다. 이로 인해 외부 주소 공간에서 WebSphere Application Server 제어 영역으로 호출하여 각 연결을 설정하고 등록 API 호출 중에 이를 최적화된 로컬 어댑터 연결 풀에 추가합니다. 이 연결이 서버와 설정되면 연결은 WOLA가 서버에서 연결을 끊고 이를 사용 가능 연결 풀에서 제거하는 등록 해제 API 호출이 수신될 때까지 유지됩니다. 최소 값을 너무 높게 설정하면 메모리가 너무 많이 소모되고 등록 및 등록 해제 API에 경로 길이 비용을 추가합니다. 요구사항에 가장 적합한 최소 연결 값을 선택하십시오. 잠재적으로 수백 개의 동시 스레드 공유 등록이 있는 경우에는 예외이며 등록 중에 연결 비용을 지불하는 것이 적절합니다. 등록을 공유하는 동시 스레드의 예상 수가 낮으면 최소 연결 값을 낮게 설정하도록 권장됩니다.

최대 연결 등록 API 매개변수는 등록을 위한 최적화된 로컬 어댑터의 연결 수에 대한 경계를 제공합니다. 이는 등록 수명에는 확장 가능하지 않습니다. 동시 연결 가져오기 요청 수가 이 값을 초과하면 호출 스레드는 연결이 사용 가능해지기 위한 연결 가져오기, 호출, 모든 요청 수신 또는 호스트 서비스 API에 대한 대기 시간 매개변수에 지정된 시간(초) 동안 대기합니다. 이 시간이 지나면 리턴 및 이유 코드가 다시 전달되고 이는 연결 핸들을 대기 시간 만기 전에 요청에 대해 확보하지 못했음을 나타냅니다. 설정 가능한 모든 단일 등록에 대한 연결 풀의 최대 크기가 있습니다. 이 값은 셀 전반의 환경 변수인 WAS_DAEMON_ONLY_adapter_max_conn에서 파생됩니다. 이 변수에 대해 제공되는 기본값은 100입니다. 값은 관리 콘솔을 사용하여 변경 가능합니다. 설정이 변경된 후 디먼을 다시 시작해야 합니다.

최적화된 로컬 어댑터 CICS 링크 서버에서 연결 최소 및 최대 설정의 영향

고객 정보 제어 시스템 (CICS®) 에서 링크 서버 태스크를 시작할 때 (BBOC START_SRVR 사용), 최소 연결 (MNC) 및 최대 연결 (MXC) 매개변수가 전달되지 않으면 MNC 레지스터 설정은 기본적으로 1 로 설정되고 MXC는 기본적으로 10으로 설정됩니다. 이는 시작 가능하고 링크 서버(BBO$) 태스크를 시작하여 동시에 실행 가능한 호출 태스크(BBO# 태스크) 링크 수가 10임을 나타냅니다. 이는 CICS 대상 프로그램을 실행하고 시작할 수 있는 WebSphere Application Server 의 동시 스레드 수로 변환됩니다. MMXC 링크 서버 매개변수의 설정은 링크 서버의 이 인스턴스에서 시작될 것으로 예상되는 일반 대상 CICS 프로그램의 예상 지속 기간을 반영해야 합니다. 대상 CICS 프로그램이 대부분 장기 실행 중인 경우, 더 큰 MXC값은 WebSphere Application Server 에서 CICS로 효율적으로 플로우되는 요청을 유지하는 데 적합합니다. 대상 프로그램이 단기 실행인 경우, 더 낮은 MXC 설정이 더 효율적입니다.

올바른 MXC 설정을 판별하려면 특정 등록 이름으로 링크 서버와 통신하는 WebSphere Application Server 하위 (servant) 영역의 수도 고려해야 합니다. 단일 하위 (servant) 영역이 있고 스레딩 옵션을 ISOLATE 로 설정하여 실행 중인 경우, 단일 스레드만 해당 하위 (servant) 에서 한 번에 CICS 로 전송할 수 있으므로 MXC값은 병목 현상이 없도록 하위 (servant) 수에 1을 곱한 값으로 설정됩니다. 스레딩이 LONGWAIT로 설정되어 실행 중인 경우 (여기서 하위 (servant) 당 최대 40개의 스레드가 활성화될 수 있음), 호출되는 CICS 프로그램의 예상 요청 수 및 유형 (장기 실행 또는 단기 실행) 에 따라 MXC는 특정 등록 이름에 대해 실행 중인 링크 서버에 대한 하위 (servant) 에서 예상되는 동시 요청 수에 따라 설정되어야 합니다. 최적의 MXC 설정을 판별하려면 실험이 조금 필요할 수 있습니다. 낮은 숫자로 시작해서 단계적으로 이를 올려 처리량이 최고에 도달하면 해당 값으로 설정하십시오.

공유 64비트 메모리

최적화된 로컬 어댑터 지원을 사용하려면 z/OS 용 WebSphere Application Server 서버가 64비트모드에서 실행되어야 합니다. true 또는 1로 설정된 WAS_DAEMON_ONLY_enable_adapter값을 사용하여 디먼 그룹이 처음 시작되면 WebSphere Application Server 는 BAR 스토리지 위의 64비트에 공유 메모리 버퍼를 할당하고 이를 초기화합니다. 이 영역의 기본 크기는 32MB입니다. 이는 최적화된 로컬 어댑터 공유 제어 구조 모두가 상주하는 위치입니다. 메시지 데이터가 캐시되는 위치는 아닙니다. 메시지 및 컨텍스트 데이터는 서버 주소 공간에 메시지 데이터를 스테이징하는 z/OS 용 WebSphere Application Server 로컬 통신 주소 공간 간 기술을 사용하여 외부 주소 공간과 WebSphere Application Server 하위 (servant) 영역 간에 플로우됩니다. 큰 메시지인 경우 이는 64비트의 above-the-bar 스토리지에 있습니다. 현재 WebSphere Application Server 로컬 통신은 최대 메시지 크기 2GB 를 지원하며 초기 최적화 로컬 어댑터 지원에서는 단일 메시지에 대해 지원되는 최대 크기입니다.

잘못된 애플리케이션이 계속 등록 API를 호출하고 등록 해제 및 종료(자동으로 정리되는) 호출 없이 루프되는 경우 디먼 그룹에 대해 최적화된 로컬 어댑터 공유 메모리 버퍼를 오버플로우할 수 있습니다. 발생하는 경우 API 호출이 메모리 부족 이유 코드와 같이 리턴됩니다. 이 상황을 진단하려면 영향을 받는 디먼 그룹의 WebSphere Application Server 서버 중 하나에서 다음 명령을 실행하십시오.
F <server_name>,DISPLAY,ADAPTER,REGISTRATIONS 	 	
표시 출력에서 이용 중이며 등록을 릴리스하지 않는 작업을 판별하고 이를 다시 시작하여 문제점을 정정할 수 있습니다.

분석 후에 기본값 32MB가 디먼 그룹의 요구사항에 비해 너무 작다고 판별되는 경우, 이 값은 WAS_DAEMON_ONLY_adapter_max_shrmem 셀 전반 환경 변수를 사용하여 변경할 수 있습니다. 이 값의 변경은 주의해서 수행해야 합니다. above-the-bar 메모리 버퍼를 공유하는 최적화된 로컬 어댑터를 다시 작성해야 하며 이는 시스템의 IPL을 사용해서만 수행할 수 있습니다.

필요한 메모리 크기를 대략적으로 예상할 수 있습니다. 각 클라이언트 등록에는 공유 메모리가 392바이트 필요하고 112바이트가 각 연결에 대한 공유 메모리로 필요합니다. 최대 100개의 연결이 포함되는 등록은 약 12KB의 공유 메모리가 이용됩니다. 연결이 사용 가능해지길 대기해야 하는 각 클라이언트 스레드(모든 연결이 사용 중인 경우)는 각 클라이언트 스레드는 추가로 80바이트가 필요합니다. 등록으로 호스트 중인 각 서비스는 추가로 336바이트를 이용합니다.

예를 들어, 디먼 그룹에 200개의 등록이 있다고 가정해 보십시오. 각 등록에는 200개의 연결이 있고 언제든지 최대 1000개의 스레드가 연결을 대기 중입니다. 이 구성에서 이용되는 최대 메모리는 20MB입니다. 그러면 약 38,000개의 서비스를 동시에 호스트하거나 등록당 190개의 동시 서비스를 호스트하기에 충분한 공유 메모리가 있게됩니다.
200 Registrations x 392 bytes=78,400 bytes 		
200 Registrations x 200 connections x 112 bytes=4,480,000 bytes 		
200 Registrations x 1000 waiters x 80 bytes= +	16,000,000 bytes 							 	
-------------------------------- 									
20,558,400 bytes 	 		


33,554,432 bytes – 20,558,400 bytes=12,996,032 bytes remaining 							     
/	     336 bytes per service 							     
---------------------------------- 								        
38,678 Services 
공유 메모리 크기를 늘리거나 줄이는 경우 above-the-bar 공유 메모리는 1MB 섹션으로 할당됩니다. WebSphere Application Server 는 사용자가 지정하는 값을 가장 가까운 MB로 반올림합니다.

WebSphere Application Server 에서 동시 아웃바운드 호출의 최대 수 제어

최적화된 로컬 어댑터에서 지원되는 단일 등록을 위해 WebSphere Application Server 호출로부터의 최대 동시 아웃바운드 수를 제어하는 디먼 전체의 기본 설정이 있습니다. 이를 제어하는 값은 WAS_DAEMON_ONLY_adapter_max_serv입니다. 기본값은 100입니다. 이는 단일 등록에서 최대 100개의 다른 서비스가 실행될 수 있다는 의미입니다(동시 호스트 서비스, 모든 요청 수신 또는 특정 요청 수신 API 호출). 이 값이 변경되면 디먼을 다시 시작해야 합니다.

기본값인 100을 사용하여 이런 용도로 세 API 중 하나를 사용해서 특정 등록 이름에 대해 101번째 서버로 스레드를 설정하면 0이 아닌 리턴값이 리턴되고 adapter_max_serv에 도달했음을 나타내는 이유 코드가 수신됩니다. WebSphere Application Server 의 애플리케이션이 이 서비스를 찾고 즉시 사용할 수 없는 경우, 애플리케이션은 요청된 서비스를 기다리는 중에 제한시간 초과가 발생했음을 표시하는 예외를 수신하기 전에 기본값 30 초 동안 대기합니다. WebSphere Application Server 하위 (servant) 로그에서 이는 C9C24C15 부 코드로 표시됩니다. 이 제한시간의 기본 30 초는 애플리케이션이 JCA ( Java™ EE Connector Architecture) ConnectionSpecImpl에서 setConnectionWaitTimeout() 메소드를 사용하여 수정할 수 있습니다.

최적화된 로컬 어댑터 CICS 링크 서버 성능 고려사항

CICS 링크 서버에 대한 최적화된 로컬 어댑터 지원을 사용하여 WebSphere Application Server for z/OS에서 실행 중인 애플리케이션에서 기존 CICS 애플리케이션 프로그램을 호출하는 간단한 방법을 제공할 수 있습니다. BBOC 트랜잭션 또는 CICS PLTPI 프로그램 BBOACPL2를 사용하여 링크 서버를 시작할 때, 최적화된 로컬 어댑터 링크 서버 태스크 (BBO$) 가 시작되고 WebSphere Application Server에서 프로그램 링크 요청을 수신합니다. 그런 다음 프로그램 링크 태스크 (BBO#) 가 시작되어 대상 프로그램에 EXEC CICS LINK를 실행하고 응답을 수신하여 WebSphere Application Server 호출자에게 다시 전송합니다. 이 지원의 일부에는 WebSphere Application Server 애플리케이션 스레드 레벨 ID를 대상 CICS 태스크에 전파하고 어설션하는 것이 포함됩니다. ID의 전파 및 어설션은 BBOC START_SRVR 명령에서 SEC=Y 매개변수를 사용하여 요청됩니다.

SEC=N으로 링크 서버를 실행하고 링크 서버를 시작한 사용자 ID의 ID 사용으로 성능은 향상되지만 보안 및 조직의 감사 요구사항에 맞지 않을 수 있습니다.

링크 서버가 SEC=N으로 실행 가능한 것으로 판별되면 최고의 성능은 REU=Y BBOC START_SRVR 매개변수도 실행하여 얻을 수 있습니다. REU=Y는 링크 서버가 프로그램 링크 호출 태스크(BBO# 트랜잭션)를 프로그램 호출 요청 사이에서 다시 사용하도록 합니다.
중요: 이 구성에서 링크 서버를 실행하는 경우, 개별 요청에 대해 별도의 LINK 트랜잭션 ID를 전달하기 위한 최적화된 로컬 어댑터 JCA의 지원이 사용 불가능하며 이에 대한 요청으로 인해 ResourceException 이 애플리케이션으로 다시 전달됩니다. 또한, REU=Y 및 SEC=Y 선택을 시도하면 재사용 옵션이 어설션되어 전파된 ID를 사용하여 각 요청에 대한 새 프로그램 링크 태스크를 링크 서버가 시작하도록 강제로 No로 설정됩니다.

REU=Y 옵션을 실행하면 프로그램 링크 태스크(BBO#s)는 시작된 이후 계속 활성화되며 BBOC STOP_SRVR 또는 BBOC UNREGISTER가 등록에 대해 입력됩니다. BBOC START_SRVR에서 높은 MXC 값으로 실행하고 많은 수의 요청이 동시에 도착하는 경우 BBO# 태스크 수는 높아지고 이는 링크 서버가 중지될 때까지 종료되지 않습니다. 이는 REU=Y 사용 여부 및 적절한 MXC 값 결정 시에 고려해야 하는 또 다른 문제입니다.

목표가 WebSphere Application Server에서 CICS 하의 애플리케이션으로 호출하기 위한 가장 빠른 성능을 달성하는 것인 경우, 애플리케이션 프로그램에서 직접 호스트 서비스 (BBOA1SRV), 모든 요청 수신 (BBOA1RCA) 또는 특정 요청 수신 (BBOA1RCS) API를 코딩하는 것을 고려하십시오. 그러면 링크 서버가 제공하는 ID 전파에 대한 기본 제공 지원이 없지만, 필요하지 않고 성능 우선순위가 충분히 높은 경우 API를 직접 사용하는 것이 최선의 옵션입니다.

JCA 고려사항

최적화된 로컬 어댑터 JCA 자원 어댑터를 사용하는 경우, ConnectionFactory 오브젝트에서 확보되는 각 연결에 대한 추가 오버헤드가 있습니다. 애플리케이션이 동일한 애플리케이션 메소드에서 외부 주소 공간 또는 CICS 를 여러 번 호출해야 하는 경우 각 상호작용에 대해 동일한 연결을 사용하면 각 상호작용에 대해 서로 다른 연결을 확보하는 것보다 더 잘 수행됩니다. 또한, JCA 상호작용 오브젝트는 동일한 애플리케이션 메소드에서 반복적으로 사용 가능합니다.

최적화된 로컬 어댑터에 대해 JCA ConnectionFactory를 작성하는 경우, 해당 ConnectionFactory에 대한 JCA 연결 풀의 최소 및 최대 크기를 수정할 수도 있습니다. 이 연결 풀은 논리 연결을 나타내며 이는 통합 중에 실제 연결(BBOA1REG 등록 호출에 지정)에 바인드됩니다. 최적의 성능을 위해 JCA 연결 풀 크기는 BBOA1REG 중에 설정되는 실제 연결 풀과 크기가 동일해야 합니다. JCA 연결 풀이 너무 작게 설정되면 애플리케이션은 사용 가능한 실제 연결이 있더라도 JCA 연결 오브젝트를 대기해야 할 수도 있습니다. 실제 연결 풀은 모든 하위(servant) 리젼에서 공유되기 때문에 여러 개의 하위(servant) 리젼이 있는 경우 각 하위(servant) 리젼에 대한 JCA 연결 풀 크기를 줄여서 실제 연결 풀 크기와 비슷하게 모든 하위(servant) 리젼에서 전체 JCA 연결 수가 유지되도록 할 수도 있습니다.