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