 웹 응용 프로그램 스트레스 도구를 사용한 성능 테스트
Duwamish Online Aaron Ching, Pedro Silva 및 Allen Wagner 요약:이 문서에서는 Duwamish Online 응용 프로그램의 성능을 테스트하는 데 사용하는 도구인 Microsoft WAS(웹 응용 프로그램 스트레스)에 초점을 맞추어 웹 응용 프로그램을 성공적으로 구축하는 데 있어 성능 테스트가 얼마나 중요한지를 다룹니다.
웹 응용 프로그램을 성공적으로 구축하기 위해서는 성능 테스트가 꼭 필요합니다. 많은 사용자가 웹 사이트에 방문할 때 응용 프로그램과 웹 서버 그룹이 어떻게 동작하는 지를 이해하고 있어야 합니다. 웹 응용 프로그램에 대해 해당 종류의 사용법을 시뮬레이트하기 위해서는 수 백 또는 수 천의 실제 사용자와 조정하여 지정된 시간 내에 웹 사이트에 액세스하거나 그러한 사용자 부하를 재현할 수 있는 테스트 도구를 사용해야 합니다. 수 많은 웹 성능 테스트 도구를 사용할 수 있습니다. 기본적으로 이들 도구를 사용하면 최소 수의 클라이언트 컴퓨터를 사용하여 웹 사이트의 미리 정의된 페이지나 URL(Uniform Resource Locator)을 동시에 요청하는 많은 수의 가상 사용자를 시뮬레이트할 수 있습니다. 이들 각 가상 사용자는 실제 웹 브라우저와 웹 서버 사이에서 정확한 통신 프로토콜을 에뮬레이트합니다. 이 문서에서는 이러한 무료로 이용할 수 있는 Microsoft® WAS(웹 응용 프로그램 스트레스) 중점적으로 다룰 것입니다. WAS는 http://www.microsoft.com/technet/itsolutions/intranet/downloads/webstres.asp
첫째 WAS를 사용하여 응용 프로그램의 성능을 테스트할 때의 장점을 논의할 것입니다. 무료입니다
간단합니다WAS에서는 여러 가지 방법으로 테스트 스크립트를 쉽게 작성할 수 있습니다. 즉, 브라우저로 사이트의 내용을 훑어보거나, 웹 서버 로그 파일에서 URL을 가져오거나 웹 컨텐트 디렉터리에서 파일을 선택하여 스크립트를 기록할 수 있습니다. 물론 URL을 직접 입력하여 새 테스트 스크립트를 만들 수도 있습니다. 몇몇 다른 도구와 달리, 하나의 중앙 마스터 클라이언트에 의하여 제어되는 클라이언트 컴퓨터를 개수에 상관없이 사용하여 테스트 스크립트를 실행할 수 있습니다. 각 테스트 시작 시 마스터 클라이언트는 아래의 작업을 투명하게 수행합니다.
이 기능은 그 처리량을 최대화하기 위해 많은 수의 클라이언트 컴퓨터를 사용해야 할 수도 있는 대형 웹 그룹의 성능을 테스트할 때 특히 유용합니다. 가용성이 높습니다WAS는 서버가 실행되는 플랫폼에 관계 없이 HTTP(하이퍼텍스트 전송 프로토콜) 1.0 또는 1.1 표준을 준수하는 모든 표준 웹 서버에 대한 웹 브라우저 요청을 시뮬레이트하도록 설계되었습니다. WAS는 사용이 용이한 테스트 생성 기능 외에도 다음을 포함하여 많은 유용한 기능을 갖고 있습니다.
WAS에는 장점 외에 몇 가지 한계도 있습니다. WAS 웹 사이트에 현재 알려진 버그와 문제가 나열되어 있습니다. 다음은 현재 WAS에서 지원되지 않는 기능입니다.
참고 여러 마스터 클라이언트를 사용하여 여러 웹 서버에 대해 동시에 테스트할 수도 있습니다. 그러나 모든 테스트 결과를 하나의 전체로서 상관시키려면 여러 WAS 데이터베이스에서 나온 데이터를 통합해야 합니다. 참고 WAS는 이미 SSL 페이지에 대한 테스트를 지원하지만 이를 기록하지는 못합니다. 스크립트 기록을 마친 후에는 지정된 각 URL에 대한 SSL 지원을 수동으로 켜야 합니다. 이러한 한계 중 몇몇에 대해서는 해결책이 있지만 사용 중인 응용 프로그램이 이 기능 중 하나 이상에 의존할 경우 WAS의 장점을 완전히 이용하지 못할 수도 있습니다. 현재 WAS의 개발 노력은 차세대 웹 응용 프로그램 성능 테스트 도구인 Microsoft Application Center Test(ACT)를 구현하는데 맞추어져 있습니다. 이 새로운 도구는 현재 Visual Studio.NET 베타의 일부로 최근에 출시된 제품의 베타 버전으로 WAS를 향상된 UI와 추가 기능으로 대체하도록 설계되었습니다.
웹 응용 프로그램 스트레스 도구는 Windows 2000 플랫폼을 포함하여 Microsoft Windows NT® 4.0 서비스 팩 4 이상이 필요합니다. 또한 Internet Explorer 4.0 이상이 필요한데, Internet Explorer 5.0이 더 좋습니다. 웹 응용 프로그램 스트레스 도구를 설치하려면 setup.exe 프로그램의 최신 버전을 다운로드하십시오. 설치 마법사의 안내대로 진행하십시오. 모든 테스트 컴퓨터에 setup.exe를 복사하고 실행하십시오. 참고 본 문서에 제시된 모든 절차는 WAS 버전 293을 기준으로 한 것입니다.
테스트 스크립트를 수동으로 만들 수도 있지만 WAS를 사용하여 브라우저 활동을 기록하거나, 웹 서버 로그 파일을 가져오거나 웹 컨텐트 디렉터리의 내용을 평가할 수도 있습니다. 본 문서에서는 웹 브라우저 활동을 기록하는 방식으로 테스트 스크립트를 만드는 것을 주로 다룰 것입니다. 다음과 같은 몇 가지 이유 때문에 여러 가지 방법 중에서 이 방법을 선택했습니다.
마스터 클라이언트 컴퓨터에서 테스트 스크립트를 만들어서 저장하기만 하면 됩니다. 마스터 클라이언트부터 테스트가 시작될 때 스크립트가 다른 클라이언트에도 자동으로 배포됩니다. 클라이언트 컴퓨터 준비회사 네트워크의 프록시 서버를 통해 WAS를 사용하고 있고 회사 네트워크 외부에 있는 클라이언트로부터 페이지를 요청하는데 회사에서 Microsoft Proxy Server를 사용 중인 경우 아래의 단계에 따라 클라이언트를 설치하십시오.
회사에서 이와 다른 프록시 서버를 사용할 경우 해당 프록시 서버와 함께 제공된 프록시 클라이언트 소프트웨어를 찾아서 설치합니다. 브라우저 준비스크립트 기록을 시작하기 전에 브라우저 캐시를 지워서 웹 브라우저를 준비해야 합니다. 그렇지 않으면 브라우저가 웹 서버에서 웹 페이지를 요청하는 대신 자신의 캐시에서 웹 페이지를 가져오기 때문에 요청된 브라우저 활동을 기록하지 못할 수도 있습니다. Internet Explorer에서 임시 저장 해제
Internet Explorer 5.0 이상을 사용 중인 경우 WAS가 프로그램 방식으로 설정값을 수정할 수 있게 해주는 새로운 기능이 포함되어 있으므로 프록시 설정값을 바꿀 필요가 없습니다. 그러나 Internet Explorer 4.0 이전 버전을 사용 중인 경우에는 WAS가 내장 프록시 서버를 사용하여 브라우저 활동을 기록합니다. WAS에서 요청하는 대로 프록시 설정값 지정
스크립트 기록브라우저와 클라이언트가 기록할 준비가 되었으면 다음을 수행하십시오.
 [그림1]스크립트 만들기
