![닫기 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
이 기사는 IBM® Rational® Performance Tester 환경을 준비하기 위한 세 가지 부분으로 구성되어 있다. 첫 번째 섹션에서는 Rational Performance Tester 로드 생성 환경을 배치하기 위한 메소드와 방지할 배치 패턴에 관한 정보에 대해 학습할 것이다. 두 번째 섹션에서는 최적화 성능 테스트 로드 생성 및 운영 체제 성능을 증진시키는 튜닝 매개변수에 대해 학습할 것이다. 마지막 섹션에서는 성공적인 성능 테스트를 실행하기 위해 성능 테스트를 시작하기 전에 독자가 수행할 수 있는 내용에 대한 정보가 들어있다.
채택하고 방지하기 위한 Rational Performance Tester 배치 사례
Rational Performance Tester 로드 생성 환경을 배치하기 위한 다음 제안을 고려하자.
- 로우엔드(low-end) 구성(CPU의 수와 메모리 양의 측면에서)으로 많은 에이전트 머신을 사용하고
이러한 머신이 로드를 생성하도록 한다. 하이엔드(high-end) 구성으로 에이전트 머신을 더 적게
사용하면, 운영 체제는 사용 가능한 총 소켓의 수, 병렬 처리 및
멀티스레딩에 대한 한계로 제한된다. 따라서 적은 수의 하이엔드 머신에서 에이전트를 수직으로
규모 조정하는 것이 아니라 성능 테스팅을 위해 수평으로 규모 조정하는 로우엔드 구성으로
에이전트 머신을 많이 사용한다.
참고:
로우엔드 구성 머신은 CPU 및 메모리의 수가 적은 것이다. 하지만, CPU 속도는 낮은 구성으로 고려되어서는 안 된다. Rational Performance Tester 에이전트 머신에 대한 권장 CPU 속도는 2.33GHz 이상이다.
그림 1. 로드 생성 환경을 설계하는 면에서 다른 토폴로지의 비교
- 테스트 에이전트가 가상 환경에 있다면 성능 테스트 에이전트 소프트웨어가 설치된
머신에서 논리적 파티션이 전용 실제 이더넷 컨트롤러를 보유하여 높은 볼륨 네트워크
트래픽을 지원하도록 한다.
중요:
논리적 호스트 이더넷 어댑터 또는 가상화된 이더넷 디바이스를 Rational Performance Tester 에이전트 논리적 파티션에서 성능 테스트 에이전트 서비스를 실행하는 논리적 파티션에 대한 네트워킹 인터페이스로 사용하지 말자. - 모든 에이전트가 컨트롤러 및 성능 테스트 설정과 동일한 네트워크에 위치하도록 한다. 이렇게 하면 최소 네트워크 지연이 있음을 보장하고 기간 통계, 테스트 자산 및 호스트 제어기와 에이전트 머신 사이에 데이터를 더 빠르게 전송할 수 있다.
처음 두 가지 토폴로지는 그림 2와 3에 시연된다. 이는 Rational Performance Test 환경을 배치하기 위해 채택할 수 있는 우수 사례이다.
토폴로지 1: 솔루션을 성능 테스트하기 위한 우수 메커니즘
성능 테스팅 도중에 테스트되는 솔루션과 동일한 네트워크에서 로드 생성 환경을 호스트해야 하므로 로드 생성 환경과 솔루션 사이에 최소 네트워크 지연이 있다. 네트워크 지연을 최소화한 후에 성능 병목현상을 진단하는 것이 더 간편할 뿐만 아니라 문제해결하기에 어려울 수 있고, 서버가 제대로 운영 중임에도 불구하고 트랜잭션 오류가 나타날 수 있는 패킷 삭제 및 네트워크 오류가 줄어든다.
그림 2. 성능 테스트 환경을 위한 첫 번째 토폴로지
토폴로지 2: Rational Performance Tester 호스트 제어기는 솔루션 네트워크의 외부에 있지만 성능 테스트 에이전트는 내부에 있다
이 토폴로지는 이전 것과 거의 유사하다. 여기에서는 네트워크 파이프의 대역폭과 Rational Performance Tester를 호스트하는 서버의 네트워크 카드 등의 다양한 네트워크 문제로 인해 호스트 제어기와 해당 에이전트 사이에 통신 문제가 있을 수 있을 수 있다. 이를 통해 이 메커니즘의 단점은 다음 상황에서 성능 테스트의 원활한 실행을 방지하는 문제점에서 주로 확인된다.
- 성능 테스트의 일반적인 실행이 실행되거나 대규모 지속 기간 동안 성능 테스트의
실행이 실행된다 / 내구성 성능 테스트는 몇 일 동안 빠른 샘플링 비율로 실행된다
- 로드 생성 용도에 참여한 많은 테스트 에이전트들이 있다. 약 25개 이상의 테스트 에이전트들이다.
호스트 제어기와 에이전트 사이에 네트워크 연결과 대역폭이 균등하지 않으면 통신 오류를 야기할 수도 있고(네트워크 패킷 손실) 더 나아가 성능 테스트의 비정상 종료를 초래한다. 다음과 같은 오류가 나타날 수 있다.
- "Workbench did not receive any message from Agent for more than
xxmilliseconds" - "Could not connect to Agent. Connection timed out"
그림 3. 성능 테스팅을 위한 두 번째 토폴로지
Rational Performance Tester 환경을 배치할 때 그림 4와 5에 시연된 토폴로지 패턴을 피하자.
패턴 1: Rational Performance Tester 에이전트가 솔루션 컴포넌트와 동일한 하드웨어에 배치된다
성능 테스팅의 이러한 토폴로지가 성능 테스트 에이전트와 솔루션 사이에 최소 네트워크 지연을 보장한다고 해도, 운영 체제 자원은 솔루션과 성능 테스트 환경 사이에 공유된다. 이 경우에 자원 활용 분석은 솔루션 환경과 성능 테스트 환경 사이에 동일한 운영 체제의 자원 활용을 차별화하는 면에서 수반된 극도의 복잡성으로 인해 매우 어려워진다. 부정확한 분석으로 인해 성능 문제 식별, 분석 및 문제 해결에 대한 부정확한 데이터를 초래한다. 따라서, 이러한 토폴로지는 성능 테스트 환경 배치에 권장되지 않는다.
다음 운영 체제 자원을 고려한다.
- 프로세서 사용
- 메모리 사용
- 솔루션 컴포넌트와 에이전트 프로세스 둘 다를 위한 TCP/IP 소켓
- 솔루션 컴포넌트와 에이전트 프로세스 둘 다에 초당 전송 및 수신된 바이트의 수를 포함한 네트워크 대역폭
참고:
솔루션 컴포넌트에서 성능
테스트 에이전트를 배치하는 것은 운영 체제 계층에서 사용 가능한
TCP/IP 소켓의 사용뿐만 아니라 프로세스, 메모리 및 네트워크 대역폭
활용에도 영향을 준다.
Rational Performance Tester는 성능 테스트 로드 생성 도중에 작성한 요청에 대한 연결을 작성한다. 모든 연결은 TCP/IP 소켓을 사용한다. 이 숫자는 65,535로만 제한된다(어느 운영 체제 플랫폼에서나 사용 가능하도록 TCP/IP 프로토콜이 65,535 TCP/IP 포트만 허용한다).
성능 테스트 에이전트가 많은 수의 TCP/IP 소켓을 사용하면, 솔루션 컴포넌트는 소켓 연결이 부족하게 되며, 이는 성능 병목현상을 만들고 불량 성능을 초래한다.
그림 4. 성능 테스팅을 위해 피해야 할 첫 번째 패턴
패턴 2: 전체 로드 생성 환경(호스트 제어기 및 테스트 에이전트)은 솔루션 네트워크에서부터 나온다
이 토폴로지는 네트워크 오류, 패킷 삭제 및 기타 등등을 야기하기 때문에 솔루션을 테스트하기 위해 이를 피하자. 그러므로 이러한 토폴로지는 성능 테스팅 도중에 혼란과 오류를 야기할 뿐만 아니라 솔루션 서버에서 원하는 처리량과 로드를 추진하는 데 어렵게 한다.
그림 5. 성능 테스팅을 위해 피해야 할 두 번째 패턴
Rational Performance Tester에 대한 다음 튜닝 매개변수는 HTTP 프로토콜을 사용하는 3계층 웹 기반 애플리케이션에 대해 3000명의 가상의 동시 사용자로 35000명의 가상 사용자의 대규모 사용자 볼륨 로드를 생성하기 위해 성공적으로 시도되어 테스트되었다.
1000명에서 10,000명의 동시 가상 사용자 사이에 사용자 로드에 대해 웹 애플리케이션을 테스트할 때 이러한 매개변수를 적용할 수 있다.
면책사항: 이러한 튜닝 매개변수는 운영 체제의 네트워크 처리량 작동에서 25 – 40% 개선을 제공하기 위해 주목을 받고 애플리케이션 워크로드 특성에 따라 영향을 받을 수도 있다. 달성되는 성능 개선은 다른 플랫폼에서 5 – 10%로 달라졌다. AIX 플랫폼에 가장 중요한 개선사항이 있었다.
이러한 매개변수는 참조 지점이다. 테스트하는 애플리케이션 워크로드와 볼륨에 대해 맵핑할 수 있으므로 테스트에 대한 적절한 설정 값을 얻는다.
표 1: 로드 생성에서 최적화 성능을 위한 운영 체제 튜닝
| OS | 매개변수 | 값 | 구현 방식 세부사항 |
|---|---|---|---|
| Windows | MaxUserPort | 65534 | HKEY_LOCAL_MACHINE > System > CurrentControlSet > Services > TCPIP > Parameters 아래에서 레지스트리를 편집한다. 모든 매개변수는 DWORD로 추가되고 값은 Decimal로 설정된다. |
| TcpTimedWaitDelay | 30 | ||
| MaxFreeTcbs | 72000 | ||
| MaxHashTableSize | 65535 | ||
| TcpWindowSize | 65535 | ||
| EnableDynamicBacklog | 1 | ||
| MinimumDynamicBacklog | 20 | ||
| MaximumDynamicBacklog | 1000 | ||
| DynamicBacklogGrowthDelta | 10 | ||
| TcpAckFrequency | 1 | ||
| Linux | net.ipv4.ip_local_port_range | 2048 65000 | 다음 매개변수로 /etc/sysctl.conf 를 편집하고 파일을 저장한다. 다음 명령을 실행한다. – sysctl –p |
| net.core.rmem_default | 262144 | ||
| net.core.wmem_default | 262144 | ||
| net.core.wmem_max | 33554432 | ||
| net.core.rmem_max | 33554432 | ||
| net.core.netdev_max_backlog | 5000 | ||
| net.ipv4.tcp_no_metrics_save | 1 | ||
| net.ipv4.tcp_rmem | 4096 16777216 33554432 | ||
| net.ipv4.tcp_wmem | 4096 16777216 33554432 | ||
| net.core.optmem_max | 40960 | ||
| AIX | sb_max | 6192000 |
no –p –o <parameter> = <value>
|
| clean_partial_conns | 1 | ||
| tcp_timewait | 1 | ||
| tcp_keepidle | 600 | ||
| tcp_keepinit | 40 | ||
| tcp_nodelayack | 1 | ||
| tcp_keepintvl | 10 | ||
| Maxuproc | 8192 | ||
| tcp_sendspace | 4096000 | ||
| tcp_recvspace | 4096000 | ||
| tcp_ephemeral_low | 1024 | ||
| rfc1323 | 1 |
- Rational Performance Test 에이전트 서비스가 반드시 에이전트 머신에서 시작하도록 한다.
- 에이전트에서부터 테스트를 시작하기 전에
netstat명령을 사용하는 CLOSE_WAIT 또는 TIME_WAIT에서 연결이 없도록 한다.
참고:
TIME_WAIT 연결은 서버가 연결을 종료할 때 발생하지만, 클라이언트는 연결을 종료하도록 수신확인 신호에 대해 대기한다. TIME_WAIT 상태 하의 지속 시간을 초과한 후에 연결은 CLOSE_WAIT로 이동하고 운영 체제는 이 연결을 종료해야 한다. 성능 테스트를 실행하기 전에 이 두 가지 중 어느 상태에서나 연결을 보유하면 테스트 실행 도중에 Rational Performance Tester로 이 연결이 사용되는 것을 방지하며, 이는 테스트 이전에 이러한 연결 유형이 발생하지 않음을 제안한다. 이는 실행 이전에 정리된 네트워크 상태를 보장한다. - UNIX 운영 체제에 있는 에이전트 머신의 경우
rpt_runner라는 프로세스를 찾고 성능 테스트를 실행하기 전에 이러한 일이 발생하는 것을 중지한다.
Windows에서는 Task Manager에서 Java를 찾고 테스트를 시작하기 전에 동일한 것이 발생하면
중지한다.
참고:
Linux, AIX 또는 Windows의 Java에서rpt_runner프로세스를 중지해도 Rational Performance Tester 에이전트 서비스를 중지하지 않는다. 에이전트 프로세스는 모든 테스트 실행의 시작부에서 시작된다. 그러므로, 다음 테스트의 실행 이전에 이러한 프로세스를 중지하면(테스트 실행이 완료된 후에 존재하는 경우) 이전 테스트와 연관된 에이전트의 프로세스가 운영 체제에서부터 정리되도록 보장한다. 이러한 프로세스는 성능 테스트 도중에 성능 테스트 또는 오류의 갑작스러운 종결로 인해 테스트 완료 이후에 계속 존재할 수 있다. - Microsoft Windows 머신에서 다음과 같이 호스트 제어기에서 힙 상태 보기
옵션을 사용한다. Windows > Preferences > General > Show heap
status 테스트 도중에
Rational Performance Tester를 위한 메모리 활용을 계속 추적하도록 이를 사용할 수
있다. 메모리 활용이 늘어나면, 힙 상태 표시줄에서 가비지 콜렉션 아이콘을 수동으로 클릭하여
가비지 콜렉션을 강제 실행한다. 이를 알면 호스트 제어기 머신에 대해 메모리를 크기 조정하는 데
도움을 준다.
- 테스트를 시작하기 전에 호스트 제어기 워크벤치를 닫고 JVM 힙 메모리의 최소 사용을
달성하기 위해 다시 이를 실행한다. 테스트를 시작하기 전에
Rational Performance
Tester JVM 힙 메모리에서 참조되지 않은 오브젝트를 정리하기 위해 가비지 콜렉션을 한 번
강제 실행해야 한다.
- 테스트를 실행하기 전에 다음 디렉토리에서 컨텐츠를 모두 삭제하고 에이전트 서버를
다시 시작한다.
- 운영 체제의 temp 디렉토리. (Unix 기반 운영 체제의 /tmp 및
Windows의 C:\Documents and Settings\<User>\temp
디렉토리)
- 에이전트의 Deployment_root 디렉토리
- C:\Documents and
Settings\user name\Local Settings\Application
Data\javasharedresources에 있는 공유 클래스 자원
- 특정한 경우, 성능 테스트 에이전트 머신의 운영 체제를 다시 시작해야 한다.
- 운영 체제의 temp 디렉토리. (Unix 기반 운영 체제의 /tmp 및
Windows의 C:\Documents and Settings\<User>\temp
디렉토리)
- 적절한 디스크 공간이 temp 디렉토리 및
deployment_root 폴더가 들어있는 파일 시스템에 사용 가능하도록 한다. temp 디렉토리의
권장 최소값은 10GB이고 deployment 디렉토리의 권장 최소값은 5GB이다.
- 높은 로드를 생성하고 동기점을 고려할 때, 더 나은 결과를 얻기 위해 상대적으로 적은
대규모 구성 머신보다는 소규모 구성 에이전트 머신을 많이 사용한다.
- 테스트 지속 시간이 길거나 요청의 높은 처리량 생성을 수반한다면, 빠른 비율의 통계 샘플링을 방지한다. 높은 통계 샘플링 비율은 성능 테스트 도구에 대해 오버헤드이고 최적화 비율로 유지되어야 한다. 예를 들어, 2시간 테스트 실행에서 15초 샘플링 간격은 최적 통계 샘플링 비율이다.
그림 6. Rational Performance Tester에서 통계 샘플링 비율
- 오류 로그를 최소 로깅으로 설정한다. 오류와 경고만 로드 생성에서 최적 성능을 달성하기 위해 대용량 테스트를 실행할 때 주요 테스트 조치에 로그될 수 있다.
그림 7. Rational Performance Tester에서 로깅 레벨 옵션
교육
- Rational
Performance Tester 제품 개요 페이지에서 자세히 알아보자. 그 다음에 기술 기사로 링크는
IBM® developerWorks®에서 Rational Performance Tester 페이지를
탐색하고
Rational Performance Tester Information Center에서
사용자 지원을 찾아보자.
- developerWorks의 Rational 소프트웨어 영역에서 Rational Software Delivery Platform 제품과 관련된 기술 자료와 우수 사례를 볼 수 있다.
- developerWorks
기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다.
- 무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.
- developerWorks
on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다.
- 무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.
- 기술을 개선하자. Rational
training and certification 카탈로그를 확인한다. 이는 광범위한 주제에 대한 과정 유형이 많이
들어있다. 이 중 일부를 언제 어디서나 확인할 수 있으며, 다수의 "시작하기"는 무료이다.
제품 및 기술
- IBM
Rational Performance Tester의 무료 시험판을 다운로드하자.
- 자신에게 가장 적합한 방법으로 IBM
소프트웨어를 평가해 보자. 시험판 소프트웨어를 다운로드하거나 온라인으로 소프트웨어를 사용해 보거나 클라우드 환경에서 소프트웨어를 사용하거나
SOA Sandbox에서 SOA(Service-Oriented Architecture)를 효과적으로
구현하는 방법을 배울 수 있다.
토론
- Performance Testing 포럼에
참여하자. 이 포럼에서는 IBM 성능 테스트 제품에 대한 질문과 지식을 공유할 수 있다.
- developerWorks 기사를 기고하여 Rational 소프트웨어를 사용하는 다른 사람을 돕고 지식을 공유하자. developerWorks Rational 웹 사이트를 통해
전 세계적으로 기사를 공개하고 RSS 신디케이션과 필자란 및 전기를 이용할 수 있을 뿐만 아니라 전문적인 편집과
제작 혜택을 누릴 수 있다.
- Facebook 및 Twitter
(@ibmrational)에서 Rational 소프트웨어를 따라하고, 주석과 요청을 추가하자.
- Rational 포럼, cafés 및 위키에 참여하여 질문과 답을 해보고 자신의 전문성을 강화하자.
- developerWorks 커뮤니티에 가입하고 개발자 중심 블로그에 응답하여 관심사를 공유하는 다른 사람들과 연결해보자.
Bharath Raj는 IBM India Software Labs에서 HiPODS(High Performance OnDemand Solutions) 팀과 Enterprise Solutions Performance Analyst로 일하고 있다. 그는 Web 2.0 기술을 사용하여 J2EE 애플리케이션 개발자로서 IBM에서 일하기 시작했다. 원격 통신, 소매 및 기타 산업 분야에서 엔터프라이즈 솔루션에 사용되는 미들웨어, Java 및 데이터베이스의 성능과 관련하여 작업했다. 성능 튜닝, 용량 계획, 테스팅 및 엔지니어링 방법론 부문에서 광범위한 배경 지식과 경험을 갖춘 Bharath Raj는 엔터프라이즈 솔루션의 성능에 전체론적인 접근방식을 적용한다. 그는 최적화되고 더 빠르고 훨씬 더 높은 수준의 신뢰성을 갖춘 솔루션을 달성하기 위해 엔터프라이즈 웹 애플리케이션 분야에서 지속적으로 최첨단 기술을 사용하고 이를 흡수한다.
목차
태그
태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.
인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.
내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.
인기 기사 태그 |
내 기사 태그태그 목록으로 건너뛰기
인기 기사 태그 |
내 기사 태그