SharePoint Server 2010 성능 테스트
적용 대상: SharePoint Server 2010
마지막으로 수정된 항목: 2016-11-30
이 문서에서는 Microsoft SharePoint Server 2010의 성능을 테스트하는 방법에 대해 설명합니다. 테스트 및 최적화 단계는 효과적인 용량 관리를 위한 핵심적인 구성 요소입니다. 새로운 아키텍처는 프로덕션 환경에 배포하기 전에 테스트를 거쳐야 하며, 디자인한 아키텍처가 성능 및 용량 목표를 달성하도록 하려면 다음과 같은 모니터링 관련 모범 사례와 함께 승인 테스트를 수행해야 합니다. 이렇게 하면 잠재적인 병목 현상이 실제 환경의 사용자에게 영향을 미치기 전에 이를 식별하고 최적화할 수 있습니다. Microsoft Office SharePoint Server 2007 환경에서 업그레이드하는 상황에서 아키텍처를 변경하려는 경우나 SharePoint Server 2010의 새 기능이 발생시키는 사용자 부하를 예측하는 경우에는 새 SharePoint Server 2010 기반 환경이 성능 및 용량 목표를 충족하도록 하는 과정에 테스트가 매우 중요한 역할을 합니다.
환경에 대한 테스트를 마치면 테스트 결과를 분석하여 SharePoint Server 2010의 용량 관리의 1단계: 모델링에서 정한 성능 및 용량 목표를 달성하기 위해 변경해야 할 사항을 확인할 수 있습니다.
다음은 프로덕션 이전 환경에 대해 수행하도록 권장되는 하위 단계입니다.
2단계: 디자인에서 디자인한 초기 아키텍처를 모방한 테스트 환경을 만듭니다.
1단계: 모델링에서 식별한 데이터 집합의 전부 또는 일부로 저장소를 채웁니다.
1단계: 모델링에서 식별한 작업량을 나타내는 가상 부하를 사용하여 시스템에 부하를 발생시킵니다.
테스트를 실행하고 결과를 분석하고 아키텍처를 최적화합니다.
최적화된 아키텍처를 데이터 센터에 배포하고 일부 사용자를 대상으로 하는 파일럿 환경을 배포합니다.
파일럿 결과를 분석하고 잠재적인 병목 현상을 식별하고 아키텍처를 최적화한 다음 필요한 경우 다시 테스트합니다.
프로덕션 환경에 배포합니다.
이 문서를 읽기 전에 SharePoint Server 2010의 용량 관리 및 크기 조정 개요를 살펴보아야 합니다.
이 문서의 내용:
테스트 계획 만들기
테스트 환경 만들기
테스트 및 도구 만들기
테스트 계획 만들기
테스트 계획에 다음 요소가 포함되어 있는지 확인합니다.
프로덕션 환경의 예상 성능 목표치에서 작동하도록 디자인된 하드웨어. 항상 보수적인 기준에 따라 테스트 시스템의 성능을 측정하십시오.
사용자 지정 코드나 구성 요소가 있는 경우 먼저 해당 구성 요소의 성능만 따로 테스트하여 코드나 이러한 요소의 성능과 안정성을 검증해야 합니다. 코드나 구성 요소가 안정적인 것으로 확인되면 이러한 요소를 설치한 상태에서 시스템을 테스트하여 설치되지 않았을 때의 팜 성능과 비교해야 합니다. 사용자 지정 구성 요소는 프로덕션 시스템에서 성능 저하와 안정성 문제를 야기하는 주요 요인입니다.
테스트 목표를 파악합니다. 테스트의 목표가 무엇인지 사전에 이해하고 있어야 합니다. 테스트의 목표가 팜에서 사용하도록 개발된 몇 가지 새로운 사용자 지정 구성 요소의 성능을 검증하는 것인지, 일정량의 콘텐츠를 크롤링하고 인덱싱하는 데 걸리는 시간이 어느 정도인지 확인하는 것인지, 팜에서 지원할 수 있는 초당 요청 수를 확인하는 것인지를 분명히 알고 있어야 합니다. 테스트의 목표는 다양할 수 있습니다. 적절한 테스트 계획을 세우려면 무엇보다도 테스트의 목표를 정해야 합니다.
테스트 목표를 측정하는 방법을 파악합니다. 예를 들어 팜의 처리량을 측정하려는 경우 RPS와 페이지 대기 시간을 측정해야 하고, 검색 성능을 측정하려는 경우 크롤링 시간과 문서가 인덱싱되는 속도를 측정해야 합니다. 테스트 목표를 올바로 이해하면 테스트를 완료하기 위해 반드시 검증해야 할 핵심 성과 지표가 무엇인지 명확하게 정의하는 데 도움이 될 것입니다.
테스트 환경 만들기
테스트 목표가 파악되고 텍스트 목표를 측정하는 방법이 정해졌으며 팜의 용량 요구 사항이 결정되었으면(이 프로세스의 1-2단계에서) 그 다음에는 테스트 환경을 디자인하고 만들어야 합니다. 테스트 환경을 만드는 데 들어가는 시간과 작업이 저평가되는 경우가 종종 있습니다. 테스트 환경을 만들려면 프로덕션 환경을 가능한 한 똑같이 복제해야 합니다. 다음은 테스트 환경을 디자인할 때 고려해야 할 몇 가지 기능입니다.
인증 – Active Directory 도메인 서비스(AD DS), 폼 기반 인증(폼 기반 인증을 사용할 경우 함께 사용할 디렉터리), 클레임 기반 인증 중에서 팜에서 사용할 인증 방식을 결정해야 합니다. 사용 중인 디렉터리에 관계없이 테스트 환경에 포함할 사용자 수와 사용자를 만드는 방식을 검토해야 합니다. 필요한 그룹이나 역할의 수와 그룹이나 역할을 만들고 채우는 방법도 정해야 합니다. 또한 테스트 중 인증으로 인해 병목 현상이 발생하지 않도록 인증 서비스에 충분한 리소스가 할당되도록 해야 합니다.
DNS – 테스트에서 사용될 네임스페이스를 알고 있어야 합니다. DNS 요청에 응답할 서버를 식별하고 서버별로 사용될 IP 주소와 만들어야 할 DNS 항목에 관한 계획을 포함해야 합니다.
부하 분산 – 서버를 두 대 이상 사용한다고 가정할 경우 일종의 부하 분산 솔루션이 필요합니다. 서버를 두 대 이상 사용하는 것이 일반적이며 그렇지 않을 경우 부하 테스트의 결과를 보증할 만큼 부하가 충분히 생성되지 않을 수 있습니다. 하드웨어 부하 분산 장치나 Windows NLB와 같은 소프트웨어 부하 분산을 부하 분산 솔루션으로 사용할 수 있습니다. 사용할 부하 분산 솔루션을 결정하고 해당 솔루션을 빠르고 효율적으로 설정하는 데 필요한 모든 구성 정보를 기록해 둡니다. 또 한 가지 유의해야 할 점은 부하 테스트 에이전트는 일반적으로 30분에 한 번씩만 주소를 사용하여 주소를 URL로 확인한다는 것입니다. 즉, 로컬 호스트 파일이나 라운드 로빈 DNS를 부하 분산에 사용할 경우 테스트 에이전트는 사용 가능한 모든 서버로 부하를 분산하는 대신 모든 단일 요청에 대해 동일한 서버로 요청을 보낼 수 있으므로 부하 분산에 로컬 호스트 파일이나 라운드 로빈 DNS를 사용하지 않아야 합니다.
테스트 서버 – 테스트 환경을 계획할 때 SharePoint Server 2010 팜의 서버뿐만 아니라 테스트를 실행하는 데 필요한 컴퓨터에 대한 계획도 세워야 합니다. 일반적으로 최소한 3대의 서버가 포함되며 이보다 많이 필요할 수도 있습니다. Visual Studio Team System(Team Test Load Agent)을 사용하여 테스트를 수행하는 경우 컴퓨터 중 한 대는 부하 테스트 컨트롤러로 사용됩니다. 일반적으로 2대 이상의 컴퓨터가 부하 테스트 에이전트로 사용됩니다. 부하 테스트 에이전트는 테스트 컨트롤러부터 무엇을 테스트해야 하는지에 대한 명령을 받아서 SharePoint Server 2010 팜에 요청을 실행하는 컴퓨터입니다. 테스트 결과 자체는 SQL Server 기반 컴퓨터에 저장됩니다. 이 컴퓨터는 SharePoint Server 2010 팜에 사용되는 SQL Server 기반 컴퓨터와는 다른 컴퓨터여야 하는데, 팜에 사용되는 SQL Server 기반 컴퓨터에 테스트 데이터를 기록할 경우 SharePoint Server 2010 팜에서 사용할 수 있는 SQL Server 리소스에 영향을 주기 때문입니다. 또한 SharePoint Server 2010 팜이나 도메인 컨트롤러 등에서 서버를 모니터링할 때와 동일한 방식으로 테스트를 실행할 때 테스트 서버를 모니터링하여 설정하려고 하는 팜이 테스트 결과에 잘 반영되도록 해야 합니다. 부하 에이전트나 컨트롤러 자체가 병목 현상을 일으킬 수도 있습니다. 이 경우 테스트에서 관찰되는 처리량은 일반적으로 팜에서 지원할 수 있는 최대 처리량이 아닙니다.
SQL Server – 테스트 환경에서 저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010) 문서의 "SQL Server 구성"과 "저장소 및 SQL Server 성능 유효성 검사 및 모니터링" 섹션에 나와 있는 지침을 따르십시오.
데이터 집합 유효성 검사 – 테스트를 실행할 대상 콘텐츠를 결정할 때 모범 사례 시나리오에서는 기존 프로덕션 시스템의 데이터를 사용한다는 점에 유의하십시오. 예를 들어 프로덕션 팜에서 콘텐츠 데이터베이스를 백업하고 테스트 환경에 복원한 다음 데이터베이스를 연결하여 콘텐츠를 팜으로 가져올 수 있습니다. 직접 구성한 데이터나 예제 데이터에 대해 테스트를 실행하면 콘텐츠 모음의 차이로 인해 결과가 왜곡될 수 있는 위험이 따릅니다.
예제 데이터를 꼭 만들어야 하는 경우에는 다음과 같은 몇 가지 사항을 염두에 두고 콘텐츠를 만드십시오.
모든 페이지를 게시해야 합니다. 어떤 페이지도 체크 아웃되어 있으면 안 됩니다.
탐색이 현실적이어야 합니다. 프로덕션에서 사용될 것으로 예상되지 않는 것은 만들지 마십시오.
프로덕션 사이트에서 사용할 사용자 지정 요소를 고려해야 합니다. 예를 들어 마스터 페이지, 스타일시트, JavaScript 등의 요소를 가능한 한 프로덕션 환경에서와 비슷하게 테스트 환경에서도 모두 구현해야 합니다.
필요한 SharePoint 그룹의 수 및/또는 사용 권한 수준과 사용자에게 이러한 사용 권한을 연결하는 방법을 결정합니다.
프로필 가져오기를 수행해야 하는지 여부와 이 작업에 소요되는 시간을 파악합니다.
대상 그룹이 필요한지 여부와 대상 그룹을 만들고 채우는 방법을 결정합니다.
추가 검색 콘텐츠 원본이 필요한지 여부와 추가 검색 콘텐츠 원본을 만드는 데 필요한 것이 무엇인지 결정합니다. 추가 검색 콘텐츠 원본을 만들 필요가 없는 경우 검색 콘텐츠 원본을 크롤링하기 위해 네트워크에 액세스할 수 있는지 여부를 결정합니다.
문서, 목록, 목록 항목 등 예제 데이터가 충분한지 확인합니다. 충분하지 않을 경우 이 콘텐츠를 만드는 방법을 계획합니다.
검색을 적절히 테스트할 수 있도록 고유 콘텐츠를 충분히 준비합니다. 흔히 같은 문서를 수백, 수천 번 다른 이름의 여러 문서 라이브러리에 업로드하는 실수를 저지르곤 합니다. 이 경우 쿼리 프로세서에서 중복 검색을 수행함으로써 불필요하게 시간을 소모하게 되므로 검색 성능에 영향을 주게 됩니다. 프로덕션 환경에서 실제 콘텐츠를 검색할 때는 이러한 일이 발생하지 않아야 합니다.
테스트 및 도구 만들기
테스트 환경이 작동하기 시작하면 팜의 성능을 측정하는 데 사용할 테스트를 만들고 조정해야 합니다. 이 섹션에서는 부하 테스트 도구로 Visual Studio Team System(Team Test Load Agent)을 특정하여 언급하지만 대부분의 개념은 사용 중인 부하 테스트 도구에 관계없이 적용되는 것들입니다. Visual Studio Team System에 대한 자세한 내용은 MSDN(https://msdn.microsoft.com/ko-kr/library/fda2bad5.aspx)의 Visual Studio Team System(영문일 수 있음)을 참조하십시오.
SharePoint 2010 팜의 부하 테스트에 SharePoint LKT(Load Test Kit)를 VSTS와 함께 사용할 수도 있습니다. SharePoint LKT는 Windows SharePoint Services 3.0 및 Microsoft Office SharePoint Server 2007 IIS 로그를 기반으로 Visual Studio Team System 2008 부하 테스트를 생성합니다. 용량 계획 연습이나 업그레이드 전 스트레스 테스트의 일환으로 VSTS 부하 테스트를 사용하여 SharePoint Foundation 2010 또는 SharePoint Server 2010에 대해 가상 부하를 생성할 수 있습니다.
LKT는 Microsoft 다운로드 센터(영문일 수 있음)(https://www.microsoft.com/downloads/details.aspx?familyid=718447d8-0814-427a-81c3-c9c3d84c456e)(영문일 수 있음)에서 다운로드할 수 있는 Microsoft SharePoint 2010 Administration Toolkit v1.0에 포함되어 있습니다.
테스트를 성공으로 이끄는 핵심 조건은 프로덕션 SharePoint Server 2010 팜에서 사용자가 광범위한 종류의 콘텐츠에 액세스할 때처럼 광범위한 테스트 사이트 데이터에 대해 요청을 생성하여 현실적인 작업량을 효과적으로 시뮬레이션하는 것입니다. 일반적으로 이를 위해서는 데이터에 기반을 두도록 테스트를 구성해야 합니다. 특정 페이지에 액세스하도록 하드 코딩된 개별 테스트를 수백 개 만드는 대신 해당 항목에 대한 URL이 포함된 데이터 원본을 사용하는 테스트를 몇 개만 만들어 해당 페이지 모음에 동적으로 액세스해야 합니다.
Visual Studio Team System(Team Test Load Agent)에서 데이터 원본은 다양한 형식을 취할 수 있지만 대개 CSV 파일 형식이 개발 환경과 테스트 환경 간에 관리 및 전송을 가장 손쉽게 수행할 수 있는 형식입니다. 해당 콘텐츠를 포함하는 CSV 파일을 만드는 경우 사용자 지정 도구를 만들어 SharePoint Server 2010 기반 환경을 열거하고 사용되는 다양한 URL을 기록해야 한다는 점을 염두에 두십시오.
도구를 사용해야 하는 작업은 다음과 같습니다.
폼 기반 인증을 사용하는 경우, Active Directory 또는 다른 인증 저장소에 사용자 및 그룹 만들기
사이트, 목록 및 라이브러리, 목록 항목, 문서 등의 URL을 열거하고 부하 테스트를 위해 CSV 파일에 저장
광범위한 문서 라이브러리 및 사이트에 예제 문서 업로드
사이트 모음, 웹, 목록, 라이브러리, 폴더 및 목록 항목 만들기
내 사이트 만들기
테스트 사용자의 사용자 이름과 암호를 포함하는 CSV 파일 만들기. 이 사용자 이름은 부하 테스트를 실행할 때 사용할 사용자 계정입니다. 예를 들어 일부 파일에는 관리자만 포함하고 다른 일부 파일에는 승격된 권한이 있는 다른 사용자(예: 만든 이/참가자, 계층 구조 관리자 등)를 포함할 수 있도록 파일이 여러 개 있어야 합니다.
예제 검색 키워드 및 구문 목록 만들기
사용자 및 Active Directory 그룹(또는 폼 기반 인증을 사용하는 경우 역할)으로 SharePoint 그룹 및 사용 권한 수준 채우기
웹 테스트를 만들 때 꼼꼼히 살펴보고 구현해야 할 다음과 같은 다른 모범 사례가 있습니다.
단순한 웹 테스트를 기록하는 것으로 시작합니다. 이러한 테스트에는 URL, ID 등의 매개 변수에 대한 값이 하드 코딩되어 있습니다. 하드 코딩된 값을 CSV 파일의 링크로 바꿉니다. Visual Studio Team System(Team Test Load Agent)에서 이러한 값을 데이터 바인딩하는 작업은 매우 쉽습니다.
항상 테스트에 대한 유효성 검사 규칙을 만듭니다. 예를 들어 페이지를 요청하는 경우 오류가 발생하면 응답으로 error.aspx 페이지가 나타납니다. 웹 테스트의 관점에서는 부하 테스트 결과로 HTTP 상태 코드 200(성공)을 받았기 때문에 이 응답이 다른 긍정적인 응답과 다를 바가 없습니다. 그러나 분명히 오류가 발생했기 때문에 이 응답은 다른 방식으로 추적되어야 합니다. 유효성 검사 규칙을 하나 이상 만들면 특정 텍스트가 응답으로 전송되는 경우 이를 트래핑하여 유효성 검사가 실패하고 요청이 실패로 표시되도록 할 수 있습니다. 예를 들어 Visual Studio Team System(Team Test Load Agent)에서 ResponseUrl validation이라는 간단한 유효성 검사 규칙을 만들 수 있습니다. 이 규칙에서는 리디렉션된 후 렌더링되는 페이지가 테스트에 기록된 것과 동일한 응답 페이지가 아니면 실패를 기록합니다. 응답에서 "액세스 거부"와 같은 단어를 발견하면 실패를 기록하는 FindText 규칙을 추가할 수도 있습니다.
다양한 역할에 속한 여러 사용자를 테스트에 포함합니다. 출력 캐싱과 같은 특정 동작은 현재 사용자의 권한에 따라 다르게 작동합니다. 예를 들어 사이트 모음 관리자나 승인 또는 제작 권한이 있는 인증된 사용자의 경우 항상 콘텐츠의 가장 최신 버전을 봐야 하므로 이들 사용자에게는 캐시된 결과가 제공되지 않습니다. 그러나 익명 사용자에게는 캐시된 콘텐츠가 제공됩니다. 프로덕션 환경의 사용자 조합과 거의 일치하도록 다양한 역할을 고루 혼합하여 테스트 사용자를 구성해야 합니다. 예를 들어 프로덕션 환경에서는 사이트 모음 관리자가 대개 두세 명입니다. 따라서 사이트 모음 관리자 계정에서 테스트 콘텐츠에 대해 만드는 페이지 요청이 총 페이지 요청의 10%에 이르지 않도록 테스트를 구성해야 합니다.
구문 분석에 종속된 요청은 Visual Studio Team System(Team Test Load Agent)의 한 특성으로, 테스트 에이전트가 해당 페이지만 검색할지 아니면 페이지와 함께 페이지에 포함된 이미지, 스타일시트, 스크립트 등에 대한 관련 요청까지 모두 검색할지 여부를 결정합니다. 부하 테스트를 수행할 때 일반적으로 이러한 항목을 무시하는데 몇 가지 이유는 다음과 같습니다.
사용자가 사이트를 처음 방문한 후에는 이러한 항목이 대개 로컬 브라우저에 캐시됩니다.
SharePoint Server 2010 기반 환경에서 이러한 항목은 일반적으로 SQL Server에서 가져오지 않습니다. BLOB 캐싱이 설정된 상태에서는 대신 웹 서버에서 이러한 항목을 제공하므로 SQL Server 부하가 생성되지 않습니다.
사이트 최초 방문자의 비율이 지속적으로 높거나 브라우저 캐싱을 해제했거나 몇 가지 이유로 BLOB 캐시를 사용하지 않으려는 경우에는 테스트에서 구문 분석에 종속된 요청을 사용하는 것이 적절합니다. 그러나 구문 분석에 종속된 요청은 아주 예외적인 경우에만 사용하며 대부분의 구현에서 경험을 바탕으로 검증된 규칙이 아닙니다. 구문 분석에 종속된 요청을 사용할 경우 테스트 컨트롤러에서 보고하는 RPS 수가 크게 증가할 수 있다는 점에 유의하십시오. 이러한 요청은 아주 빠르게 처리되므로 팜의 사용 가능한 용량이 실제보다 많다고 잘못 판단하게 될 수도 있습니다.
클라이언트 응용 프로그램 작업도 모델링해야 합니다. Microsoft Word, PowerPoint, Excel 및 Outlook과 같은 클라이언트 응용 프로그램에서도 SharePoint Server 2010 팜에 대해 요청을 생성합니다. 이러한 응용 프로그램은 RSS 피드 검색과 같은 서버 요청을 보내고, 자세한 개인 정보를 구하고, 사이트 및 목록 구조에 대한 세부 정보를 요청하고, 데이터를 동기화하는 등 환경에서 받는 부하를 추가합니다. 이러한 클라이언트가 구현에 포함된 경우에는 이와 같은 종류의 요청도 테스트에 포함하고 모델링해야 합니다.
대부분의 경우 웹 테스트에는 단일 요청만 포함해야 합니다. 웹 테스트에 단일 요청만 포함되어 있으면 테스트 도구 및 개별 요청을 조정하고 문제를 해결하기가 쉽습니다. 테스트에서 시뮬레이션하는 작업이 여러 요청으로 이루어진 경우에는 일반적으로 웹 테스트에 여러 요청을 포함해야 합니다. 예를 들어 일련의 작업을 테스트하려면 문서 체크 아웃, 문서 편집, 문서 체크 인 및 게시와 같은 여러 단계를 포함하는 테스트가 필요하며, 단계 간에 상태도 보유되어야 합니다. 예를 들어 체크 아웃, 편집 및 체크 인에 모두 동일한 사용자 계정이 사용되어야 합니다. 각 단계 간에 상태가 전달되어야 하는 이러한 여러 단계 작업은 단일 웹 테스트에 여러 요청을 포함했을 때 가장 효과적으로 처리할 수 있습니다.
각 웹 테스트를 개별적으로 테스트합니다. 대규모 부하 테스트에서 실행하기 전에 먼저 각 테스트를 성공적으로 완료할 수 있는지 확인합니다. 웹 응용 프로그램의 이름이 모두 확인되는지와 테스트에 사용된 사용자 계정에 테스트를 실행하는 데 필요한 권한이 있는지 확인합니다.
웹 테스트는 개별 페이지에 대한 요청, 문서 업로드, 목록 항목 보기 등으로 이루어집니다. 이러한 모든 웹 테스트를 부하 테스트에 통합할 수 있습니다. 부하 테스트는 실행하려는 여러 다른 웹 테스트를 연결하는 데 사용할 수 있는 수단입니다. 각 웹 테스트가 실행될 시간을 백분율로 지정할 수 있습니다. 예를 들어 프로덕션 팜에서 요청의 10%가 검색 쿼리임이 확인되면 부하 테스트에서 전체 시간의 10%를 실행하도록 쿼리 웹 테스트를 구성할 수 있습니다. Visual Studio Team System(Team Test Load Agent)에서는 브라우저 혼합 비율, 네트워크 혼합 비율, 부하 패턴 및 실행 설정 등을 구성하는 수단으로 부하 테스트를 사용할 수도 있습니다.
부하 테스트에서 주의해서 살펴보고 관찰하고 구현해야 할 몇 가지 추가 모범 사례가 있습니다.
테스트에서 읽기/쓰기 비율을 적절히 조정합니다. 테스트에서 쓰기 수가 지나치게 많으면 테스트의 전반적인 처리량에 많은 영향을 줄 수 있습니다. 공동 작업 팜의 읽기/쓰기 비율에서은 쓰기보다 읽기가 더 많은 비중을 차지하는 경향이 있습니다. 자세한 내용은 성능 및 용량 기술 사례 연구(SharePoint Server 2010)를 참조하십시오.
리소스를 많이 사용하는 다른 작업의 영향을 고려해 부하 테스트 중 이러한 작업이 발생되도록 할지 여부를 결정합니다. 예를 들어 백업 및 복원과 같은 작업은 일반적으로 부하 테스트 중 수행되지 않습니다. 전체 검색 크롤링도 일반적으로 부하 테스트 중 실행되지 않지만 증분 크롤링은 일반적으로 수행됩니다. 프로덕션 환경에서 이러한 작업이 예약되는 방식 즉, 이러한 작업이 부하가 많은 시간에 실행되는지 등을 검토해 보아야 합니다. 부하가 많은 시간에 실행되지 않는 경우에는 최대 트래픽에 대해 지원할 수 있는 안정적인 상태의 최대 부하를 결정할 때 이러한 작업을 부하 테스트에서 제외해야 합니다.
인지 시간을 사용하지 마십시오. 인지 시간은 사용자가 페이지에서 클릭하는 사이의 일시 중지하는 시간을 시뮬레이션하는 데 사용할 수 있는 Visual Studio Team System(Team Test Load Agent)의 기능입니다. 예를 들어 일반적인 사용자는 페이지를 로드하고 3분 가량 페이지를 읽어본 다음 페이지의 링크를 클릭하여 다른 사이트를 방문합니다. 테스트 환경에서 이 상황을 제대로 모델링하는 것은 거의 불가능하며 테스트 결과에 별다른 의미를 주지도 않습니다. 이 상황을 모델링하는 것이 어려운 이유는 대부분의 조직에는 다양한 사용자와 이들 사용자가 여러 유형의 SharePoint 사이트(예: 게시, 검색, 공동 작업 등)에서 클릭하는 사이에 경과하는 시간을 모니터링할 방법이 없기 때문입니다. 사용자는 페이지 요청 간에 일시 중지하더라도 SharePoint Server 2010 기반 서버에서는 일시 중지하지 않으므로 이 상황을 모델링한다 해도 실질적으로 아무런 효과가 없습니다. 시간의 경과에 따라 요청 수가 늘어나거나 줄어들 수는 있지만 서버에서는 이를 일정한 요청 스트림으로 받을 뿐이며, 각 사용자가 페이지의 링크를 클릭하는 사이에 일시 중지해 있는 동안에도 서버에서는 유휴 상태로 대기하지 않기 때문입니다.
사용자와 요청의 차이를 이해해야 합니다. Visual Studio Team System(Team Test Load Agent)에는 시뮬레이션하려는 사용자 수를 입력할 것을 요청하는 부하 패턴이 있습니다. 이 사용자 수는 응용 프로그램 사용자와는 아무런 관련이 없으며 실제로는 요청을 생성하기 위해 부하 테스트 에이전트에서 사용될 스레드 수를 나타낼 뿐입니다. 일반적으로 잘못 생각하는 부분을 예로 들어 보겠습니다. 예를 들어 배포에 5,000명의 사용자가 포함된다고 하면 이 5,000이라는 숫자가 Visual Studio Team System(Team Test Load Agent)에서 사용될 사용자의 수를 나타낸다고 생각하기 쉽지만 실제로는 그렇지 않습니다. 다른 이유도 여러 가지가 있지만 바로 이 때문에 용량 계획 요구 사항을 예측할 때는 사용자 수가 아니라 초당 요청 수에 기반을 두어야 합니다. Visual Studio Team System(Team Test Load Agent) 부하 테스트에서는 종종 50~75명의 부하 테스트 "사용자"만 사용하여 초당 수백 개의 요청을 생성할 수 있습니다.
일정한 부하 패턴을 사용하여 안정적이고 재현이 가능한 테스트 결과를 얻어야 합니다. Visual Studio Team System(Team Test Load Agent)에는 일정 사용자 수(앞에서 설명한 바와 같이 스레드 수), 단계별로 증가하는 사용자 부하 패턴 또는 목표 기반 사용량 테스트를 기준으로 부하를 계산하는 옵션이 있습니다. 단계 부하 패턴은 소수의 사용자로 시작한 다음 몇 분마다 사용자 수를 "단계별로" 늘리는 부하 패턴입니다. 목표 기반 사용량 테스트는 CPU 사용률과 같은 특정 진단 카운터의 임계값을 설정하여 해당 카운터 값을 정의된 최소 임계값과 최대 임계값 사이에서 유지하기 위해 부하를 발생시키는 부하 패턴입니다. 단지 SharePoint Server 2010 팜에서 부하가 많은 시간 동안 감당할 수 있는 최대 처리량만 확인하려는 경우에는 일정 부하 패턴을 선택하는 것이 더 효과적이고 정확합니다. 이렇게 하면 시스템이 정기적으로 임계값(정상적인 상태의 팜에서 유지되어야 하는 임계값)을 초과하기 전까지 처리할 수 있는 부하의 양이 어느 정도인지 쉽게 식별할 수 있습니다.
부하 테스트를 실행할 때마다 데이터베이스의 데이터가 변경된다는 점에 유의하십시오. 문서 업로드, 목록 항목 편집, 사용량 데이터베이스의 작업 기록 등 어떤 작업을 수행하든 관계없이 SQL Server에 데이터가 기록됩니다. 각 부하 테스트에서 일관되고 적법한 테스트 결과 집합을 얻으려면 첫 번째 부하 테스트를 실행하기 전에 백업을 준비해 두어야 합니다. 각 부하 테스트가 완료된 후에는 이 백업을 사용하여 테스트를 시작하기 전의 상태로 콘텐츠를 복원해야 합니다.
See Also
Concepts
SharePoint Server 2010의 용량 관리 및 크기 조정 개요
SharePoint Server 2010의 용량 관리
SharePoint Server 2010 모니터링 및 유지 관리
상태 모니터링(SharePoint Server 2010)
저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010)