웹 콘텐츠 관리에 필요한 용량 및 성능 평가(SharePoint Server 2013)
적용 대상:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
기업에서는 종종 SharePoint Server 2013을 사용하여 익명 사용자가 인터넷 사이트에 액세스하거나 인증된 사용자가 인트라넷 사이트에 액세스하는 콘텐츠를 게시합니다. 이 문서에는 사용할 컴퓨터 수와 SharePoint Server 2013에서 콘텐츠를 게시하고 웹 콘텐츠를 관리하는 데 필요한 컴퓨터 유형을 계획하는 데 도움이 되는 용량 및 성능 데이터가 포함되어 있습니다.
SharePoint 게시에는 다양한 유형의 게시 사이트와 각 사이트에 사용할 수 있는 관련 방법이 포함되어 있습니다. SharePoint Server 2013의 게시 기능은 브랜드 인터넷, 인트라넷 및 엑스트라넷 사이트를 만드는 데 도움이 됩니다. SharePoint Server 2013 게시에 대한 자세한 내용은 SharePoint Server의 인터넷, 인트라넷 및 엑스트라넷 사이트에 게시 개요를 참조하세요.
소개
이 문서에서는 다음 시나리오를 논의합니다.
인터넷 제공 사이트
고객, 파트너, 투자자 및 잠재적인 직원에 대한 정보를 제공합니다. 이 유형의 사이트를 통해 익명의 인터넷 사용자가 회사 정보를 찾을 수 있습니다. 일반적으로 이러한 사이트는 브랜드가 지정되어 있으며 회사에서 해당 콘텐츠를 엄격하게 제어합니다.
인터넷 비즈니스 사이트
회사에서 고객에게 제공하는 제품과 서비스를 홍보합니다. 이러한 사이트를 통해 회사에서 제공하는 제품 카탈로그를 표시할 수 있습니다.
인트라넷 사이트
회사에서 이 사이트를 조직 내부적으로 게시합니다. 이러한 사이트에서는 인증된 사용자 정보를 공유하며 회사가 사이트를 엄격하게 관리하여 액세스 권한을 제한하거나 전체 내부 사용자에게 공개합니다.
엑스트라넷 사이트
원격 직원, 파트너 및 고객에게 대상이 지정된 콘텐츠에 대한 액세스 권한을 제공합니다. 이러한 사이트에서는 메타데이터로 태그가 지정된 제작 콘텐츠를 사용하여 문서를 분류하는 기술 자료에 대한 액세스 권한을 제공할 수 있습니다. 사용자는 문제 해결 및 지원 문서와 같은 특정 정보를 검색하거나 찾아볼 수 있습니다.
교차 사이트 모음 게시 및 콘텐츠 검색 웹 파트를 사용하면 이러한 시나리오에서 사이트 모음 간에 콘텐츠를 재사용할 수 있습니다. 해당하는 특징과 기능은 용량을 계획하는 방법에 영향을 줍니다. 자세한 내용은 SharePoint Server의 사이트 간 게시 개요를 참조하세요.
참고
이 문서에서는 교차 사이트 모음 게시를 교차 사이트 게시라고 합니다.
SharePoint Server 2013의 관리형 탐색은 게시 사이트에 대한 분류 기반 탐색을 제공합니다. 자세한 내용은 Overview of managed navigation in SharePoint Server를 참조하세요.
이 문서의 용량 및 성능 데이터에는 두 부분으로 구성됩니다. 첫 번째 부분은 새로운 사이트 간 게시 방법 및 관리되는 탐색입니다. 두 번째 부분에서는 현재 위치의 작성자 모델을 사용합니다.
참고
이 문서에서 다루는 시나리오는 교차 사이트 게시 및 전체 제작 사이트에서 모두 활용할 수 있습니다. 교차 사이트 게시 및 관리 탐색 기능은 서로 의존하지 않고 개별적으로 사용할 수 있습니다.
다음의 두 가지 핵심 지표는 이 문서에서 사용되는 모델에서 처리됩니다.
처리량
사이트에서 유지할 수 있는 초당 페이지 보기 수
서버 응답 시간
서버가 요청을 처리하는 데 필요한 시간으로, 사용자가 페이지를 보는 데 소요되는 시간에 영향을 줍니다. 이 문서에 나와 있는 서버 응답 시간은 95번째/50번째 백분위수 값입니다. 이러한 값은 요청의 95%/50%가 제공되는 각 값보다 더 빠르다는 뜻입니다. 지정된 요청에 대해 SharePoint 사용량 데이터베이스에 기록된 "기간"을 사용하여 이러한 값을 측정합니다.
콘텐츠 새로 고침
업데이트한 항목이 검색 결과에 반영되는 데 필요한 시간은 교차 사이트 게시 시나리오에서 작업할 때 고려하기 좋은 지표입니다.
이 문서의 시나리오에서는 다음 두 상태를 사용합니다.
안전 영역
서버 사용률이 60% 미만입니다. 서버가 실행되는 대부분의 시간 동안 대상이 되어야 합니다.
위험 영역
서버는 전체 사용률에 가깝습니다. SharePoint 사이트가 평소보다 더 많은 부하를 받고 있는 상태로 간주될 수 있습니다. 레드 존에서 서버가 들어오는 요청의 수요를 충족하려고 할 때 서버 응답 시간 값이 증가하기 시작합니다.
필수 정보
이 문서를 읽기 전에 SharePoint Server 2013 용량 관리의 주요 개념을 이해해야 합니다. 다음 문서에서는 용량 관리에 권장되는 접근 방법을 알아보고, 이 문서의 정보를 효과적으로 활용하는 방법을 알아볼 수 있는 설명을 제공합니다.
이 문서에 게시 시나리오 기능에 영향을 주는 일부 다른 새 기능은 나와 있지 않습니다. 이러한 시나리오에는 장치 채널, SEO 최적화, 표시 서식 파일 및 쿼리 규칙이 포함됩니다. 또한 이 문서에는 교차 사이트 게시 사이트의 기능과 구성이 자세히 설명되어 있지 않습니다. 자세한 내용은 SharePoint Server에서 사이트 간 게시 계획 및 SharePoint Server에서웹 콘텐츠 관리 솔루션 구성을 참조하세요.
이 문서의 데이터를 이해하는 데 도움이 되는 용량 및 성능에 대한 자세한 내용은 SharePoint Server 2013의 성능 계획을 참조하세요.
관리 탐색을 사용하는 교차 사이트 게시
이 섹션에는 익명 사용자가 포함된 교차 사이트 게시와 전체 제작 게시의 두 영역에 대한 테스트 데이터가 나와 있습니다.
익명 사용자가 포함된 교차 사이트 게시
이 섹션의 테스트 결과는 용량 계획 지침을 제공하는 기본 교차 사이트 게시 사이트 모델을 기반으로 합니다. 익명 사용자가 웹 사이트에 액세스할 수 있는 SharePoint 배포를 계획할 경우 이 지침을 사용하고 그에 따라 배포 사양을 조정하도록 합니다.
Microsft 테스트의 테스트 사례에서는 교차 사이트 게시 기능을 사용합니다. 이 시나리오는 카탈로그로 표시되어 SharePoint Search Service 응용 프로그램에서 크롤링되는 여러 사이트 모음에 콘텐츠를 제공합니다. 콘텐츠 검색 웹 파트 및 카탈로그 항목 재사용 웹 파트와 같이 검색 기술을 사용하는 웹 파트는 다른 사이트의 페이지에 콘텐츠를 표시합니다. 자세한 내용은 SharePoint Server의 사이트 간 게시 개요를 참조하세요.
교차 사이트 게시를 테스트하기 위해 작성한 모델 사이트에서 사용한 특성은 다음과 같습니다.
게시 웹 사이트에는 약 500만 페이지 또는 항목이 있습니다.
항목은 악 1,000개의 범주와 연결되어 있습니다.
콘텐츠는 하나 이상의 카탈로그에 있는 다른 사이트 모음에 있습니다.
웹 사이트는 항목이 관련되어 있는 범주에 링크로 연결된 관리 탐색을 사용합니다.
이 목록의 뒷부분에 설명된 기준 배포 토폴로지의 경우 웹 사이트는 평균 초당 최대 80개의 페이지 보기를 받습니다. 피크 기간은 초당 최대 100페이지 보기에 도달합니다. 이 처리량 수를 확장하려면 토폴로지에 컴퓨팅을 추가합니다. 이 처리량 수를 축소하려면 토폴로지에서 컴퓨터를 제거합니다.
검색 크롤러는 카탈로그를 초당 5번 업데이트하면서 1분 간격으로 연속 크롤링을 실행합니다.
웹 사이트의 페이지/트래픽 패턴은 다음과 같습니다.
콘텐츠 검색 웹 파트 3개와 구체화 패널 웹 파트 한 개가 포함된 홈 페이지에서 트래픽 15%를 수신합니다.
콘텐츠 검색 웹 파트 세 개, 분류 구체화 패널 웹 파트 한 개 및 구체화 패널 웹 파트 한 개가 포함된 범주 페이지에서 트래픽 45%를 수신합니다.
카탈로그 항목 재사용 웹 파트와 콘텐츠 검색 웹 파트 두 개가 포함된 카탈로그 항목 페이지에서 트래픽 40%를 수신합니다.
각 콘텐츠 검색 및 카탈로그 항목 재사용 웹 파트에서 동기 쿼리를 실행합니다.
카탈로그 항목 페이지에서는 트래픽을 소량 수신하므로 익명 검색 결과 캐시를 사용하지 않습니다.
팜에서는 프런트 엔드 웹 서버로 실행되는 컴퓨터의 BLOB(Binary Large Object) 캐시가 켜져 있습니다.
이 시나리오를 테스트하는 데 사용한 서버 토폴로지가 다음 다이어그램에 나와 있습니다.
그림 1: 테스트 랩 서버 토폴로지
SharePoint에서 사용하는 모든 데이터베이스를 사용하여 SQL Server를 호스트하는 컴퓨터 1대
SharePoint Service 응용 프로그램, 분산 캐시 서비스, 검색 분석 처리 및 검색 관리 역할을 호스팅하는 컴퓨터 한 대
검색 크롤러 및 콘텐츠 처리(CPC) 역할을 호스팅하는 컴퓨터 한 대
쿼리 처리를 사용하여 검색 인덱스 노드를 호스팅하고 프런트 엔드 웹 서버로 작동하는 컴퓨터 세 대
참고
이 테스트의 컴퓨터는 Windows Server 2008 R2를 실행하는 물리적 컴퓨터입니다. 가상 머신 및 Windows Server 2012를 사용하는 방법에 대한 권장 사항은 SharePoint Server 2013 에 대한 검색 용량 계획 및 용량 계획을 참조하세요.
중요
Microsoft 테스트 랩 토폴로지의 구성은 검색 기반 게시 시나리오에 최적화되어 있습니다. 이 구성은 공동 작업 유형의 SharePoint 배포와 다릅니다. 예를 들면 당사 구성은 프런트 엔드 웹 서버를 검색 인덱스 서버로 사용하여 최고의 성능을 얻습니다. > 테스트 랩 토폴로지에서 애플리케이션 서버를 호스트하는 컴퓨터의 사용이 미달이라는 것을 알게 되었습니다. 따라서 전용 서버 대신 이 애플리케이션 서버에 분산 캐시 서비스를 배치합니다. 환경의 전용 서버에서 분산 캐시 서비스를 호스트하기로 결정할 수 있습니다. 최상의 성능을 위해 검색 인덱스 서버 역할이 있는 프런트 엔드 웹 서버에서 분산 캐시 서비스를 호스트하지 않는 것이 좋습니다.
테스트 랩 보고서
테스트 랩에서는 실제 컴퓨터와 VSTS(Visual Studio Team System) 부하 테스트가 그림 1의 토폴로지와 함께 사용되었습니다. 자세한 내용은 Visual Studio 팀 시스템을 참조하세요. 테스트 컴퓨터의 기술 사양은 다음 표에 나와 있습니다.
참고
VSTS 테스트에서는 이미지나 JavaScript 파일 같은 브라우저 캐싱 또는 종속 요청을 사용하지 않았습니다. 게시 사이트를 사용자 지정하는 방식에 따라 발생하는 종속 요청의 양은 크게 달라질 수 있습니다. > 테스트에서 사용한 페이지는 거의 50페이지 로드 시간 1(PLT1) 요청 유형(빈 브라우저 캐시) 및 PLT2 요청 유형에 대한 약 3개 요청(브라우저 캐시의 결과가 포함된 후속 요청)을 만들었습니다. 일반적으로 SharePoint BLOB 캐시는 이러한 항목에 대한 요청을 처리하며, 성능 수치를 많이 변경하지는 않습니다.
| 서버 구성 요소 | SharePoint Server 실행 서버 |
|---|---|
| 프로세서 | Intel Xeon CPU @2.27GHz(프로세서 2개, 코어 총 8개, 스레드 총 16개) |
| RAM | 24GB |
| 운영 체제 | Windows Server 2008 R2 Enterprise SP1, 64비트 |
| SharePoint 드라이브 크기 | 내부 디스크에 200GB |
| 검색 인덱스에 사용되는 저장소 | 외부 디스크 배열에 78GB(Dell PERC H700 SCSI 2개) |
| 네트워크 어댑터 수 | 2 |
| 네트워크 어댑터 속도 | 1GB |
| 인증 | 없음 - 익명 |
| 소프트웨어 버전 | SharePoint Server 2013 |
| 서버 구성 요소 | 데이터베이스 서버 |
|---|---|
| 프로세서 | Intel Xeon CPU L5520 @2.27GHz(프로세서 2개, 코어 총 8개, 스레드 총 16개) |
| RAM | 24GB |
| 운영 체제 | Windows Server 2008 R2 Enterprise SP1, 64비트 |
| 디스크 배열 | Dell H700 SCSI 2개 |
| 네트워크 어댑터 수 | 2 |
| 네트워크 어댑터 속도 | 1GB |
| 인증 | NTLM |
| 소프트웨어 버전 | Microsoft SQL Server 2008 R2 SP1 |
10분간 실행하여 얻은 결과가 다음과 같습니다.
| 기능 테스트 | 안전 영역 | 위험 영역 |
|---|---|---|
| VSTS 사용자 수(동시 사용자 시뮬레이션): | 60 | 100 |
| 서버 응답 시간 50번째 백분위 수*: | 219ms | 302ms |
| 서버 응답 시간 95번째 백분위 수*: | 412ms | 635ms |
| 초당 페이지 보기: | 78 | 98 |
검색 인덱스의 콘텐츠를 표시하는 사이트 간 게시 시나리오입니다. 검색 쿼리를 호스트하는 서버가 제공하는 쿼리 수와 익명 결과 캐시에서 제공하는 쿼리 수를 살펴보는 것이 흥미로울 수 있습니다. 이 모델에서 익명 결과 캐시는 쿼리의 약 60%를 제공합니다. 익명 결과 캐시는 이 문서의 뒷부분에 설명되어 있습니다.
| 기능 테스트 | 안전 영역 | 위험 영역 |
|---|---|---|
| 초당 총 쿼리 수: | 235 | 294 |
| 익명 결과 캐시에서 처리된 쿼리 수: | 145 | 182 |
| 검색에서 처리된 쿼리 수: | 90 | 112 |
테스트를 실행하는 동안 해당 컴퓨터의 평균 CPU/최대 메모리 사용량은 다음과 같습니다.
| 기능 테스트 | 안전 영역 | 위험 영역 |
|---|---|---|
| 평균 CPU(프런트 엔드 웹 서버당 검색 인덱스 노드) | 59% | 80% |
| 평균 CPU(분산 캐시를 포함하는 응용 프로그램 서버) | 8% | 9% |
| 평균 CPU(검색 CPC 노드) | 5% | 5% |
| 평균 CPU(SQL Server) | 측정되지 않음 | 측정되지 않음 |
| 최대 메모리 사용량(프런트 엔드 웹 서버당 검색 인덱스 노드) | 7.5GB | 7.5GB |
| 최대 메모리 사용량(분산 캐시를 포함하는 응용 프로그램 서버) | 10.1GB | 10GB |
| 최대 메모리 사용량(검색 CPC 노드) | 6.5GB | 6.5GB |
정상적으로 사용할 때 서버에서는 다양한 타이머 작업이 실행되므로 메모리 사용량이 약간 다를 수 있습니다. 부하가 지속적으로 유지되는 2주간의 테스트를 실행한 후에 인덱스/프런트 엔드 웹 서버 노드가 12GB의 메모리를 사용한다는 사실을 알게 되었습니다.
교차 사이트 게시 페이지에 검색 웹 파트가 콘텐츠를 표시하는 방법
게시 페이지에 콘텐츠 검색 웹 파트와 같은 검색 웹 파트가 포함된 경우 검색 쿼리가 완료되기 전에 브라우저가 페이지를 처리하기 시작합니다. 이렇게 하면 페이지의 대기 시간이 향상됩니다. 검색 쿼리가 완료되면 쿼리의 전체 결과가 브라우저로 전송되고 브라우저에 대한 연결이 닫힙니다. 사용자는 검색 결과가 비동기적으로 로드되었다고 생각할 수 있습니다. 그러나 페이지가 요청되는 동안 서버에서 쿼리가 계속 실행됩니다.
콘텐츠 검색 웹 파트에는 별도의 비동기 모드가 있는데, 이 모드에서는 페이지가 로드된 후 브라우저에서 쿼리가 실행됩니다.
교차 사이트 게시 사이트에 대한 부하 변경 시 미치는 영향
부하 테스트에 사용된 VSTS 사용자 수(사이트에 액세스한 동시 사용자 수와 유사)를 달리했습니다. 다음 그래프를 통해 부하가 증가하면 서버 응답 시간이 증가하고 초당 처리되는 페이지 수가 점차 증가한다는 점을 알 수 있습니다. 사용자에게 SharePoint 배포에 반응하는 환경을 제공하려면 서버 응답 시간을 750ms 미만으로 유지하는 것이 좋습니다.
그림 2: 다양한 부하에서의 처리량과 서버 응답 시간을 나타낸 차트
교차 사이트 게시 사이트 수평 확장
SharePoint 배포가 앞서 설명한 기준 사례보다 더 많거나 더 적은 트래픽을 수신할 경우, 사용자는 팜에서 인덱스 및 프런트 엔드 웹 서버 역할로 실행되는 컴퓨터 수를 변경하여 해당 트래픽을 수용하려고 할 수 있습니다. 다음 그래프에는 부하 패턴이 서로 다르고, 인덱스 노드가 포함된 프런트 엔드 웹 서버로 사용되는 컴퓨터를 1대부터 6대까지 보유하도록 동일한 교차 사이트 게시 사이트를 확장한 경우의 결과가 나와 있습니다.
그림 3: 배포 수평 확장
각 구성에서 이전 섹션의 기준과 비교하여 서버 응답 시간 값이 비슷하게 유지되도록 부하를 조정했습니다.
컴퓨터 수가 증가하면서 토폴리지의 복잡성도 그에 못지않게 증가하고 있습니다. 각각의 추가 컴퓨터는 해당 환경에서 이미 사용 중인 컴퓨터와 비교할 때 처리량이 더 적습니다. 이러한 숫자는 스케일 아웃 패턴을 표시하기 위해 제공됩니다. SharePoint 배포를 빌드하는 방법에 따라 실제 성능이 변경됩니다.
사이트 계획 지침
대부분의 성능 테스트에서는 이전 섹션에 설명된 배포를 사용했습니다. 다음 목록에 나와 있는 지침은 배포가 테스트 랩에서 사용된 것과 다를 때 용량 계획을 올바로 결정하는 데 도움을 주기 위한 것입니다.
검색 인덱스에서 항목이 많을수록 일반적으로 대기 시간이 더 짧아질 수 있습니다. 각 인덱스 파티션에는 최대 1,000만 개의 항목이 포함될 수 있습니다. 일반적인 웹 사이트에는 1,000만 개 이상의 항목이 거의 표시되지 않습니다. 따라서 앞에서 설명한 토폴로지와 같이 하나의 파티션만 필요합니다. 더 많은 인덱스 파티션을 사용하여 1,000만 개 이상의 항목을 호스트하거나 더 많고, 더 작고, 더 빠른 인덱스 파티션을 가질 수 있습니다. 여러 인덱스 파티션을 사용하려는 경우 SharePoint Server에서 인터넷 사이트에 대한 검색 크기 조정 을 참조하여 검색 토폴로지의 크기를 올바르게 조정합니다.
페이지 또는 페이지 레이아웃에 추가하는 각 컨트롤이나 웹 파트는 페이지에 대한 서버 응답 시간에 오버헤드를 발생시킵니다.
한 페이지에 5개가 넘는 동기 콘텐츠 검색 웹 파트 또는 카탈로그 항목 재사용 웹 파트를 사용하지 않도록 합니다. 페이지에 대한 요청을 처리하는 동안 SharePoint Server 2013은 최대 5개의 쿼리를 병렬로 실행하고 결과를 반환합니다. 페이지에 5개 이상의 쿼리가 있는 경우 SharePoint Server 2013은 다음 5개의 쿼리 집합을 실행하기 전에 처음 5개의 쿼리를 실행합니다. 페이지가 5개가 넘는 콘텐츠 검색 웹 파트나 카탈로그 항목 재사용 웹 파트를 요청하는 경우에는 비동기 모드로 추가 콘텐츠 검색 웹 파트를 실행하거나 쿼리 규칙 및 결과 블록을 사용할 수 있습니다.
콘텐츠 검색 웹 파트 및 카탈로그 항목 재사용 웹 파트에는 비동기 모드가 있습니다. 웹 파트와 연결된 쿼리는 브라우저가 페이지를 로드하면 실행됩니다. 저속 쿼리에서는 이 모드를 이용하여 나머지 페이지가 사용자에게 더 빠르게 표시되도록 합니다. 그렇지 않은 경우 동기 쿼리를 사용하여 페이지 로드 시간을 최적화하는 것이 좋습니다.
구체화 기능이 많이 포함된 구체화 패널 웹 파트는 쿼리 처리 시간을 증가시킵니다. 사용자는 관리 속성에 표시되는 구체화 수를 변경할 수 있습니다. 자세한 내용은 SharePoint Server에서 구체화 및 패싯 탐색 구성을 참조하세요.
탐색 노드의 계층 구조가 깊을 때 분류 구체화 패널 웹 파트를 사용하면 쿼리 처리 시간이 늘어납니다. 탐색 노드가 200개가 넘는 페이지에서는 분류 구체화 패널 웹 파트를 사용하지 않는 것이 좋습니다. 탐색 노드 수가 많으면 서버 응답 시간이 느려지고 처리량이 줄어들 수 있습니다.
고가용성을 위해 SharePoint 배포를 디자인해야 하는 경우 다음을 추가해야 합니다.
기존 컴퓨터를 사용할 수 없는 경우 분산 캐시 역할의 서비스 응용 프로그램을 실행하는 추가 컴퓨터
인덱스 노드가 포함된 하나 이상의 프런트 엔드 웹 서버 컴퓨터를 사용할 수 없는 경우 부하를 유지하기 위한 추가 컴퓨터
CPC 역할이 포함된 컴퓨터를 사용할 수 없을 때 업데이트가 사이트에 계속 반영되도록 하기 위한 CPC 역할의 추가 컴퓨터
데이터베이스 서버 중 하나를 사용할 수 없는 경우 데이터베이스 쿼리를 계속 제공하는 SQL Server 토폴로지
검색 크롤링 속도 및 콘텐츠 최신 상태
테스트할 때 게시 중인 카탈로그 콘텐츠를 업데이트하는 프로세스에 대한 테스트도 수행했습니다. 그런 다음 게시 사이트에 업데이트된 항목이 나타나기 전까지 경과된 시간을 관찰했습니다. 이 실험에서는 카탈로그를 초당 5번 업데이트하고 카탈로그에 대한 연속 크롤링을 1분 간격으로 설정했습니다. Microsoft는 변경 내용이 게시 사이트에 나타나는 평균 시간이 약 2분이라는 사실을 확인했습니다. 최소 시간은 1분도 되지 않았고 최대 시간은 3분이었습니다. CPC 역할로 실행되던 컴퓨터 수를 늘려도 이러한 수치가 크게 달라지지는 않았습니다.
그러나 카탈로그의 전체 크롤링에서는 CPC 역할로 실행되는 컴퓨터의 수가 늘어나면 초당 처리되는 항목 수도 늘어났습니다. 다음 그래프에는 CPC 역할이 포함된 팜의 컴퓨터 수와 초당 처리되는 항목 수의 관계가 나와 있습니다. 이 테스트 데이터는 기준 테스트에 사용되지 않는 SharePoint 배포에서 가져왔습니다. CPC 노드를 추가하면 전체 크롤링 시간이 향상되므로, 이와 같이 확인된 결과는 SharePoint 배포에 적용해야 합니다.
그림 4: CPC(콘텐츠 처리) 컴퓨터가 전체 크롤링에 미치는 영향
이에 따라 카탈로그에 고속 전체 크롤링이 필요한 경우 배포에서 CPC 역할을 사용하는 컴퓨터 수를 늘릴 수 있습니다.
Managed Metadata Service 응용 프로그램의 부하
테스트에 따르면 관리형 탐색을 사용하는 사이트가 포함된 게시 시나리오에는 관리되는 메타데이터 서비스 애플리케이션에 대한 메모리 또는 CPU 요구 사항이 크게 없습니다. 앞에서 설명한 것과 같은 배포의 경우 다른 SharePoint 서비스 애플리케이션을 실행하는 컴퓨터에서 관리되는 메타데이터 서비스 애플리케이션을 실행할 수 있습니다. 관리 탐색 기능은 사이트에 대한 첫 번째 요청을 받을 때 서비스 애플리케이션에 한 번 연결합니다. 후속 요청은 프런트 엔드 웹 서버가 캐시하는 값을 사용합니다. 따라서 프런트 엔드 웹 서버가 요청을 수행하는 동안 관리되는 메타데이터 서비스 애플리케이션에는 로드가 없습니다.
익명 검색 결과 캐시
익명 검색 결과 캐시는 쿼리의 결과, 쿼리에 대한 구체화 데이터 및 SharePoint 분산 캐시 서비스에서 반환된 추가 결과 테이블을 저장합니다. 각 캐시 항목은 결과의 정렬 순서, 요청된 구체화 및 동적 순서 재지정 규칙 같은 쿼리 매개 변수에 따라 달라집니다. 캐시는 검색 웹 파트의 쿼리 및 CSOM 클라이언트의 쿼리 등 웹 응용 프로그램이 처리하는 모든 쿼리에 영향을 줍니다. 자세한 내용은 SharePoint Server의 검색 아키텍처 개요 및 SharePoint Server의 인터넷 사이트에 대한 검색 크기 조정을 참조하세요.
이 캐시는 보안 문제 때문에 인증된 쿼리에는 사용되지 않습니다.
최상의 결과를 얻으려면 분산 캐시 서비스를 SharePoint Service 응용 프로그램이 실행되는 컴퓨터에서만 실행하도록 구성하는 것이 좋습니다. 분산 캐시 서비스는 프런트 엔드 웹 서버 역할에 속하는 컴퓨터에서 실행하면 안 됩니다.
기본적으로 익명 검색 결과 캐시는 15분 간격으로 항목을 새로 고칩니다. Microsoft PowerShell을 사용하여 캐시가 구성된 웹 애플리케이션에서 캐시 기간을 구성할 수 있습니다.
$webapp.Properties["SearchResultsCacheTTL"] = <number of seconds to keep in cache>
$webapp.Update()
검색 결과가 기본값보다 더 최신 상태를 유지하도록 하려면 이 값을 낮춥니다. 그러면 검색 서비스에서 처리해야 하는 쿼리 수가 늘어납니다.
과도한 트래픽을 수신하는 게시 페이지에는 항상 캐시를 사용하는 것이 좋습니다. 이러한 유형의 페이지에 대한 예로는 사이트 홈 페이지와 검색 웹 파트를 사용하는 범주 페이지를 들 수 있습니다. 카탈로그 항목 페이지는 캐시하지 않는 것이 좋습니다. 개별 카탈로그 항목 페이지에는 홈 페이지보다 훨씬 덜 빈번하게 액세스하므로 캐시에 항목을 저장하는 것은 그다지 도움이 되지 않을 수 있습니다.
부하 패턴이 동일한 테스트 환경에서 익명 검색 결과 캐시 기능을 해제했을 때 서버 응답 시간이 크게 증가하고 초당 페이지 보기 수의 처리량이 감소했습니다. 다음은 이 관계를 보여 주는 그래프입니다.
그림 5: 익명 검색 결과 캐시의 영향
기본적으로 콘텐츠 검색 웹 파트는 익명 검색 결과 캐시를 사용하도록 구성되어 있습니다. 카탈로그 항목 페이지에서 사용되는 카탈로그 항목 재사용 웹 파트는 일반적으로 이러한 페이지에 액세스하는 경우가 드물기 때문에 익명 검색 결과 캐시를 사용하도록 구성되지 않습니다.
개별 웹 파트에서 익명 검색 결과 캐시를 사용하거나 사용하지 않도록 캐싱 동작을 구성하려면 웹 파트의 속성에서 DataProviderJSON 하위 속성 "TryCache"의 값을 설정합니다. 값이 "true"인 경우 쿼리는 캐시를 사용합니다. 값이 "false"인 경우 쿼리는 익명 검색 쿼리에 캐시를 사용하지 않습니다.
출력 캐싱의 영향
출력 캐싱은 게시 시나리오에서 SharePoint Server 2013의 부하를 줄이는 효과적인 방법입니다. 이 문서에서 출력 캐시의 작동 방식에 대한 자세한 내용은 출력 캐싱 및 캐시 프로필을 참조하세요.
SharePoint 배포는 SharePoint 콘텐츠 데이터베이스 및 Search Service 응용 프로그램의 부하를 줄이는 데 출력 캐싱을 이용할 수 있습니다. 아래 몇 가지 예제 상황이 나와 있습니다.
일부 페이지에서 많은 트래픽을 수신 중인 경우
SharePoint 콘텐츠 데이터베이스에서 많은 트래픽을 수신 중인 경우
검색 쿼리를 처리하는 컴퓨터의 CPU 사용량이 많은 경우
사이트의 홈페이지 또는 최상위 범주 페이지 및 많은 양의 트래픽을 수신하는 특정 항목 페이지와 같이 사이트의 인기 있는 페이지에 출력 캐싱을 사용하는 것이 좋습니다.
중요
SharePoint Server 2013에서 출력 캐싱을 사용하도록 설정된 페이지에 콘텐츠 검색 웹 파트도 포함된 경우 알려진 문제가 있습니다. 배포에서 이 문제를 방지하려면 SharePoint Server 2013 업데이트: 2013년 3월 12일을 설치합니다.
다음 그래프에는 홈 페이지 및 사이트 트래픽의 60%를 수신하는 범주 페이지에 출력 캐싱을 사용할 때 테스트 환경에서 발생한 몇 가지 결과가 나와 있습니다.
그림 6: 홈 페이지 및 범주 페이지에 대한 출력 캐싱의 영향
참고
콘텐츠 검색 웹 파트에는 비동기 모드로 실행되는 설정이 있습니다. 출력 캐싱은 비동기 콘텐츠 검색 웹 파트에서 발생하는 부하에 적용되지 않습니다.
사용 현황 분석 처리
사용 현황 분석에 대한 정보를 사용할 준비가 되도록 SharePoint Server 2013은 사용 데이터베이스에 있는 정보를 처리합니다. Microsoft 토폴로지에서는 검색 관리 노드, 분산 캐시 서비스 및 기타 서비스 응용 프로그램이 포함된 노드에서 분산 처리가 발생합니다. 자세한 내용은 SharePoint Server의 분석 처리 개요를 참조하세요.
이전 테스트에서 사용한 교차 사이트 게시 사이트를 이용하여 몇 가지 분석 처리 시간을 측정했습니다. SharePoint Server 2013에서 사이트의 페이지에서 많은 양의 클릭 이벤트를 처리하는 데 걸리는 시간을 측정했습니다. 이러한 결과는 교차 사이트 게시 사이트에서 가져오지만, 전체 제작 게시 방법을 사용하는 사이트에도 적용됩니다.
사용 현황 분석 처리에 대한 테스트에서는 1주일 동안 매일 다음과 같은 모형 이벤트를 생성했습니다.
목록 항목 300만 개 및 사용자 400,000명에 걸쳐 클릭 이벤트 2,750만 개 분산.
일부 항목과 사용자에게는 이벤트가 많이 포함되지만 다른 항목 및 사용자에게는 많이 포함되지 않도록 Zipf 분포를 사용했습니다.
이에 따라 하루에 총 750만 개의 이벤트가 생성되어 사이트에 서로 다른 트래픽 패턴을 생성하는 다양한 사용자를 시뮬레이션했습니다.
1주일 간의 트래픽을 시뮬레이션하기 위해 분석 실행을 7번 트리거했습니다. 6일 동안 누적된 데이터에 대해 매일 Usage Analytics 작업을 실행했습니다. 그런 다음 우리는 일곱 번째 날이 걸린 시간을 측정했습니다. 7일은 전체 주의 항목이 처리되고 관계 그래프가 업데이트될 때 처리하는 데 가장 오래 걸리는 날입니다. 8일차의 런타임 및 디스크 사용량은 1일차와 유사합니다.
분석 처리 작업이 실행된 컴퓨터에 심각한 영향을 끼치지 않았으며 쿼리를 계속해서 처리했고 검색 기반 사이트의 콘텐츠를 최신 상태로 유지했습니다.
다음 표에 결과가 요약되어 있습니다.
| 테스트 일정 | 업데이트 관계 그래프 | 런타임(시) | 총 최대 디스크 사용량 | 사용 현황 분석 최대 디스크 사용량 |
|---|---|---|---|---|
| 1일 | 아니오 | 02:35 | 2.65GB | |
| 2일 | 아니오 | 02:43 | ||
| 3일 | 아니오 | 03:23 | ||
| 4일 | 아니오 | 04:39 | ||
| 5일 | 아니오 | 06:08 | ||
| 6일 | 아니오 | 07:35 | ||
| 7일 | 예 | 08:29 | 82.4GB | 4GB |
다음 그래프에는 며칠간의 실행 시간이 나와 있습니다.
그림 7: 일별 실행 시간
인증된 사용자가 있는 교차 사이트 게시
SharePoint 게시는 일반적으로 인트라넷 사이트에서 사용됩니다. SharePoint Server 2013을 사용하면 사이트 간 게시를 통해 이러한 사이트를 구동할 수도 있습니다. 다음 섹션에는 인증된 사용자를 이용하는 교차 사이트 게시 사이트를 계획할 때 고려해야 할 몇 가지 중요 항목이 나와 있습니다. 다음 섹션에 언급된 사항을 제외하고는 익명으로 액세스한 사이트에 적용되는 규칙이 인증된 사용자가 액세스하는 사이트에 계속 적용됩니다.
익명 검색 결과 캐시 부족
앞서 익명 검색 결과 캐시 섹션에서 설명한 것처럼 이 캐시는 SharePoint 사이트에 익명으로 액세스하는 사용자에게만 적용됩니다. 익명 검색 결과 캐시를 사용하는 익명 액세스 사이트에 비해 인증된 사용자가 액세스하는 사이트의 처리량 용량은 훨씬 낮아집니다. 일반적으로 인트라넷 사이트는 이전 섹션(최대 100페이지 보기/초)에 언급된 만큼 높은 부하를 거의 받지 못합니다. 그러나 이것은 고려해야 할 중요한 차이점입니다.
출력 캐시를 사용하면 이러한 시나리오에서 부족한 익명 검색 결과 캐시를 일정 수준 상쇄할 수 있습니다. 초당 여러 페이지 보기가 예상되는 교차 사이트 게시 사이트에서는 사이트 출력 캐시를 사용하도록 설정하는 것이 좋습니다.
중요
콘텐츠 검색 웹 파트에는 사용하도록 설정하면 비동기 모드에서 실행되도록 하는 설정이 있습니다. 출력 캐시는 비동기 콘텐츠 검색 웹 파트에서 발생하는 부하에 적용되지 않습니다.
대규모 검색 인덱스
SharePoint Server 2013을 배포하는 엔터프라이즈의 크기에 따라 SharePoint Server 2013에 대한 인트라넷 배포는 일반적으로 더 많은 수의 문서를 인덱싱합니다. 이는 곧 해당 문서를 인덱싱하는 데 필요한 검색 토폴로지가 이전 섹션에 설명된 토폴로지와 비교하여 다르다는 뜻입니다. SharePoint 배포 크기를 적절하게 조정하려면 SharePoint Server에서 검색 계획을 참조하세요.
전체 제작 게시
이 섹션에서는 SharePoint Server 2013을 사용하는 지침과 결과를 제공하지만 용량 계획에 영향을 주는 다양한 기능은 자세히 설명하지 않습니다. 이 영역에 대한 자세한 내용은 SharePoint Server의 웹 콘텐츠 관리를 참조하세요.
익명 사용자가 있는 전체 제작 게시
테스트 시 다음과 같은 특성을 지닌 웹 사이트에서 작업했습니다.
문서 페이지가 최대 20,000장인 웹 사이트가 한 사이트 모음에 있는 사이트 50개에 걸쳐 1,000페이지짜리 폴더 20개로 나뉘어 있습니다.
사이트에서 구조적 탐색을 사용합니다.
사이트에서 일반적으로 초당 최소 50~100개의 페이지 보기를 수신합니다.
다음과 같은 페이지가 혼합된 트래픽 패턴을 나타냅니다.
다양한 범위의 콘텐츠 데이터베이스 쿼리를 실행하는 단일 콘텐츠 쿼리 웹 파트가 포함된 페이지 20개(트래픽의 20%)
다양한 범위의 콘텐츠 데이터베이스 쿼리를 실행하는 여러 콘텐츠 쿼리 웹 파트가 포함된 페이지 30개(트래픽의 30%)
40K 텍스트와 이미지 2개가 포함된 문서 1,600개(트래픽의 50% 수신)
다음 다이어그램에 권장되는 서버 토폴로지가 나와 있습니다.
그림 8: 전체 제작 게시 테스트 토폴로지
SQL Server를 호스팅하는 컴퓨터 1대
SharePoint Service 응용 프로그램을 프런트 엔드 웹 서버로 호스팅하는 컴퓨터 1대
테스트 랩 결과
Microsoft는 실제 컴퓨터와 Visual Studio Team System 부하 테스트를 통해 당사 테스트 랩의 이전 다이어그램에 표시된 토폴로지를 사용했습니다.
다음 표에는 테스트한 컴퓨터에서 사용한 기술 사양이 나와 있습니다.
| 서버 구성 요소 | SharePoint Server |
|---|---|
| 프로세서 | Intel Xeon CPU @2.33GHz(프로세서 2개, 코어 총 8개, 스레드 총 8개) |
| RAM | 24GB |
| 운영 체제 | Windows Server 2008 R2 Enterprise, 64비트 |
| 네트워크 어댑터 수 | 2 |
| 네트워크 어댑터 속도 | 1Gbps |
| 인증 | 없음 - 익명 |
| 부하 분산 장치 유형 | Windows 소프트웨어 부하 분산 장치 |
| 소프트웨어 버전 | SharePoint Server 2013 |
| 서버 구성 요소 | 데이터베이스 서버 |
|---|---|
| 프로세서 | Intel Xeon CPU MP7130M @2.79GHz(프로세서 2개, 코어 총 8개, 스레드 총 16개) |
| RAM | 16GB |
| 운영 체제 | Windows Server 2008 R2 Enterprise, 64비트 |
| 디스크 배열 | Dell PERC 5/E 2개 |
| 네트워크 어댑터 수 | 1 |
| 네트워크 어댑터 속도 | 1GB 또는 1Gbps |
| 인증 | NTLM |
| 소프트웨어 버전 | Microsoft SQL Server 2008 R2 SP1 |
다음 표에는 10분간 실행한 결과가 나와 있습니다.
| 기능 테스트 | 안전 영역 | 위험 영역 |
|---|---|---|
| VSTS 사용자 수: | 5 | 15 |
| 서버 응답 시간 50번째 백분위 수: | 69ms | 112ms |
| 서버 응답 시간 95번째 백분위 수: | 92ms | 221ms |
| 초당 페이지 보기: | 57 | 93 |
| 평균 CPU(응용 프로그램 서버 및 프런트 엔드 웹 서버) | 55 | 97 |
| 평균 CPU(SQL Server) | 7 | 9 |
| 최대 메모리 사용량(응용 프로그램 서버 및 프런트 엔드 웹 서버) | 8.9GB | 8.9GB |
출력 캐싱의 영향
출력 캐싱은 게시 시나리오에서 SharePoint Server 2013의 부하를 줄이는 효과적인 방법입니다. 자세한 내용은 SharePoint Server의 캐싱 및 성능 계획을 참조하세요.
다음 표에는 출력 캐싱이 사용하도록 설정되고 캐시 적중률이 90%인 상태에서 10분간 실행한 결과가 나와 있습니다.
| 기능 테스트 | 안전 영역 | 위험 영역 |
|---|---|---|
| VSTS 사용자 수: | 5 | 15 |
| 서버 응답 시간 50번째 백분위 수: | 2ms | 2ms |
| 서버 응답 시간 95번째 백분위 수: | 74ms | 88ms |
| 초당 페이지 보기: | 190 | 418 |
| 평균 CPU(응용 프로그램 서버 및 프런트 엔드 웹 서버) | 58 | 85 |
| 평균 CPU(SQL Server) | 5 | 7 |
| 최대 메모리 사용량(응용 프로그램 서버 및 프런트 엔드 웹 서버) | 9.2GB | 9.4GB |
테스트 결과를 통해 출력 캐싱을 사용한 경우 SharePoint 게시 사이트의 처리량이 대폭 증가하고 서버 응답 시간이 감소한다는 사실을 알 수 있습니다. 출력 캐싱에서 처리된 요청의 경우 응답 시간이 거의 일정합니다.
다음 그래프에는 테스트 결과가 간략하게 나와 있습니다.
그림 9: 캐시 적중률이 90%인 출력 캐싱의 영향
관리 탐색의 영향
SharePoint Server 2013에서 게시 사이트는 관리 탐색을 사용할 수도 있습니다. 이 설정을 설정하는 방법에 대한 자세한 내용은 SharePoint Server의 관리 탐색 개요를 참조하세요.
관리 탐색을 사용하는 테스트 집합에서도 구조적 탐색 테스트에 사용한 것과 동일한 테스트 집합을 실행했습니다. 테스트에 따르면 사이트가 관리 탐색이나 구조적 탐색을 사용할 때 성능상 큰 차이가 나타나지 않았습니다.
| 기능 테스트 | 안전 영역 | 위험 영역 |
|---|---|---|
| VSTS 사용자 수: | 5 | 15 |
| 서버 응답 시간 50번째 백분위 수: | 70ms | 111ms |
| 서버 응답 시간 95번째 백분위 수: | 95ms | 215ms |
| 초당 페이지 보기: | 56 | 94 |
| 평균 CPU(응용 프로그램 서버 및 프런트 엔드 웹 서버) | 54 | 97 |
| 평균 CPU(SQL Server) | 7 | 9 |
| 최대 메모리 사용량(응용 프로그램 서버 및 프런트 엔드 웹 서버) | 8GB | 8GB |
다음 그래프에는 동일한 사이트에 대한 서로 다른 탐색 유형이 나와 있습니다.
그림 10: 관리 탐색과 구조적 탐색의 비교
컴퓨터 추가 시 끼치는 영향(수평 확장)
SharePoint 배포에서 더 많은 처리량이 필요한 경우 스케일 아웃(SharePoint Server 2013을 호스트하는 컴퓨터 수 늘리기)을 고려할 수 있습니다. 다음 그래프에는 팜에 컴퓨터를 추가할 때 처리량이 어떻게 증가하는지 나와 있습니다.
그림 11: 프런트 엔드 웹 서버 추가 시 처리량에 끼치는 영향
테스트에서 추가된 각 컴퓨터에 대해 SharePoint Server 2013을 실행하는 서버의 부하가 증가하여 서버 응답 시간이 거의 동일했습니다(녹색 영역의 경우 약 11밀리초, 빨간색 영역의 경우 약 250밀리초).
인증된 사용자가 있는 전체 제작 게시 사이트
SharePoint 게시 기능은 일반적으로 사이트에 액세스하는 사용자를 인증하는 인트라넷에서 사용됩니다. 이 섹션에는 인증된 사용자를 사용한 테스트와 그 영향이 나와 있습니다.
다음 표에는 인증된 사용자가 NTML과 클레임 기반 인증을 사용하여 액세스한 전체 제작 게시 사이트의 테스트 결과가 나와 있습니다. 이러한 테스트에서는 이전 섹션의 테스트와 동일한 하드웨어를 사용합니다.
| 기능 테스트 | 안전 영역 | 위험 영역 |
|---|---|---|
| VSTS 사용자 수: | 5 | 15 |
| 서버 응답 시간 50번째 백분위 수: | 76ms | 107ms |
| 서버 응답 시간 95번째 백분위 수: | 103ms | 194ms |
| 초당 페이지 보기: | 54 | 100 |
| 평균 CPU(응용 프로그램 서버 및 프런트 엔드 웹 서버) | 50 | 97 |
| 평균 CPU(SQL Server) | 6 | 9 |
| 최대 메모리 사용량(응용 프로그램 서버 및 프런트 엔드 웹 서버) | 9.5GB | 9.5GB |
이 수치를 통해 서버 응답 시간 및 처리량에 따른 익명 요청과 인증된 요청 간에 큰 차이가 없음을 알 수 있습니다.
다음 그래프에는 동일한 사이트에 대한 서로 다른 요청 유형이 나와 있습니다.
그림 12: 익명 요청과 인증된 요청의 비교
인증된 시나리오에 끼치는 출력 캐싱의 영향
서버에 인증된 요청은 콘텐츠에 액세스하는 계정이 콘텐츠를 볼 수 있는 권한이 있는지 확인하기 위해 콘텐츠 데이터베이스로 이동했다가 돌아와야 합니다. 즉 인증된 사이트의 출력 캐싱 성능 특성은 익명 사이트와 비교할 때 다릅니다.
다음 표에는 출력 캐싱이 사용하도록 설정되고 캐시 적중률이 90%인 상태에서 10분간 실행하여 얻은 결과가 나와 있습니다.
| 기능 테스트 | 안전 영역 | 위험 영역 |
|---|---|---|
| VSTS 사용자 수: | 6 | 18 |
| 서버 응답 시간 50번째 백분위 수: | 17ms | 29ms |
| 서버 응답 시간 95번째 백분위 수: | 87ms | 118ms |
| 초당 페이지 보기: | 114 | 236 |
| 평균 CPU(응용 프로그램 서버 및 프런트 엔드 웹 서버) | 50 | 97 |
| 평균 CPU(SQL Server) | 7 | 10 |
| 최대 메모리 사용량(응용 프로그램 서버 및 프런트 엔드 웹 서버) | 9.9GB | 10GB |
다음 그래프에는 이러한 결과가 간략하게 나와 있습니다.
그림 13: 인증된 출력 캐싱의 영향
참고 항목
개념
SharePoint Server의 웹 콘텐츠 관리 계획
SharePoint Server에서 웹 콘텐츠 관리 솔루션 구성