큰 부하 테스트에 대한 고려 사항
업데이트: 2007년 11월
이 항목에서는 Visual Studio Team System Test Edition에서 대규모 부하 테스트를 수행하기 위한 팁을 제공합니다. 다음과 같은 내용에 대해 설명합니다.
적절한 부하 패턴 선택
적절한 연결 모델 선택
샘플링 주기와 데이터 수집
인지 시간
웹 테스트 요청의 응답 시간 목표 설정
타이밍 정보를 포함하여 백분위수 데이터 수집
새 사용자의 백분율 속성 설정
SQL 추적 사용
적절한 에이전트 컴퓨터 수 유지
적절한 부하 패턴 선택
일정 부하, 단계 부하 및 목표 기반 부하라는 세 가지 부하 패턴이 있습니다. 사용자의 부하 테스트에 적절한 부하 패턴을 선택하려면 각 유형의 장점을 파악해야 합니다. 자세한 내용은 부하 패턴 정보를 참조하십시오.
일정 부하 |
일정 부하 패턴은 장기간에 걸쳐 동일한 사용자 부하를 적용하여 부하 테스트를 실행하려는 경우에 유용합니다. 일정 부하 패턴에서 사용자 부하를 높게 지정하는 경우 부하 테스트에 준비 시간을 함께 지정하는 것이 좋습니다. 준비 시간을 지정하면 사이트에 수백 개의 새 사용자 세션이 동시에 생성되어 과부하가 걸리지 않게 할 수 있습니다. |
단계 부하 |
단계 부하 패턴을 사용하면 사용자 부하가 증가함에 따라 시스템 성능을 모니터링할 수 있으므로 이는 가장 널리 사용되며 유용한 부하 패턴 중 하나입니다. 사용자 부하가 증가함에 따라 시스템을 모니터링하면 적절한 반응 시간을 유지하면서 지원 가능한 사용자 수를 판단할 수 있고, 반대로 성능이 저하되기 시작하는 사용자 수를 판단할 수도 있습니다. |
목표 기반 부하 |
목표 기반 부하 패턴은 사용자 부하가 일반적으로 시간에 따라 증가한다는 점에서 단계 부하 패턴과 비슷하지만, 특정 성능 카운터가 일정 수준에 이르면 부하가 더 이상 증가하지 않도록 지정할 수 있다는 점이 다릅니다. 예를 들어 목표 기반 부하 패턴을 사용하여 부하를 점점 늘리다가 대상 서버 중 하나의 사용률이 75%가 되면 부하를 일정하게 유지할 수 있습니다. |
미리 정의된 부하 패턴이 사용자의 필요에 적합하지 않은 경우 부하 테스트가 실행되는 도중 사용자 부하를 제어하는 사용자 지정 부하 테스트 플러그 인을 구현할 수도 있습니다. 자세한 내용은 고급 부하 테스트 작업을 참조하십시오.
적절한 연결 모델 선택
사용자마다 연결 및 연결 풀이라는 두 가지 연결 모델이 있습니다. 사용자의 부하 테스트에 적절한 연결 모델을 선택하려면 각 유형의 장점을 파악해야 합니다.
사용자마다 연결 |
사용자마다 연결 모델은 실제 브라우저의 동작을 가장 가깝게 시뮬레이션합니다. 웹 테스트를 실행하는 각 가상 사용자는 해당 가상 사용자에게 지정된 웹 서버에 대한 연결을 하나 또는 두 개 사용합니다. 웹 테스트에서 첫 번째 요청이 발생하면 첫 번째 연결이 설정됩니다. 두 번째 연결은 페이지에 종속 요청에 둘 이상 포함된 경우에 사용될 수 있습니다. 이러한 요청은 두 연결을 사용하여 병렬로 발생할 수 있습니다. 웹 테스트 내에서 이후에 요청이 발생하면 같은 연결이 다시 사용되고, 웹 테스트 실행이 완료되면 연결이 닫힙니다. 사용자마다 연결 모델의 단점은 에이전트 컴퓨터에서 열려 있는 상태로 유지되는 연결 수가 사용자 부하의 두 배까지 될 수 있으며, 이러한 다수의 연결을 지원하는 데 필요한 리소스로 인해 부하 테스트 에이전트 하나에서 생성할 수 있는 사용자 부하가 제한될 수 있다는 점입니다. |
연결 풀 |
연결 풀 모델에서는 여러 가상 웹 테스트 사용자 간에 웹 서버에 대한 연결이 공유되므로 부하 테스트 에이전트의 리소스가 절약됩니다. 연결 풀 모델에서 연결 풀 크기는 부하 테스트 에이전트와 웹 서버 사이에 만들 수 있는 최대 연결 수를 지정합니다. 사용자 부하가 연결 풀 크기보다 크면 여러 가상 사용자가 실행하는 웹 테스트에서 연결을 공유하게 됩니다. 연결을 공유하는 경우 웹 테스트 중 하나에서 연결을 사용하고 있을 때 다른 웹 테스트에서 요청을 내보내려면 대기해야 할 수도 있습니다. 요청을 전송하기 전에 웹 테스트에서 대기하는 평균 시간은 부하 테스트 성능 카운터인 Avg. Connection Wait Time을 통해 추적됩니다. 이 시간은 페이지의 평균 응답 시간보다 작아야 합니다. 그렇지 않으면 연결 풀 크기가 너무 작은 경우일 수 있습니다. |
샘플링 주기와 데이터 수집
부하 테스트의 길이에 따라 적절한 샘플링 주기를 선택해야 합니다. 5초 등의 짧은 샘플링 주기를 선택하면 샘플링 주기가 길 때보다 각 성능 카운터에 많은 데이터가 수집됩니다. 장기간에 걸쳐 데이터를 대규모로 수집하면 디스크 공간 오류가 발생할 수 있습니다. 부하 테스트가 긴 경우 샘플링 주기를 늘려 데이터가 수집되는 양을 줄일 수 있습니다. 성능 카운터의 개수도 데이터가 수집되는 양에 영향을 줍니다. 테스트 대상 컴퓨터에서 카운터 수를 줄이면 데이터가 수집되는 양이 감소합니다.
여러 주기를 시험하여 특정 부하 테스트에 가장 적합한 샘플링 주기를 판단해야 합니다. 그러나 우선 다음 표에서 제공하는 권장 샘플링 주기를 참고해 볼 수 있습니다.
부하 테스트 지속 시간 |
권장 샘플링 주기 |
|---|---|
1시간 미만 |
5초 |
1-8시간 |
15초 |
8-24시간 |
30초 |
24시간 초과 |
60초 |
인지 시간
웹 테스트 요청의 인지 시간은 적절한 응답 시간을 유지하면서 지원 가능한 사용자 수에 큰 영향을 줍니다. 인지 시간을 2초에서 10초로 변경하면 일반적으로 5배 많은 사용자를 시뮬레이션할 수 있게 됩니다. 그러나 실제 사용자를 시뮬레이션하는 것이 목표인 경우 해당 웹 사이트에서 사용자의 행동을 예측하여 적절한 인지 시간을 설정해야 합니다. 인지 시간과 사용자 수를 늘려도 웹 서버에 항상 추가 부담을 주지는 않습니다. 웹 서버가 인증된 경우 사용된 구성표 유형이 성능에 영향을 줍니다.
웹 서버에서 인지 시간을 해제하면 초당 요청 처리량이 높은 부하 테스트를 생성할 수 있게 됩니다. 인지 시간을 해제하는 경우 사용자 수를 인지 시간을 사용할 때보다 훨씬 작은 수로 줄여야 합니다. 예를 들어 인지 시간을 해제하고 1000명의 사용자를 실행하면 대상 서버나 부하 테스트 에이전트에 무리를 주게 됩니다.
자세한 내용은 대기 시간 정보를 참조하십시오.
웹 테스트 요청의 응답 시간 목표 설정
웹 테스트 요청의 속성 중 하나로 응답 시간 목표가 있습니다. 웹 테스트 요청의 응답 시간 목표를 정의하면 부하 테스트에서 웹 테스트가 실행될 때 부하 테스트 분석기에서 응답 시간이 목표에 도달하지 못한 웹 테스트의 백분율을 보고합니다. 기본적으로는 웹 요청에 응답 시간 목표가 정의되어 있지 않습니다.
자세한 내용은 방법: 웹 테스트의 페이지 응답 시간 목표 설정을 참조하십시오.
타이밍 정보를 포함하여 백분위수 데이터 수집
실행 설정에는 타이밍 정보 저장소라는 속성이 들어 있습니다. 이 속성을 사용하면 부하 테스트 도중 개별 테스트, 트랜잭션 및 페이지를 실행하는 데 각각 걸리는 시간이 부하 테스트 결과 리포지토리에 저장됩니다. 이렇게 하면 부하 테스트 분석기에서 테스트, 트랜잭션 및 페이지 표에 90번째 및 95번째 백분위수 데이터가 표시됩니다.
기본적으로는 타이밍 정보 저장소가 사용되지 않습니다. 여기에는 두 가지 중요한 이유가 있습니다. 첫째로, 특히 부하 테스트가 긴 경우 부하 테스트 결과 리포지토리에서 타이밍 정보 데이터를 저장하는 데 필요한 공간이 매우 클 수 있습니다. 또한, 이 데이터는 부하 테스트 실행이 완료될 때까지 부하 테스트 에이전트에 저장되므로 부하 테스트가 끝날 때 부하 테스트 결과 리포지토리에 이러한 데이터를 저장하는 시간이 오래 걸립니다.
부하 테스트 결과 리포지토리에 사용할 수 있는 디스크 공간이 충분한 경우 타이밍 정보 저장소를 사용하여 백분위수 데이터를 가져올 수 있습니다. 타이밍 정보 저장소를 사용할 때는 StatisticsOnly 및 AllIndividualDetails를 선택할 수 있습니다. 두 가지 경우 모두 개별 테스트, 페이지 및 트랜잭션의 시간이 측정되고 개별 타이밍 데이터에서 백분위수 데이터가 계산됩니다. StatisticsOnly를 선택하면 백분위수 데이터가 계산된 후 리포지토리에서 개별 타이밍 데이터가 삭제됩니다. 데이터를 삭제하면 리포지토리에 필요한 공간이 감소합니다. 그러나 SQL 도구를 사용하여 타이밍 정보 데이터를 직접 처리하려는 경우에는 타이밍 정보 데이터가 리포지토리에 저장되도록 AllIndividualDetails를 선택해야 합니다.
새 사용자의 백분율 속성 설정
부하 테스트의 각 시나리오에는 새 사용자의 백분율이라는 속성이 있습니다. 이 속성은 부하 테스트 런타임 엔진에서 웹 브라우저가 수행하는 캐시 작업을 시뮬레이션하는 방식에 영향을 줍니다. 새 사용자의 백분율의 기본값은 100입니다. 이러한 경우 부하 테스트에서 웹 테스트가 반복하여 실행될 때마다 웹 사이트에 처음 방문하는 사용자로 취급되어 브라우저 캐시에 이전에 방문하여 남겨진 웹 사이트 콘텐츠가 없는 것으로 간주됩니다. 따라서 웹 테스트에서 이미지 등의 모든 종속 요청을 비롯한 모든 요청이 다운로드됩니다.
.gif "참고") 참고: |
|---|
웹 테스트에서 캐시 가능한 리소스가 두 번 이상 요청되는 경우는 제외됩니다. |
이미지 등의 캐시 가능한 콘텐츠가 로컬에 캐시되어 있을 가능성이 큰 재방문 사용자가 많은 웹 사이트의 부하를 테스트하는 경우 새 사용자의 백분율에 기본값인 100을 그대로 사용하면 실제 사용 환경에서 발생하는 것보다 많은 다운로드 요청이 생성됩니다. 재방문 사용자가 많은 웹 사이트의 부하를 테스트하는 경우에는 웹 사이트의 전체 방문자 중 처음으로 방문하는 사용자의 백분율을 예측하여 새 사용자의 백분율을 적절히 설정해야 합니다.
SQL 추적 사용
실행 설정에는 SQL 추적 사용이라는 속성이 들어 있습니다. 이 속성을 통해 부하 테스트 지속 시간 동안 Microsoft SQL Server의 추적 기능을 사용할 수 있습니다. 부하 테스트가 실행되는 동안 별도의 SQL Profiler 세션을 시작하는 대신 이 방법을 사용하여 SQL 성능 문제를 진단할 수 있습니다. 이 속성을 사용하면 부하 테스트 분석기에 SQL 추적 데이터가 표시됩니다. SQL 추적 표의 테이블 페이지에서 이 데이터를 볼 수 있습니다.
이 기능을 사용하려면 부하 테스트를 실행하는 사용자에게 SQL 추적을 수행하는 데 필요한 SQL 권한이 있어야 합니다. Rig에서 부하 테스트를 실행하는 경우 컨트롤러 사용자에게 SQL 권한이 있어야 합니다. 또한 추적 데이터 파일을 기록할 디렉터리(일반적으로 네트워크 공유)를 지정해야 합니다. 부하 테스트가 완료되면 추적 데이터 파일을 부하 테스트 리포지토리로 가져와서 부하 테스트에 연결하게 되므로 나중에 부하 테스트 분석기를 사용하여 이 데이터를 확인할 수 있습니다.
자세한 내용은 실행 설정 정보 및 방법: SQL 추적 데이터 통합을 참조하십시오.
적절한 에이전트 컴퓨터 수 유지
에이전트 컴퓨터의 CPU 사용률이 75%를 넘거나 사용 가능한 실제 메모리가 10%를 밑돌게 되면 컴퓨터에 무리를 주게 됩니다. 이러한 경우 부하 테스트에서 에이전트 컴퓨터로 인해 병목 현상이 발생하지 않도록 Rig에 에이전트를 추가해야 합니다.
자세한 내용은 컨트롤러, 에이전트 및 Rig를 참조하십시오.