오른쪽 창의 아래 부분에 모든 스크립트 항목을 나열한 표가 표시됩니다. 보안 연결을 필요로 하는 웹 사이트의 경우 WAS는 SSL(Secure Sockets Layer) 사용 가능 페이지에 대한 테스트를 지원합니다. 그러나 SSL 기록은 허용하지 않습니다. 이러한 한계를 해결하기 위해 웹 서버에서 SSL을 해제하고, 스크립트를 기록한 다음, 웹에서 SSL을 다시 활성화합니다.
새로 만들어진 테스트 스크립트는 아직 테스트에 사용할 수 없습니다. 테스트에 사용하기 위해서는 아래의 구성 작업 중 하나 이상을 완료해야 합니다.
스크립트 항목 조정테스트 스크립트의 스크립트 항목을 수정할 때 고려할 몇 가지 사항을 다음에서 살펴 보겠습니다. 원하지 않는 스크립트 항목 제거중복 항목이나 유효하지 않은 URL을 가진 항목을 제거하여 테스트의 노이즈 요소를 줄이십시오. 특정 기능 조정 시 이미지, 스타일시트 및 기타 보조 정적 파일을 참조하는 모든 스크립트 항목을 제거하십시오. 스크립트 항목에 대한 일고 시간 지정스크립트 항목 테이블의 마지막 열의 표제는 "Delay"입니다. 이 열에서는 스크립트 항목을 실행하기 전에 고정 지연 시간(일고 시간(think time)이라고도 함)을 지정할 수 있습니다. 성능 테스트에 적절한 일고 시간(think time)을 결정하는 한 가지 기준은 없습니다. 어떤 사람은 테스트 시 일고 시간으로 0초를 사용할 수도 있고, 또 어떤 사람은 30초를 사용하고자 할 수도 있습니다. 일고 시간(think time)의 선택은 주로 사이트의 내용과 테스트의 목적에 따라 달라집니다. 예를 들어 내용이 긴 웹 사이트는 내용이 짧은 단순한 사이트보다 긴 일고 시간을 사용할 수도 있습니다. 사용자가 내용을 읽는 데 시간이 더 많이 걸릴 것이기 때문입니다. 한편 최소 수의 클라이언트 컴퓨터가 있는 웹 서버의 최대 처리량을 빨리 확인하고자 할 때 일고 시간(think time)을 0초로 할 수도 있습니다. 일고 시간이 없다면 WAS의 모든 스레드가 최고 속도로 웹 서버에 대한 로드를 생성합니다. 스크립트 항목에 대한 값 목록 설정WAS에서는 각 요청에 대해 같은 양식의 값을 사용하는 대신 스크립트 항목의 이름-값 쌍에 값 목록을 지정할 수 있습니다. 이것은 사용자가 다시는 같은 양식 값 집합을 가진 같은 페이지를 호출하지 않을 것으로 예상되는 현실적인 테스트 시나리오를 작성할 때 중요한 기능입니다. 예를 들면, 테스트 스크립트에 있는 항목 중 하나는 제품 항목의 상세 정보를 표시하기 위해 ASP 페이지를 호출합니다. 이 때 매번 같은 제품 ID를 가진 페이지를 호출하는 대신 미리 정의된 제품 ID의 목록에서 다른 값을 임의로 선택하도록 WAS를 구성합니다. 스크립트 항목에 대한 값 목록 설정
스크립트 항목에 대한 SSL 설정특정 스크립트 항목에 대해 SSL을 사용 가능하게 하려면 다음을 수행하십시오.
스크립트 설정값 조정성능 테스트를 제대로 실행하려면 테스트 스크립트의 몇 가지 설정값을 수정해야 합니다. 왼쪽 창에서 스크립트 이름을 두 번 눌러 스크립트의 정보 트리를 확장하면 Settings라는 레이블이 붙은 항목이 발견되는데, 여기서 테스트 스크립트에 대한 설정값 중 여러 가지를 지정할 수 있습니다. Settings 항목을 누르면 오른쪽 창에서 Settings 보기(그림 4)가 열립니다.
대상 웹 서버 지정기본적으로 대상 웹 서버는 "localhost"로 설정되는데, 이 값은 대상 웹 서버의 IP 주소나 도메인 이름으로 대체됩니다. 설정값 변경
참고 Duwamish Online의 경우처럼 네트워크 로드 균형 조정이 설치된 웹 서버 그룹에 대해 테스트를 실행하려면 이 필드에 클러스터 IP 주소를 입력하십시오. 동시 연결 수 지정Settings 보기의 Concurrent Connections 구역 아래에서는 Stress level(threads) 및 Stress multiplier(sockets per thread)를 지정하여 대상 웹 서버에 적용할 로드/스트레스 수준을 제어할 수 있습니다. 여기서 스트레스 수준은 모든 클라이언트에서 만들어진 총 Windows NT 스레드 수를 말합니다. 각 스레드는 여러 개의 소켓을 만들 수 있는데, 각 소켓은 하나의 동시 요청을 말합니다. 아래의 공식은 이 관계를 설명합니다. 총 동시 요청 수 = 스트레스 수준(스레드) x 스트레스 승수 본사 성능 랩에서는 성능 테스트를 위해 다양한 스트레스 수준(스레드) 값을 사용합니다. 예를 들면 로드 수준을 늘려가면서 서버 그룹이 얼마나 잘 응답하는지 연구하기 위해 연속적인 테스트를 실행하여 값 100, 200, 300, 400, 500, 750, 1000, 1500, 2000을 사용했습니다. 예비 테스트 결과에 따라 이러한 숫자를 조정해야 합니다. 대개 스레드 수의 증가에 비례하여 시스템 처리량이 증가할 것으로 예상되는 낮은 스레드 수준에서는 보다 많은 데이터 요소를 모으고자 합니다. 반면 높은 스레드 수준에서는, 특히 시스템 처리량이 최고점에 달한 이후 감소하는 경우에는 테스트 실행 횟수를 줄여서 시간과 노력을 절약할 수 있습니다. 첫 번째 테스트는 1000 스레드에서 실행되도록 설정되었습니다. 이렇게 하는 목적은 응용 프로그램에서 사용되는 데이터 캐시를 구축하기에 충분한 요청을 실행하기 위한 것입니다. 캐시가 있을 때와 없을 때의 응용 프로그램의 성능은 극적으로 달라질 수 있기 때문에 이렇게 하면 로드를 테스트하기 위한 일관된 시스템 환경을 유지하는 데 도움이 됩니다. 테스트 실행 시간 지정Settings 보기의 Test Run Time 구역 아래에서는 전체 실행 시간을 일, 시간, 분 및 초 단위로 지정할 수 있습니다. 테스트 결과를 제대로 얻으려면 스크립트 항목의 예상 대기 시간(또는 응답 시간)에 따라 충분한 수의 요청을 생성하여 최소한 몇 분 동안 테스트 스크립트를 실행하는 것이 좋습니다. 응용 프로그램에서 지연 시간이 길수록 대용량 데이터 집합을 샘플링하기 위하여 테스트 실행 시간이 더 길어져야 합니다. 사이트의 모든 성능 문제를 모니터하고 조사하기 위해서는 짧은 테스트를 자주 실행할 수 있습니다. 또한 사이트의 성능이 점차 저하되는지 알아보려는 경우 특히 해당 사이트가 중간 또는 높은 수준의 로드 아래에 있을 때에는 훨씬 긴 테스트(예: 30일 정도)를 실행합니다. Duwamish Online의 경우 대부분의 성능 테스트를 7-10분 동안 실행하는데, 이 정도면 안정적인 테스트 결과를 얻기에 충분합니다. 임의 지연 지정Settings 보기의 Request Delay 구역 아래에서는 실행 전에 각 스크립트 항목에 임의 지연 시간(또는 일고 시간)을 추가하도록 선택할 수 있습니다. Use random delay 확인란이 선택되어 있는 경우 각 WAS 스레드가 각 스크립트 항목에 지정된 고정 일고 시간(think time)에 Min 및 Max 값 사이의 각 임의 시간을 더한 만큼 유휴 상태가 됩니다. 아래의 공식은 지연 계산을 설명합니다. 각 항목의 총 지연 = 임의 지연 + 각 항목의 고정 지연 이러한 임의 지연 기능은 스크립트 항목에 고정 지연이 지정된 경우에 특히 유용합니다. 임의 지연을 사용하지 않으면 모든 스레드가 거의 동시에 자신의 요청을 웹 서버에 보낸 후 다음 요청을 보내기 전까지 거의 같은 고정 지연 시간동안 기다릴 가능성이 있습니다. 임의 지연은 웹 서버에 대해 로드를 적용할 때 최고점과 최하점의 균형을 맞추는 데 도움이 됩니다. 일시 중지 시간 지정Settings 보기의 Suspend 구역 아래에서는 warmup 및 cooldown 시간을 시간, 분, 초로 지정할 수 있습니다. 워밍업 시간은 성능 데이터가 모아지지 않거나 테스트 결과로 계산되지 않는 동안 초기 테스트가 실행된 시간 길이에 해당합니다. 마찬가지로 쿨다운 시간은 데이터 수집이 없을 경우 테스트 실행이 끝나는 기간을 지정합니다. 워밍업 및 쿨다운 시간은 테스트 결과의 왜곡을 최소화하는 데 사용됩니다. 보통 새로운 테스트가 실행되는 초기 단계에서는 구성 요소 또는 응용 프로그램 캐시 초기화 같은 일회성 활동이 더 많은 시스템 리소스를 소모합니다. 워밍업 시간은 테스트 자료가 모아지기 전까지 시스템 환경을 안정시키는 데 도움이 됩니다. 이와 반대로 쿨다운 시간은 테스트 실행 종료 시에 추가 시스템 리소스를 사용하여 테스트를 중지하고 모든 클라이언트에서 데이터를 모으기 시작할 때 왜곡된 데이터를 피하는 데 도움이 됩니다. 더 나아가 소켓 연결이 너무 이르게 종료될 수도 있어 이로 인해 소켓 오율이 더 커집니다. Duwamish Online의 경우 대부분의 성능 테스트에 30 - 60초 정도의 워밍업 및 쿨다운 시간을 사용합니다. 대역폭 조절 지정Settings 보기의 Bandwidth 구역 아래에서는 WAS를 통해 14.4Kbps 모뎀 연결에서 T1(1.5Mbps) LAN 연결에 이르는 다양한 네트워크 대역폭을 시뮬레이트할 수 있습니다. 이 기능의 가장 큰 장점은 대상 웹 서버에서 보다 많은 수의 동시 연결 수를 유지할 수 있다는 것입니다. 이것은 고객이 속도가 느린 모뎀 연결을 사용하는 많은 웹 사이트가 공통으로 경험하는 현상입니다. 대역폭 조절 활성화
Duwamish Online의 경우 대역폭 조절에 대해 다른 설정값을 시도해 보았습니다. 처음에는 많은 웹 사이트가 경험하는 조건 아래에서 응용 프로그램의 성능을 알아보기 위하여 사용자를 56Kbps 연결로 조절했습니다. 또한 앞으로 대부분의 대상 사용자가 보다 빠른 연결을 통해 사이트에 액세스할 경우의 광대역 사용 경향을 시뮬레이트하기 위해 사용자를 ISDN 이중 채널(128Kbps)로 조절해 보았습니다. 마지막으로 대역폭 조절 없이 사이트를 테스트해 보았습니다. 흥미롭게도 이렇게 설정한 경우 128Kbps 연결을 사용할 때와 동일한 조건이 생성되었습니다. 대역폭 조절에 대해 어떤 설정값을 설정하더라도 테스트 결과를 비교하고자 하는 모든 테스트에서는 이를 동일하게 하십시오. 기타 설정값 지정Settings 보기의 다른 구역 아래에서는 HTTP 리디렉션을 제외하고 모두 기본값을 유지했습니다. Follow HTTP redirects 확인란의 선택을 취소하여 일부러 이 기능을 사용할 수 없도록 했습니다. 리디렉션된 URL이 작성 단계에서 이미 스크립트에 기록된 경우에는 이러한 작업이 필요합니다. 테스트 실행에서 이러한 URL을 두 번 실행하고 싶지 않을 것입니다. 페이지 그룹 설정WAS에서는 스크립트 항목 집합을 소위 페이지 그룹이라는 것으로 구성할 수 있습니다. 이 기능을 사용하면 HTML 파일, 그래픽 파일, 스타일시트 등을 포함하여 모든 페이지 요소나 복수의 관련 페이지를 하나의 논리적 단위로 그룹화할 수 있습니다. 각 페이지 그룹에 대해 다른 적중률을 지정할 수 있으며, 이를 통해 더 자주 요청되거나 덜 자주 요청될 페이지나 관련 페이지를 제어합니다. 사이트에 대해 상품 목록 훑어보기나 쇼핑 카트 같은 사용 시나리오를 갖고 있다면 페이지 그룹을 통해 사이트에 대해 기대하는 퍼센트로 사용 시나리오를 실행할 수 있습니다. 페이지 그룹 설정
그룹 테이블에서는 "기본" 페이지 그룹이 100퍼센트의 배포로 이미 만들어져 있습니다. 처음에는 기본적으로 모든 스크립트 항목이 이 그룹에 할당됩니다.
페이지 그룹을 만들어서 스크립트 항목에 할당하는 또 다른 방법은 스크립트 기록 동안 그룹을 지정하는 것입니다. 이 방법을 사용하려면 새 페이지로 점프하기 전에 브라우저에서 WAS 프로그램 창(그림 2 참조)으로 되돌아 가십시오. Change Group 단추를 누른 다음 New Group 대화 상자에 그룹 이름을 입력하십시오. 그 이후 기록된 모든 스크립트 항목에 앞에서 입력한 새 그룹 이름이 할당됩니다. 사용자 설정특성화 및 인증을 필요로 하는 웹 사이트를 테스트하기 위해 WAS는 Users라는 기능을 제공하는데, 이 기능은 사용자 이름, 암호 및 쿠키 정보에 대한 여러 가지 레코드를 저장하는 데 사용될 수 있습니다. 테스트가 시작되면 모든 사용자가 스트레스 수준 설정값에서 제공하는 스레드 사이에서 나누어 집니다. 요청이 있으면 각 스레드는 해당 스레드에 할당된 풀로부터 새 사용자의 사용자 이름, 암호 및 쿠키를 사용합니다. WAS가 스레드보다 적은 수의 사용자에 맞게 구성된 경우 일부 스레드에는 사용자가 없게 되어 인증된 페이지가 실패하고 쿠기와의 모든 상호 작용이 비활성화됩니다. 따라서 전용화된 웹 사이트를 테스트할 때는 항상 사용자 수가 스레드보다 많아야 합니다. WAS에서 만들 수 있는 사용자 수에는 한계가 없습니다. 그러나 각 사용자가 클라이언트 간에 보다 많은 메모리와 리소스를 필요로 하므로 거대한 사용자 목록이 사용될 경우 테스트를 시작하고 중지하는 데 시간이 더 걸릴 수도 있습니다. 새 사용자 만들기
기본적으로 200개의 사용자 레코드가 이미 만들어져 있습니다. 응용 프로그램의 로그온 계정에 따라 user 및 password 필드를 수정하려면 사용자 테이블의 각 셀을 누르기만 하면 됩니다. 또한 다음을 수행하여 새 사용자 집합을 만들 수도 있습니다.
사용자 정의 사용자 이름과 암호 목록을 사용하려는 경우 미리 포맷된 텍스트 파일에서 가져올 수 있습니다. 이 기능에 대한 자세한 내용은 WAS 도움말 파일의 "Importing user names and passwords" 절을 참조하십시오. 클라이언트 컴퓨터 설정WAS에서는 여러 대의 클라이언트 컴퓨터를 사용하여 웹 사이트의 로드를 테스트할 수 있습니다. 테스트가 시작되면 WAS가 자동으로 정의된 모든 클라이언트와 통신하고, 스크립트 항목, 페이지 그룹 및 사용자 정의를 포함한 모든 테스트 정보를 이들 클라이언트에 전송하고, 이들 클라이언트에서 테스트를 시작 및 중지한 다음, 이들로부터 테스트 결과를 모읍니다. 컴퓨터 중 한 대를 마스터 클라이언트로 사용하십시오. 테스트 스크립트를 기록하고 구성하는 데 사용된 클라이언트를 마스터 클라이언트로 사용해야 합니다. 테스트를 위한 클라이언트 설정
기본적으로 클라이언트 테이블에는 localhost(현재 작업 중인 마스터 클라이언트)에 대한 클라이언트 레코드가 이미 만들어져 있습니다. 새 클라이언트를 추가할 경우 엇비슷한 처리 능력을 가진 컴퓨터를 추가하십시오. 다른 클라이언트에 비해 속도가 상당히 느린 컴퓨터를 추가하면 해당 컴퓨터를 추가하지 않았을 때보다 많은 소켓 오류가 발생할 수 있습니다. 이는 WAS가 테스트 로드를 분산시킬 때 컴퓨터의 능력을 확인하지 않기 때문인 것으로 생각됩니다. 속도가 느린 구형 클라이언트 컴퓨터가 빠른 신형 클라이언트 컴퓨터보다 로드를 많이 생성할 것으로 예상됩니다. 또한 마스터 클라이언트의 역할을 하지만 로드 생성에는 기여하지 않는 전용 시스템을 설치하는 것이 더 낫습니다. 이러한 구성에서는 소켓 오류가 보다 적게 발생하고 테스트가 보다 빨리 끝납니다. 이렇게 설정하려면 클라이언트 목록에서 마스터 클라이언트의 컴퓨터 이름을 제거하십시오. 로드 생성에 사용하지 않기로 한, 속도가 느린 컴퓨터가 있다면 테스트 결과에 영향을 미치지 않는 마스터 클라이언트의 역할을 할 수 있습니다. 그러나 마스터 클라이언트는 모든 보고서 생성과 테스트 스크립트의 배포를 수행한다는 점에 유의하십시오. 따라서 속도가 느린 마스터 클라이언트를 사용한다는 것은 테스트가 더 늦게 시작되고 보고서를 생성하는 데 시간이 더 걸릴 수도 있음을 의미합니다. 성능 카운터 설정WAS는 테스트 자료 수집을 간단히 하기 위해 Windows NT 성능 모니터 인터페이스와 통합될 수 있습니다. 각 스크립트와 함께 즐겨 사용하는 성능 모니터 카운터를 저장할 수 있으며 그러면 WAS가 수집하는 다른 정보와 함께 해당 데이터를 모읍니다. 스크립트에 성능 모니터 카운터 추가
공통 성능 카운터의 목록에 대해서는 WAS 도움말 파일의 "Common performance monitor counters" 절을 참조하십시오. 이 기능을 사용할 때 문제가 있다면 WAS 기술 자료를 참조하십시오.
테스트 스크립트를 설정하고 구성했다면 클라이언트 컴퓨터에서 스크립트를 실행할 준비가 된 것입니다. 마스터 클라이언트 컴퓨터에서 테스트 실행 시작
도구 모음의 Play 단추를 눌러도 스크립트를 실행할 수 있습니다. 테스트 보고서 검사테스트를 마쳤으면 먼저 테스트 보고서에서 소켓 또는 HTTP 오류가 있는지 검사해야 합니다. 보고서에서 소켓 또는 HTTP 오류 확인
보고서 요약의 Socket Errors 구역 아래에서 0이외의 값을 가진 소켓 관련 오류가 있는지 확인합니다. 다음은 각 소켓 오류 유형에 대한 설명입니다.
스크립트 실행지금까지 설명한 스크립트를 준비했으면 이제 테스트를 실행하여 데이터를 모을 준비가 된 것입니다. 앞에서 설명한 단계를 수행하여 각 테스트를 직접 실행할 수도 있습니다. 그러나 이 작업은 시간 소모적인 프로세스가 될 수 있습니다. WAS에는 사용자가 자신의 Microsoft VBScript(Visual Basic Scripting Edition) 스크립트를 만들어 테스트 실행을 제어 및 구성할 수 있게 해주는 개체 모형이 있습니다. 성능 테스트를 보다 효과적으로 실행하는 데 도움이 되는 VBScript 예제를 보려면 http://webtool.rte.microsoft.com/ObjModel/ 테스트가 실행 중인 동안에는 시스템 처리량, 지연 시간(응답 시간) 및 리소스 사용률을 추적하기 위한 카운터를 포함하여 다양한 성능 관련 시스템 카운터를 모니터하고 기록해야 합니다.
클라이언트 컴퓨터. 각 클라이언트의 시스템 사용률을 면밀하게 모니터링하십시오. CPU 또는 메모리 사용률이 80% 이상인 경우 해당 클라이언트가 과부화되었을 가능성이 있으므로 테스트를 위해 추가 클라이언트 컴퓨터를 사용할 것을 고려해야 합니다. 클라이언트 컴퓨터에 스트레스를 주면 테스트 결과를 신뢰할 수 없으므로 웹 서버와의 연결에 소켓 오류가 발생합니다. 서버에 대한 스트레스 승수를 설정하십시오. 사전 테스트에서 웹 서버 그룹을 100 퍼센트 사용률에 근접하게 하는 데 필요한 최대 동시 사용자 요청 수를 평가하십시오. 충분한 수의 테스트 클라이언트 컴퓨터가 없어 서버 그룹에서 스트레스를 제거해야 할 경우 더 높은 승수가 필요할 수도 있습니다. 예를 들어 4,000 WAST 스레드가 있는데, 모두 승수 1을 갖고 있고, 여전히 서버에서 스트레스를 제거할 수 없는 경우 승수를 사용하여 스트레스를 늘릴 수 있습니다. 그러나 1보다 큰 승수를 사용한다면 웹 응용 프로그램 페이지의 정확한 TTLB가 정확하게 반영되지 않습니다. 가능하다면 사용자 승수에 의존하기 보다는 테스트 환경에 클라이언트 컴퓨터를 더 추가하십시오. Sessiontrace를 사용하십시오. WAS와 웹 서버 간의 상세한 통신을 기록하려면 Sessiontrace를 사용하십시오. 새 WAS 스크립트를 정의할 경우 스크립트에서 사용되는 모든 URL이 예상한대로 기능하고 웹 서버가 원하는 응답을 반환하는지 알아 보아야 합니다. 그렇지 않다면 웹 서버가 오류 응답을 반환할 때 향상된 성능 결과를 얻을 수도 있습니다. 유형 REG_DWORD의 경우 Sessiontrace을 1로 설정해야 합니다. Sessiontrace는 레지스트리 \HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \WAS에서 켜질 수 있습니다. 마지막으로 새 스크립트의 유효성을 검사한 후에는 잊지 말고 Sessiontrace를 꺼야(0) 합니다. 그렇지 않으면 디스크 공간이 빨리 꽉 차게 됩니다. 웹 서버 로그 파일을 모니터링하십시오. 웹 서버 로그 파일을 재배치하거나 제거할 준비가 되어 있어야 합니다. 웹 서버 로그 파일은 성능 테스트를 많이 하면 특히 장기 실행 테스트의 경우에 매우 빠르게 증가합니다. 또한 로그 파일을 사용하면 WAS에서 보고한 응용 프로그램의 오류를 해결하는 데 도움이 될 수 있습니다. 스크립트 항목 및 사용자 수를 제한하십시오. 특별히 스크립트 항목이나 사용자가 더 많이 필요한 이유가 없다면 1,000개(명) 이상 만들지 않도록 하십시오. 허용 가능한 수를 한정하는 요인은 해당 클라이언트 컴퓨터의 메모리 양뿐이지만 많은 수의 스크립트 항목이나 사용자를 사용할 경우 테스트를 초기화하는 데 시간이 더 걸릴 수도 있습니다. HTTP Redirects 옵션을 따르십시오. 스크립트가 이미 리디렉션된 URL을 기록한 경우 이 옵션을 사용하지 마십시오. 이 옵션을 사용할 경우 리디렉션된 페이지가 두 번 카운트됩니다. %USERNAME% 및 %PASSWORD%. WAS 도움말 파일은 각 WAS 사용자에 대해 지정된 USERNAME 및 PASSWORD 값을 사용하여 폼을 채울 하나의 방법으로 이들 항목을 참조합니다. 이 테스트에서는 %USERNAME%과 %PASSWORD%를 사용하면 여러 클라이언트 간에 분산된 스크립트를 시스템 종료하는데 필요한 시간의 양이 극적으로 늘어납니다. 내부 WAS 사용자의 충고에 따라 각 WAS 테스트의 QueryString 부분에서 USER 및 PASSWORD 이름-값 쌍을 지정합니다. 액세스 방법을 USER와 PASSWORD 둘 다에 대해 순차적으로 설정하면 해당 암호가 항상 해당 사용자에 상응됩니다. 이러한 한계에도 불구하고 WAS는 사이트에 방문하기 전에 사이트의 사용자를 시뮬레이트하기 위한 좋은 도구입니다. 성능 테스트 도구의 사용은 성공적인 응용 프로그램의 시작에 매우 중요합니다. 이러한 도구를 사용하면 응용 프로그램의 성능 특성을 이해할 수 있어 높은 사용자 로드 하에 놓였을 때 응용 프로그램이 어떻게 수행될지 정확하게 알 수 있습니다. 웹 사이트를 운영하는 동안 예상하지 않은 일이 적을수록 웹 사이트의 안정성은 높아질 것입니다.
최종 수정일 : 2003.1.7 | |||||||||||||||||||||||||||||||||||||||||
소개
에서 무료로 다운로드할 수 있습니다. 또한 Microsoft Windows® 2000 Resource Kit CD(WAS 버전 288)에서도 구할 수 있습니다. 
