Microsoft SharePoint Server 2010 공유 환경: 실험 연구
적용 대상: SharePoint Server 2010
마지막으로 수정된 항목: 2016-11-30
이 문서에서는 Microsoft SharePoint Server 2010을 기반으로 내 사이트 및 공유 컴퓨팅 포털의 성능 및 용량 계획을 위한 지침을 제공합니다. 이 문서에서 설명하는 내용은 다음과 같습니다.
하드웨어, 팜 토폴로지 및 구성 등의 테스트 환경 사양
테스트 팜 데이터 집합
테스트 환경에 배포해야 하는 하드웨어, 토폴로지 및 구성을 결정하는 방법과, 적절한 용량 및 성능 특성을 위해 환경을 최적화하는 방법에 대한 권장 사항 및 테스트 데이터
요약
다음은 내 사이트 및 공유 컴퓨팅 포털에 대한 주요 테스트 결과입니다.
단일 응용 프로그램 서버 및 데이터베이스 서버에 대해 프런트 엔드 웹 서버를 최대 8대까지 늘려 환경을 수평 확장했습니다(8x1x1). 이 경우 처리량은 거의 선형으로 증가했으며, 프런트 엔드 웹 서버를 9대 이상 늘리는 경우에는 데이터베이스 서버의 CPU 사용률에 병목 현상이 발생하여 처리량이 더 증가하지 않았습니다.
콘텐츠 데이터베이스와 서비스 데이터베이스를 별도의 데이터베이스 서버로 분리하여 환경을 추가로 수평 확장했습니다(8x1x2).
8x1x2 토폴로지를 사용하는 경우 처리량이 최대 수준에 도달했습니다. 이 시점에서 프런트 엔드 웹 서버 사용률 및 응용 프로그램 서버 CPU 사용률에 병목 현상이 발생했습니다. 이 결과를 토대로 할 때 지정된 하드웨어, 데이터 집합 및 테스트 작업량에서 가능한 최대 RPS(초당 요청 수)는 8x1x2 토폴로지의 최대 영역 RPS(약 1,877개 RPS)로 나타났습니다.
테스트의 추세를 확인할 때, 프런트 엔드 웹 서버 및 응용 프로그램 서버의 병목 현상을 해결하면 정상적인 팜과 동일한 처리량을 얻을 수 있다고 판단되었습니다. 프런트 엔드 웹 서버의 병목 현상은 프런트 엔드 웹 서버를 더 추가하여 해결할 수 있고, 응용 프로그램 서버의 병목 현상은 두 컴퓨터가 응용 프로그램 서버 역할을 하도록 하면 해결할 수 있습니다. 그러나 이 테스트에서는 해당 해결 방법을 시도해 보지 않았습니다.
대기 시간은 처리량이나 하드웨어 변화의 영향을 받지 않습니다.
보안 조정을 설정하는 경우 한 프런트 엔드 웹 서버가 Outlook Social Connector 트래픽의 RPS를 8~10개까지 지원할 수 있습니다. 즉, 한 프런트 엔드 웹 서버가 하루 종일 Outlook Social Connector를 사용하여 약 28,000~36,000명의 직원을 지원할 수 있습니다. 따라서 10만 명의 직원에게 Outlook Social Connector를 제공하는 경우에는 Outlook Social Connector 트래픽을 지원하기 위한 프런트 엔드 웹 서버가 3대 필요합니다. 이러한 값은 회사의 공유 태그 사용 현황에 따라 달라질 수 있습니다. 이 테스트 작업의 데이터 집합에서 사용한 것보다 실제 회사에서 수행하는 공유 태그 작업이 더 적은 경우에는 프런트 엔드 웹 서버당 처리량이 8~10개 RPS 범위를 초과할 수 있습니다.
팜을 정상 상태에서 유지 관리하는 경우 증분 사용자 검색 크롤링은 팜 처리량에 거의 영향을 주지 않습니다.
환경 소개
이 문서에 나와 있는 테스트 방법 및 결과는 공유 컴퓨팅 포털의 용량을 계획하기 위한 지침을 제공합니다. 공유 컴퓨팅 포털은 회사의 각 직원이 사용자 프로필을 유지 관리하고, 회사의 전문가를 찾고, 뉴스 피드를 통해 다른 직원들과 연결하고, 문서 저장 및 공유를 위해 개인 사이트를 유지 관리할 수 있는 SharePoint Server 2010 배포입니다. 이러한 배포에서는 공유 컴퓨팅 기능에 의해 생성되는 트래픽 외에 개인 사이트에서 문서를 업로드, 공유, 확인 및 업데이트하는 사용자에 의해서도 많은 양의 공동 작업 트래픽이 생성됩니다. 이러한 결과를 참고하면 내 사이트 및 공유 기능 전용으로 별도의 포털을 디자인하는 데 도움이 됩니다.
각 시나리오의 요구 사항은 서로 다릅니다. 따라서 작업 환경에서 사용 중인 하드웨어에 대해 추가 테스트를 수행하여 이 지침을 보완해야 합니다.
이 문서의 내용을 확인하면 다음 작업을 수행하는 방법을 이해할 수 있습니다.
지원해야 하는 수평 확장에 필요한 하드웨어 예측. 예측해야 하는 항목으로는 사용자 수, 부하, 사용하도록 설정하는 기능 등이 있습니다.
최적의 안정성과 효율성을 위한 물리적 및 논리적 토폴로지 디자인. 고가용성 및 재해 복구에 대한 내용은 이 문서에 포함되어 있지 않습니다.
지속적인 사용자 검색 크롤링 및 프로필 동기화가 공유 컴퓨팅 포털 배포의 RPS에 주는 영향 고려
이 문서를 진행하기 전에 먼저 다음 문서를 확인해야 합니다.
일반적인 공동 작업 시나리오에 대한 용량 계획 지침을 확인하려면 엔터프라이즈 인트라넷 공동 작업 환경 기술 사례 연구(SharePoint Server 2010)를 참조하십시오.
참고
이 테스트 사례의 경우에는 공유 컴퓨팅 포털 배포에서 사용자 지정 코드가 실행되지 않는다고 가정했습니다. 실제 내 사이트 및 공유 컴퓨팅 포털에 설치되어 있을 수 있는 사용자 지정 코드 또는 타사 솔루션의 동작은 보장할 수 없습니다.
참고
이 테스트 사례에서는 NTLM 인증을 사용했습니다.
용어
아래 목록에서는 이 문서에 나오는 주요 용어의 정의를 제공합니다.
RPS: 초당 요청 수를 나타냅니다. 팜이나 서버에서 1초 동안 받은 요청의 수로, 일반적으로 서버와 팜의 부하를 측정하는 데 사용되는 측정 단위입니다.
요청과 페이지 로드는 서로 다른 개념입니다. 각 페이지에는 여러 가지 구성 요소가 포함되어 있으며 이러한 구성 요소 각각은 페이지를 로드할 때 하나 이상의 요청을 생성합니다. 따라서 한 번의 페이지 로드에서 여러 개의 요청이 생성됩니다. 일반적으로 리소스를 많이 사용하지 않는 인증 검사와 이벤트는 RPS를 측정할 때 포함되지 않습니다.
안전 영역 서버에서 다음과 같은 일련의 조건을 유지할 수 있는 상태입니다.
요청의 75% 이상에 대해 서버 쪽 대기 시간이 1초 미만입니다.
모든 서버의 CPU 사용률이 50% 미만입니다.
참고
이 테스트 환경에서는 활성 검색 크롤링이 실행되지 않았으므로 검색 크롤링 부하용으로 10%를 예약하기 위해 데이터베이스의 CPU 사용률이 40% 이하로 유지되었습니다. 여기서는 프로덕션에서 Microsoft SQL Server 리소스 관리자를 사용하여 검색 크롤링 부하를 CPU 사용률의 10%로 제한한다고 가정합니다.
- 오류율이 0.01% 미만입니다.
위험 영역(최대값): 서버에서 다음과 같은 일련의 조건을 유지할 수 있는 상태입니다.
HTTP 요청 제한 기능이 사용되지만 503(서버 작업 중) 오류는 반환되지 않습니다.
HTTP 요청의 오류율이 0.1% 미만입니다.
요청의 75% 이상에 대해 서버 쪽 대기 시간이 1초 미만입니다.
데이터베이스 서버 CPU 사용률이 80% 이하입니다. 따라서 검색 크롤링 부하를 위해 사용률의 10%를 예약할 수 있습니다. CPU 사용률은 SQL Server 리소스 관리자를 통해 제한됩니다.
AxBxC(그래프 표기법): 각각 팜의 프런트 엔드 웹 서버, 응용 프로그램 서버 및 데이터베이스 서버 수입니다. 예를 들어 이 값이 8x1x2인 환경에는 프런트 엔드 웹 서버가 8대, 응용 프로그램 서버가 1대, 그리고 데이터베이스 서버가 2대 있습니다.
VSTS 부하: VSTS(Visual Studio Team System)에서 가상 사용자를 시뮬레이트하기 위해 내부적으로 사용하는 스레드입니다. 이 테스트에서는 토폴로지에 대해 RPS를 계속 생성하기 위해 VSTS 부하를 늘렸습니다.
**MDF 및 LDF:**SQL Server 실제 파일입니다. 자세한 내용은 파일 및 파일 그룹 아키텍처를 참조하십시오.
개요
이 섹션에서는 테스트에 사용된 확장 방식, 이 테스트 환경과 유사한 사례 연구 환경 간의 관계, 그리고 테스트 방법에 대해 간략하게 설명합니다.
확장 방식
실제 환경의 컴퓨터를 특정 순서로 확장하는 것이 좋습니다. 테스트 환경에서 확장 시에 사용한 것과 같은 방식을 사용하면 작업량에 가장 적합한 구성을 찾을 수 있습니다. 테스트 환경에 사용된 방식은 다음과 같습니다.
먼저 프런트 엔드 웹 서버를 수평 확장했습니다. 데이터베이스 서버에서 프런트 엔드 웹 서버의 요청을 더 이상 받을 수 없을 때까지 테스트 대상 작업량에서 프런트 엔드 웹 서버를 최대한 수평 확장했습니다.
이 시점까지 콘텐츠 데이터베이스 및 서비스 데이터베이스(예: 프로필 데이터베이스 및 공유 데이터베이스)는 같은 데이터베이스 서버에 있었습니다. 데이터베이스 서버에서 병목 현상이 발견되어, 콘텐츠 데이터베이스를 다른 데이터베이스 서버로 이동함으로써 데이터베이스 서버를 수평 확장했습니다. 이 작업 후에는 프런트 엔드 웹 서버에 의해 생성된 데이터베이스 서버에 대한 부하가 프런트 엔드 웹 서버를 추가로 수평 확장할 수 있는 지점까지 감소했습니다.
테스트 환경에서는 이러한 확장을 초과하는 범위의 확장은 테스트하지 않았습니다. 그러나 추가 확장이 필요한 경우 다음으로 수행 가능한 논리적 단계는 두 컴퓨터가 응용 프로그램 역할을 공유하도록 하는 것입니다.
먼저 프런트 엔드 웹 서버, 응용 프로그램 서버 및 SQL Server 기반 컴퓨터가 각각 1대씩인 최소 팜 구성에서 테스트를 시작했으며, 테스트를 여러 차례 반복하면서 프런트 엔드 웹 서버 8대, 응용 프로그램 서버 1대, SQL Server 팜 2대에 해당하는 구성에서 테스트를 중지했습니다. 이 문서 뒷부분에 나오는 결과 및 분석 섹션에서는 각 반복 테스트 시의 안전 영역 및 최대 영역 성능 특성을 비교한 내용을 확인할 수 있습니다. 각 반복에 대해 안전 영역과 최대 영역을 확인한 방법에 대한 설명은 테스트 반복 결과 섹션에 나와 있습니다.
테스트 환경과 프로덕션 환경의 상관 관계
이 문서에서 설명하는 테스트 환경은 Microsoft에서 사용하는 프로덕션 환경과 유사한 확장 모델입니다. 두 환경 간에는 많은 차이가 있지만 둘 다 내 사이트 및 공유 컴퓨팅 환경이며 확인되는 패턴도 유사하므로 함께 비교 확인하면 유용할 수 있습니다.
테스트 환경에는 프로덕션 환경의 데이터 집합과 매우 비슷한 데이터 집합이 있습니다. 또한 테스트에 사용된 작업량은 프로덕션 환경에서 확인되는 작업량과 대체로 비슷하지만, 몇 가지 중요한 차이점이 있습니다. 그 중 가장 큰 차이점은, 테스트 환경의 경우 프로덕션 환경에 비해 작업을 수행하는 고유 사용자 및 작업 수행 대상 사용자 프로필의 수가 더 적다는 것입니다. 또한 테스트는 더 짧은 시간 동안 진행되었습니다. 이러한 모든 요인이 응용 프로그램 서버에서 유지 관리되는 사용자 프로필 캐시에 대해 발생하는 캐시 적중 횟수에 영향을 줍니다.
User Profile Service는 응용 프로그램 서버에서 최근에 사용된 사용자 프로필을 캐시합니다. 이 캐시의 기본 크기는 256MB(사용자 프로필 약 50만 개)입니다. 테스트에 사용된 사용자 프로필 수는 1,500개로 제한되었으며 테스트 기간은 캐시 재활용 시간보다 짧았기 때문에 캐시 적중이 일반적으로 발생했습니다. 따라서 이 문서에서 제공하는 처리량 수치는 높은 편입니다. 실제 환경에서는 캐시 누락을 고려하여 예상 처리량 수치를 더 낮게 잡아야 합니다.
Microsoft에서 사용하는 프로덕션 내 사이트 및 공유 컴퓨팅 포털과 관련된 자세한 사례 연구는 공유 환경 기술 사례 연구(SharePoint Server 2010)를 참조하십시오.
테스트 방법 및 참고 사항
이 문서에서는 테스트 환경의 결과를 제공합니다. 작업 환경이 테스트 환경이었으므로 해당 작업 부하에 대해 특정 성능 측면을 표시하도록 특정 요인을 제어할 수 있었습니다. 또한 테스트 오버헤드를 간소화하기 위해 프로덕션 환경의 특정 요소는 테스트 환경에서 제외되었습니다. 실제 프로덕션 환경에서는 이러한 요소를 제외하지 않는 것이 좋습니다.
테스트 실행 간의 결과를 쉽게 비교할 수 있도록 각 실행 간에 변수를 한 번에 하나씩만 수정했습니다.
테스트에서는 중복성이 필요하지 않았기 때문에, 이 테스트 환경에서 사용된 데이터베이스 서버는 클러스터에 포함되어 있지 않았습니다.
테스트 중에는 검색 크롤링이 실행되지 않았지만 프로덕션 환경에서는 검색 크롤링이 실행될 수 있습니다. 이를 고려하기 위해 안전 영역 및 위험(최대) 영역 정의에서 SQL Server CPU 사용률을 낮춰 검색 크롤링이 테스트와 동시에 실행되는 경우 사용했을 리소스를 계산에 포함했습니다.
사양
이 섹션에서는 테스트 환경의 하드웨어, 소프트웨어, 토폴로지 및 구성에 대한 자세한 정보를 제공합니다.
하드웨어
아래 표에는 이 테스트에 사용된 컴퓨터의 하드웨어 사양이 나와 있습니다. 여러 차례의 테스트 반복 중에 서버 팜에 추가된 프런트 엔드 웹 서버도 이러한 사양을 따릅니다.
| 프런트 엔드 웹 서버 | 응용 프로그램 서버 | 데이터베이스 서버 | |
|---|---|---|---|
프로세서 |
2개 프로세서(4개 코어, 2.33GHz) |
2개 프로세서(4개 코어, 2.33GHz) |
4개 프로세서(4개 코어, 3.10GHz) |
RAM |
8GB |
8GB |
32GB |
네트워크 어댑터 수 |
2 |
2 |
1 |
네트워크 어댑터 속도 |
1기가비트 |
1기가비트 |
1기가비트 |
부하 분산 유형 |
F5 - 하드웨어 부하 분산 |
해당 없음 |
해당 없음 |
ULS 로깅 수준 |
보통 |
보통 |
해당 없음 |
소프트웨어
아래 표에는 이 테스트에 사용된 컴퓨터의 소프트웨어 사양이 나와 있습니다. 여러 차례의 테스트 반복 중에 서버 팜에 추가된 프런트 엔드 웹 서버도 이러한 사양을 따릅니다.
| 프런트 엔드 웹 서버 | 응용 프로그램 서버 | 데이터베이스 서버 | |
|---|---|---|---|
운영 체제 |
Windows Server 2008 R2 x64 |
Windows Server 2008 R2 x64 |
Windows Server 2008 x64 |
소프트웨어 버전 |
Microsoft SharePoint 4763.1000(RTM), Office Web Applications 4763.1000(RTM) |
Microsoft SharePoint 4763.1000(RTM), WAC 4763.1000(RTM) |
SQL Server 2008 R2 CTP3 |
부하 분산 유형 |
F5 - 하드웨어 부하 분산 |
해당 없음 |
해당 없음 |
ULS 로깅 수준 |
보통 |
보통 |
해당 없음 |
바이러스 백신 설정 |
사용 안 함 |
사용 안 함 |
사용 안 함 |
실행되는 서비스 |
SharePoint Foundation 받는 전자 메일 SharePoint Foundation 웹 응용 프로그램 SharePoint Foundation 워크플로 타이머 서비스 |
중앙 관리 Excel Calculation Services Managed Metadata Web Service SharePoint Foundation 받는 전자 메일 SharePoint Foundation 웹 응용 프로그램 SharePoint Foundation 워크플로 타이머 서비스 PowerPoint Service User Profile Service 사용자 프로필 동기화 서비스 Word Viewing Service |
토폴로지
다음 다이어그램에서는 테스트 환경의 토폴로지를 보여 줍니다.
.gif "이 환경의 팜 토폴로지 다이어그램")
데이터 집합 및 디스크 구조
테스트 팜에 채워진 콘텐츠는 다음과 같습니다.
내 사이트 콘텐츠166.5GB(콘텐츠 데이터베이스 10개에 균일하게 분산됨)
프로필 데이터베이스 콘텐츠 27.7GB
공유 데이터베이스 콘텐츠 3.7GB(공유 태그, 메모 및 등급 GUID)
관리되는 메타데이터 데이터베이스 콘텐츠 0.14GB(공유 태그 및 해당하는 GUID의 텍스트)
아래 표에는 데이터 집합에 대한 자세한 설명이 나와 있습니다.
사용자 프로필 수 |
최대 150,000 |
사용자당 평균 구성원 자격 수 |
74 |
사용자당 평균 부하 직원 수 |
6 |
사용자당 평균 동료 수 |
28 |
총 프로필 속성 수 |
101 |
다중값 속성 수 |
21 |
대상 그룹 수 |
130 |
내 사이트 수 |
최대 10,000 |
블로그 사이트 수 |
최대 600 |
작업 피드의 총 이벤트 수 |
798,000* |
공유 태그 및 등급 수 |
5,040,000** |
* del.icio.us의 공유 태그 연구에 따르면, 활성 사용자 한 명이 매월 작성하는 태그 수는 평균 4.2개입니다. 이러한 맥락에서 URL에 메타데이터(키워드 태그, 등급, 메모)를 지정하는 작업을 고려하면, 활성 사용자 한 명이 매일 작성하는 태그 수는 4.2개 태그/30일 = 0.14개입니다. 공유 포털 사용자의 1/3이 태그를 사용한다고 가정할 때, 150,000/3 x 0.14개의 태깅 이벤트가 매일 수행됩니다. 작업 피드 테이블에는 14일 동안의 작업이 보관되므로, 작업 피드 테이블에 포함된 태깅 이벤트의 총 수는 150,000/3 x 0.14 x 14입니다. 태깅 이벤트 외에도, 활성 사용자가 프로필 속성 업데이트나 상태 업데이트와 같은 이벤트를 매일 하나씩 추가로 생성한다고 가정하면 150,000/3 x 1 x 14개의 이벤트가 작업 피드 테이블에 추가되는 것입니다. 따라서 작업 피드 테이블의 총 이벤트 수는 150,000/3 x 1.14 x 14 = 798,000개입니다. 이러한 이벤트 중에 98,000개는 보안 조정을 트리거할 수 있는 태깅 작업이고 나머지 이벤트는 상태 업데이트와 프로필 속성 변경 내용에 임의로 분산됩니다.
** 총 사용자 중 1/3이 활성 사용자이고 각 사용자가 매월 4.2개의 태그를 작성한다고 가정합니다. 여기서 태그란 키워드 태그, 메모, 등급 등을 의미할 수 있습니다. 팜이 2년 동안 사용된다고 가정할 때 총 태그 수는 150,000/3 x 4.2 x 12 x 2 = 5.04MB가 됩니다.
아래 표에는 디스크 구조에 대한 자세한 설명이 나와 있습니다.
| 데이터베이스 | ContentDB 1, 2, 3, 4 | ContentDB 5, 6 | ContentDB 7, 8 | ContentDB 9, 10 | 프로필 | 공유 | 메타데이터 |
|---|---|---|---|---|---|---|---|
데이터베이스 크기 |
61.4GB |
39GB |
32.3GB |
33.7GB |
27.7GB |
3.7GB |
0.14GB |
RAID 구성 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
MDF용 스핀들 수 |
1 |
1 |
1 |
1 |
6 |
1 |
1 |
LDF용 스핀들 수 |
모든 데이터베이스에서 물리적 스핀들 1개 공유 |
테스트 혼합
중요 참고 사항:
테스트에서는 일반적인 공유 컴퓨팅 포털에서 사용량이 많은 시간의 사용 현황만을 모델링합니다. 즉, 주간/야간 주기로 나타나는 사용자 생성 트래픽의 주기적인 변경은 고려하지 않았습니다. 프로필 동기화, 사용자 검색 크롤링 등 리소스를 많이 사용해야 하는 타이머 작업의 경우 동일한 테스트 작업량을 사용하여 독립적으로 테스트하여 해당 영향을 확인했습니다.
테스트에서는 뉴스 피드, 공유 태깅, 사용자 프로필 읽기 등의 공유 작업을 중점적으로 수행했습니다. 일반적인 공동 작업 트래픽도 약간 발생했지만 중요하게 고려하지는 않았습니다. 이러한 결과를 참고하면 내 사이트 및 공유 기능 전용으로 별도의 포털을 디자인하는 데 도움이 됩니다.
테스트 혼합에는 검색 콘텐츠 크롤링의 트래픽이 포함되지 않습니다. 그러나 검색 크롤링에 CPU 사용률 중 10%를 사용할 수 있도록 안전 영역 정의를 표준 50%가 아닌 40% SQL Server CPU 사용률로 수정하여 이 트래픽을 테스트에 적용했습니다. 마찬가지로, 최대 RPS에 대한 조건으로는 80% SQL Server CPU가 사용되었습니다.
아래 표에 나와 있는 테스트 혼합 외에, Outlook Social Connector 트래픽용으로 각 프런트 엔드 웹 서버에 대해 RPS 8개를 추가했습니다. 보안 조정은 설정한 상태로 테스트를 진행했습니다. 동료의 작업을 가져올 때 단일 프런트 엔드 웹 서버에서 Outlook Social Connector 트래픽이 약 8개 RPS에 도달하자 보안 토큰 서비스에서 부하가 높아졌습니다. 이러한 공식은 환경 테스트에서 사용된 데이터 집합, 테스트 작업량 및 하드웨어에만 해당하며, 실제 동작은 이와 완전히 다를 수 있습니다. 보안 토큰 서비스에 대한 추가 부하를 방지하기 위해, 각 테스트 반복에서 프런트 엔드 웹 서버 수에 비례하여 Outlook Social Connector 트래픽을 추가하기로 결정했습니다. 즉, 1x1x1 구성의 경우에는 Outlook Social Connector 트래픽이 8개 RPS가 되고 2x1x1 구성에서는 Outlook Social Connector 트래픽이 16개 RPS가 되는 식입니다.
아래 표에 전체 테스트 혼합이 나와 있습니다.
| 테스트 | 읽기/쓰기 | 혼합 비율 |
|---|---|---|
동료 추가 |
쓰기 |
2.11 |
URL 등급 작성, 메모 쓰기 또는 URL에 태그 지정 |
쓰기 |
3.22 |
작업 문서 나열 |
읽기/쓰기 |
2.36 |
게시된 링크를 가져와 PublishedLinksService.asmx에 대한 클라이언트 호출 모델링 |
읽기 |
6.92 |
목록에서 RSS 피드 가져오기 |
읽기 |
3.72 |
내 사이트의 문서 라이브러리 및 목록에 있는 모든 항목 보기 |
읽기 |
1.07 |
블로그 게시물 보기 |
읽기 |
0.04 |
다양한 내 사이트 페이지(내 콘텐츠, 동료, 뉴스 피드, 내 프로필, 다른 사람의 프로필, 조직 브라우저, 구성원 자격, 태그, 메모) 보기 |
읽기 |
3.87 |
공유 OneNote 파일 동기화 |
읽기 |
10.0 |
내 프로필 페이지 또는 상태 메시지 편집/사진 업데이트 |
쓰기 |
2.31 |
Office Web Apps: 파일 열기 및 스크롤(PowerPoint, Word, Excel) |
읽기 |
0.13 |
Outlook과 목록 동기화 |
읽기 |
48.16 |
문서 업로드 |
쓰기 |
0.09 |
콘텐츠 데이터베이스에서 페이지, 문서 라이브러리 및 폴더 로드 |
읽기 |
15.93 |
문서 공동 작성 |
읽기/쓰기 |
0.17 |
아래 표에는 프런트 엔드 웹 서버당 8개 RPS를 생성하는 추가 Outlook Social Connector 시나리오 테스트 혼합에 대한 설명이 나와 있습니다.
동료 자동 동기화 |
읽기 |
4% |
동료의 뉴스 피드 자동 동기화 |
읽기 |
96% |
결과 및 분석
모든 테스트 반복 비교
이 테스트에서는 앞서 언급한 것처럼 먼저 프런트 엔드 웹 서버, 응용 프로그램 서버 및 SQL Server 기반 컴퓨터가 각각 1대씩인 최소 팜 구성에서 테스트를 시작했으며, 테스트를 여러 차례 반복하면서 최종적으로 프런트 엔드 웹 서버 8대, 응용 프로그램 서버 1대, SQL Server 컴퓨터 2대가 포함된 팜에서 테스트를 중지했습니다. 이러한 각 반복에서는 단계 부하 테스트를 수행하여 안전 영역과 최대 영역을 확인했습니다. 아래 표에는 각 테스트 반복에 대해 이러한 안전 영역 및 최대 영역 성능 특성을 비교한 내용이 나와 있습니다.
아래 표와 차트에는 비교 및 분석 내용이 간략하게 나와 있습니다.
안전 영역 결과
아래 표에는 각 토폴로지에서 나타난 안전 영역의 성능 특성이 간략하게 나와 있습니다.
| 토폴로지 | 1x1x1 | 2x1x1 | 3x1x1 | 5x1x1 | 8x1x1 | 8x1x2 |
|---|---|---|---|---|---|---|
안전 영역 RPS |
137.25 |
278.08 |
440.72 |
683.07 |
793.67 |
873.4 |
안전 영역 75번째 백분위수 대기 시간 |
0.12 |
0.16 |
0.14 |
0.16 |
0.31 |
0.32 |
안전 영역 프런트 엔드 웹 서버 CPU |
47.84 |
46.88 |
48.68 |
46.13 |
31.79 |
36.90 |
안전 영역 응용 프로그램 서버 CPU |
9.45 |
18.88 |
26.91 |
35.58 |
48.73 |
47.20 |
안전 영역 SQL Server CPU |
5.45 |
10.61 |
16.46 |
24.73 |
30.03 |
32.40(콘텐츠 DB - 17.9, 서비스 DB - 14.5) |
아래 차트에서는 서로 다른 토폴로지에서 RPS에 따른 CPU 사용률의 변화를 보여 줍니다(안전 영역 결과).
.gif "GreenZone의 RPS와 함께 CPU 사용률을 보여 주는 차트")
위의 차트를 통해 다음 사실을 확인할 수 있습니다.
토폴로지에 컴퓨터를 추가하면 처리량이 RPS에 비례하여 증가했습니다.
5x1x1 토폴로지까지는 토폴로지의 CPU가 안전 영역 경계까지 도달하는 요인이 프런트 엔드 웹 서버 CPU임을 명확하게 확인할 수 있습니다. 8x1x1의 경우에는 프런트 엔드 웹 서버가 안전 영역 경계에 도달하기 전에 응용 프로그램 서버 CPU가 먼저 안전 영역 경계에 도달했습니다.
전체 테스트 과정에서 SQL Server CPU는 매우 정상적인 범위로 유지되었습니다.
최대 영역 결과
아래 표에는 각 토폴로지에서 나타난 최대 영역 결과가 간략하게 나와 있습니다.
| 1x1x1 | 2x1x1 | 3x1x1 | 5x1x1 | 8x1x1 | 8x1x2 | |
|---|---|---|---|---|---|---|
최대 영역 RPS |
203.28 |
450.75 |
615.00 |
971.13 |
1655 |
1877 |
최대 영역 대기 시간 |
0.22 |
0.23 |
0.22 |
0.22 |
0.31 |
0.32 |
최대 영역 프런트 엔드 웹 서버 CPU |
75.13 |
78.17 |
70.00 |
67.02 |
67 |
71.6 |
최대 영역 응용 프로그램 서버 CPU |
12.97 |
27.07 |
28.40 |
48.28 |
67.1 |
73.4 |
최대 영역 SQL Server CPU |
7.64 |
16.06 |
21.00 |
38.38 |
79.5 |
74.9 (콘텐츠 DB - 45.9, 서비스 DB - 29) |
아래 차트에서는 서로 다른 토폴로지에서 RPS에 따른 CPU 사용률의 변화를 보여 줍니다(최대 영역 결과).
.gif "MaxZone의 RPS와 함께 CPU 사용률을 보여 주는 차트")
위의 차트를 통해 다음 사실을 확인할 수 있습니다.
토폴로지에 컴퓨터를 추가하면 처리량이 RPS에 비례하여 증가했습니다.
5x1x1 토폴로지까지는 프런트 엔드 웹 서버 CPU가 병목 현상의 원인임을 명확하게 확인할 수 있습니다. 8x1x1의 경우에는 SQL Server CPU에서 병목 현상이 발생합니다.
초기에는 응용 프로그램 서버 CPU 사용률이 SQL Server CPU 사용률보다 높았습니다. 그러나 SQL Server CPU 사용률 증가 속도가 응용 프로그램 서버 CPU 사용률 증가 속도보다 높은 것으로 나타납니다. 높은 처리량 수준에서는 SQL Server CPU 사용률이 응용 프로그램 서버 CPU 사용률보다 높아져 병목 현상의 원인이 됩니다.
안전 영역과 최대 영역 비교
아래 차트에는 서로 다른 토폴로지에 대해 안전 영역 및 최대 영역의 처리량과 대기 시간을 비교한 내용이 나와 있습니다.
.gif "각 토폴로지의 RPS를 보여 주는 차트")
.gif "각 토폴로지의 대기 시간을 보여 주는 차트")
위의 차트를 통해 다음 사실을 확인할 수 있습니다.
대기 시간은 처리량이나 토폴로지에 따라 크게 바뀌지 않았습니다. 이 테스트에서는 대기 시간이 모두 적절한 수준인 0.5초 미만이었습니다.
처리량은 거의 선형으로 증가합니다.
디스크 I/O
아래 표와 차트에는 서로 다른 토폴로지의 각 데이터베이스에서 확인된 디스크 I/O가 나와 있습니다. 디스크 I/O에서는 병목 현상이 발생하지 않았으며, 추세를 확인한 결과 표에 나와 있는 토폴로지 이후에서는 데이터를 기록할 필요가 없다고 판단되어 기록하지 않았습니다.
| 1x1x1 최대 영역 | 2x1x1 최대 영역 | 3x1x1 최대 영역 | 5x1x1 최대 영역 | |
|---|---|---|---|---|
초당 읽기(콘텐츠 DB) |
21.33 |
20.80 |
24.24 |
22.42 |
초당 읽기(프로필 DB) |
14.97 |
17.20 |
19.82 |
13.50 |
초당 읽기(공유 DB) |
1.81 |
1.83 |
2.10 |
2.01 |
초당 쓰기(콘텐츠 DB) |
50.12 |
76.24 |
80.02 |
99.16 |
초당 쓰기(프로필 DB) |
9.01 |
24.31 |
23.35 |
38.29 |
초당 쓰기(공유 DB) |
4.12 |
9.47 |
10.63 |
19.45 |
.gif "각 토폴로지의 IOPS를 보여 주는 차트")
사용자 검색 크롤링의 영향
이 테스트에서는 구성 및 최종 사용자 대기 시간을 통해 사용자 검색 크롤링이 처리량에 주는 영향을 측정하고자 했습니다. 여기서는 8x1x1 구성에서 제공된 결과를 기준으로 사용하여 증분 사용자 검색 크롤링을 시작했습니다. 증분 크롤링에서는 53분 동안 49,375개의 항목을 인덱싱했습니다.
8x1x1 구성에서 사용자 검색 증분 크롤링을 수행한 경우와 수행하지 않은 경우에 나타난 성능 특성을 비교한 내용이 아래 표에 나와 있습니다.
| 기준 8x1x1 안전 영역 결과 | 8x1x1에서 사용자 검색 크롤링을 수행한 경우(안전 영역 결과) | |
|---|---|---|
처리량(RPS) |
1024.00 |
1026.00 |
프런트 엔드 웹 서버 CPU(%) |
39.84 |
41.6 |
응용 프로그램 서버 CPU(%) |
41.40 |
43.1 |
콘텐츠/서비스 SQL Server CPU(%) |
36.63 |
39.5 |
크롤링 서버 CPU(%) |
0.52 |
34.6 |
검색용 SQL Server CPU(%) |
3.62 |
14.8 |
이 표의 설명을 통해 다음 사실을 확인할 수 있습니다.
RPS는 거의 동일하게 유지되었습니다. 8x1x1 안전 영역에서는 리소스 병목 현상이 발생하지 않았으므로 RPS는 영향을 받지 않습니다.
프런트 엔드 웹 서버 및 콘텐츠/서비스 SQL Server CPU 사용률은 약간만 증가했습니다.
크롤링 서버 및 검색용 SQL Server CPU는 각각 0.5%에서 34.6%로, 그리고 3.6%에서 14.8%로 증가했습니다.
분석
응용 프로그램 서버 확장
어떤 구성에서도 응용 프로그램 서버에서는 병목 현상이 발생하지 않았습니다. 또한 단일 구성의 서로 다른 VSTS 부하에서 응용 프로그램 서버 CPU 사용률을 확인하면, 어느 정도까지는 증가하다가 그 이후로는 거의 동일하게 유지됨을 확인할 수 있습니다. 아래 표에 나와 있는 8x1x1 구성의 CPU 사용률이 좋은 예입니다.
| VSTS 부하 | 416 | 616 | 816 | 1016 | 1216 | 1416 | 1616 |
|---|---|---|---|---|---|---|---|
응용 프로그램 서버 CPU 사용률(%) |
37.6 |
49.4 |
57.9 |
61.9 |
67.1 |
65.3 |
63.10 |
공유 포털의 경우에는 대부분의 작업을 수행할 때 SharePoint Server User Profile Services를 사용해야 하기 때문에 이러한 결과는 어느 정도 예측할 수 있습니다. 즉, 대부분의 작업에서는 User Profile Service 작성 시 구축되는 프로필 데이터베이스에서 사용자의 프로필을 가져와야 합니다.
빈번한 SQL Server 왕복을 방지하기 위해 User Profile Service용 응용 프로그램 서버에서는 사용자 프로필 캐시를 보관합니다. 초기에 테스트 환경을 가동할 때는 이 캐시가 비어 있으며 응용 프로그램 서버가 SQL Server에서 지속적으로 사용자 프로필을 가져와서 프런트 엔드 웹 서버에서 들어오는 요청에 응답합니다. 이렇게 가져온 프로필이 캐시되면 응용 프로그램 서버는 SQL Server 왕복을 수행하지 않고도 프런트 엔드 웹 서버로부터의 모든 요청에 응답할 수 있습니다. 즉, 캐시에서 사용자 프로필을 찾아서 요청을 처리합니다.
테스트에서 사용된 사용자 프로필 수는 제한되었으므로 응용 프로그램 서버에서 모든 사용자 프로필을 캐시합니다. 그 이후에는 사용률이 계속 증가했습니다. 모든 프로필이 캐시된 후에는 캐시 조회 작업이 지속적으로 진행되었습니다. 따라서 응용 프로그램 서버 CPU 사용률이 지속적으로 감소했습니다.
Outlook Social Connector 트래픽 및 보안 조정
Outlook Social Connector는 Office 2010에 포함된 추가 기능으로, Outlook에서 SharePoint 동료의 작업을 보여 줍니다. 이 추가 기능은 2007 Microsoft Office 시스템 및 Microsoft Office 2003용 무료 다운로드로도 제공됩니다.
Outlook Social Connector는 1시간마다 SharePoint Server를 한 번씩 확인하여 특정 사용자의 동료 목록에 포함된 사용자의 작업을 가져오며, 1시간마다 해당 작업을 캐시합니다. 후속 동료 작업 확인 시 Outlook Social Connector는 마지막으로 SharePoint Server를 확인한 시간 이후 새로 추가된 작업만 확인하기 때문에, 해당 패턴을 예측하기가 쉽습니다. 사용자가 10만 명인 Outlook Social Connector 및 SharePoint Server 배포에서 모든 사용자가 하루 종일 Outlook Social Connector를 사용한다고 가정하면 시간당 요청이 10만 개(27.77개 RPS) 생성됩니다.
동료의 작업을 표시하는 경우 정보가 노출될 가능성이 있습니다. 예를 들어 동료가 태그를 지정하는 URL이 다른 사용자는 액세스할 수 없는 기밀 내용일 수 있습니다. 이 경우에는 Outlook Social Connector를 확인하여 해당 기밀 내용의 존재 여부를 파악할 수 있습니다. 이와 같은 정보 노출을 방지하기 위해 SharePoint Server에서는 모든 작업을 필터링하여 사용자가 작업 피드에서 액세스할 수 있는 URL만 표시합니다. 이러한 필터링을 보안 조정이라고 합니다. 보안 조정은 기본적으로 설정되지만, SharePoint Server 관리자가 해제할 수 있습니다.
모든 작업에 보안 조정이 필요한 것은 아닙니다. SharePoint Server 2010에서 지원하는 16가지 작업 유형 중 4가지(태깅, 메모 게시판 메모, 등급, DL(메일 그룹) 구성원 자격 변경)의 경우에만 보안 조정이 필요합니다. 또한 Outlook Social Connector에서는 마지막 동기화 이후에 수행한 작업 변경 사항만 확인하므로, 사용자당 보안 조정이 필요한 작업의 수는 상대적으로 적습니다.
Outlook Social Connector에서 보안 조정이 필요한 요청을 보낼 때마다, Search Service를 사용할 수 있도록 응용 프로그램 서버에 대해 인증된 WCF(Windows Communication Foundation) 호출을 수행해야 합니다. 이 호출을 수행하는 데 필요한 인증 토큰을 가져오기 위해 먼저 보안 토큰 서비스에 대한 WCF 호출을 수행합니다.
테스트를 수행한 결과, Outlook Social Connector RPS가 프런트 엔드 서버당 8개 RPS를 초과하는 경우 보안 토큰 서비스에 대한 부하가 높아졌습니다. 보안 토큰 서비스에 대한 부하는 사용자 동료의 작업에 대해 수행되는 총 공유 태깅의 양과 총 사용자 수에 의해 영향을 받으므로, 모든 사용자에 대해 부하가 높아지는 것은 아닙니다. 테스트에서 작성된 데이터 집합과 테스트에 사용된 사용자 수의 경우에는 보안 조정이 필요한 작업 수가 많아 부하가 높아질 수 있습니다. 따라서 사용 가능한 프런트 엔드 웹 서버의 수에 비례하여 Outlook Social Connector 트래픽을 늘렸습니다. 즉, 1x1x1 구성에서는 8개 RPS, 2x1x1 구성에서는 16개 RPS에 해당하는 Outlook Social Connector 트래픽을 생성했습니다.
즉, 테스트에 사용한 데이터 집합, 테스트 혼합 및 하드웨어의 경우에는 8 x 60 x 60(시간당 요청 28,800개)을 지원할 수 있습니다. Outlook Social Connectork의 작동 방식을 고려할 때 이는 보안 조정이 설정된 단일 프런트 엔드 웹 서버에서 Outlook Social Connector를 사용하는 직원을 28,800명 지원할 수 있음을 의미합니다. 마찬가지로, 보안 조정이 설정된 프런트 엔드 웹 서버를 3대 사용하는 경우에는 Outlook Social Connector를 사용하는 직원을 28,800 x 3 = 86,400명 지원할 수 있습니다.
이러한 수치를 통해 Outlook Social Connector 트래픽을 지원하는 데 필요한 하드웨어를 예측할 수 있습니다. 그러나 앞에서도 언급한 것처럼, 이 테스트의 결과는 테스트에 사용된 데이터 집합, 테스트 혼합 및 하드웨어에 적용되는 것입니다. 또한 Windows PowerShell 2.0을 사용하거나, Outlook Social Connector가 SharePoint Server와 동기화되는 빈도를 변경하여 보안 조정을 해제할 수도 있습니다. 이 두 옵션은 모두 하드웨어 요구 사항에 큰 영향을 줍니다.
반복 테스트 결과
아래에는 테스트 결과가 이 문서 앞부분의 개요에서 설명한 확장 방식을 기반으로 한 순서대로 나와 있습니다.
1x1x1 토폴로지
이 섹션에서는 웹 서버, 응용 프로그램 서버, 데이터베이스 서버가 각각 1대인 토폴로지에서 확인된 테스트 결과를 설명합니다.
결과 요약
이 문서 앞부분에 나와 있는 테스트 혼합 외에, 이 팜에는 사용자에 의한 피드 이벤트를 요청하는 Outlook Social Connector에서 생성하는 트래픽(8개 RPS)이 있습니다.
프런트 엔드 웹 서버, 응용 프로그램 서버 및 SQL Server 컴퓨터가 각각 1대인 팜에서는 프런트 엔드 웹 서버에서 병목 현상이 발생함을 명확하게 확인할 수 있었습니다. 아래 표에 나와 있는 것처럼, 이 문서 앞부분에서 설명한 트랜잭션 혼합을 사용하여 팜의 RPS를 238개로 높였을 때 프런트 엔드 웹 서버의 CPU 사용률이 약 90%까지 높아졌습니다.
이 구성의 안전 영역 RPS는 137.25였으며 75% 대기 시간은 0.12초, 프런트 엔드 웹 서버 CPU 사용률은 대략 47.8%였습니다. 이 수치를 통해 이 팜은 약 137.25개의 RPS를 정상적으로 전달할 수 있음을 알 수 있습니다. 이 팜에서 전달 가능한 최대 영역 RPS는 203.2였으며 대기 시간은 0.22초, 프런트 엔드 웹 서버 CPU 사용률은 약 85%였습니다.
프런트 엔드 웹 서버에서 병목 현상이 발생했으므로, 다음 테스트 반복을 위해 팜에 다른 프런트 엔드 웹 서버를 추가했습니다.
성능 카운터 및 그래프
아래 표에는 1x1x1 팜을 테스트하는 동안 여러 VSTS 부하 단계에서 캡처한 다양한 성능 카운터가 나와 있습니다.
| VSTS 부하 | 52 | 77 | 102 | 127 | 152 | 177 |
|---|---|---|---|---|---|---|
RPS |
99.8 |
147 |
188 |
218 |
238 |
243 |
프런트 엔드 웹 서버 CPU |
33.9 |
50 |
71.8 |
81.1 |
90.8 |
89 |
응용 프로그램 서버 CPU |
7.92 |
11.7 |
13.5 |
14.1 |
13.9 |
13.3 |
SQL Server CPU |
4.7 |
6.48 |
7.99 |
8.21 |
8.41 |
8.88 |
75번째 백분위수(초) |
0.13 |
0.16 |
0.17 |
0.25 |
0.3 |
0.45 |
75번째 백분위수(초) |
0.29 |
0.47 |
0.41 |
0.55 |
0.55 |
0.77 |
.gif "1x1x1 토폴로지의 RPS 및 대기 시간을 보여 주는 차트")
.gif "1x1x1 토폴로지의 RPS 및 CPU 사용률을 보여 주는 차트")
2x1x1 토폴로지
이 섹션에서는 웹 서버가 2대이고 응용 프로그램 서버와 데이터베이스 서버가 각각 1대인 토폴로지에서 확인된 테스트 결과를 설명합니다.
결과 요약
이 문서 앞부분에 나와 있는 테스트 혼합 외에, 이 팜에는 사용자에 의한 피드 이벤트를 요청하는 Outlook Social Connector에서 생성하는 트래픽(16개 RPS)이 있습니다.
프런트 엔드 웹 서버가 2대이고 응용 프로그램 서버 및 SQL Server 컴퓨터가 각각 1대인 팜에서는 프런트 엔드 웹 서버에서 병목 현상이 발생함을 명확하게 확인할 수 있었습니다. 아래 표의 데이터와 같이, 이 문서 앞부분에서 설명한 트랜잭션 혼합을 사용하여 팜의 RPS를 520개로 높였을 때 프런트 엔드 웹 서버의 CPU 사용률이 약 89%까지 높아졌습니다.
이 구성의 안전 영역 RPS는 278이었으며 75% 대기 시간은 0.16초, 프런트 엔드 웹 서버 CPU 사용률은 대략 47%였습니다. 이 수치를 통해, 테스트에 사용된 테스트 혼합 및 하드웨어의 경우 이 팜은 약 278개의 RPS를 정상적으로 전달할 수 있음을 알 수 있습니다. 이 팜에서 전달 가능한 최대 영역 RPS는 450이었으며 대기 시간은 0.23초, 프런트 엔드 웹 서버 CPU 사용률은 약 78%였습니다.
이 테스트 반복에서는 프런트 엔드 웹 서버 CPU에서 병목 현상이 발생했으므로, 다음 반복에서는 다른 프런트 엔드 웹 서버를 추가하여 병목 현상을 해결했습니다.
성능 카운터 및 그래프
아래 표 및 차트에는 2x1x1 팜을 테스트하는 동안 여러 VSTS 부하 단계에서 캡처한 다양한 성능 카운터가 나와 있습니다.
| VSTS 부하 | 104 | 154 | 204 | 254 | 304 | 354 |
|---|---|---|---|---|---|---|
RPS |
190 |
278 |
390 |
455 |
500 |
520 |
프런트 엔드 웹 서버 CPU |
36 |
50.9 |
71.9 |
86.9 |
87.1 |
89.5 |
응용 프로그램 서버 CPU |
16 |
24.9 |
28.3 |
26.5 |
26.5 |
24.9 |
SQL Server CPU |
8.06 |
10.6 |
14.2 |
16.4 |
17.9 |
18.9 |
75번째 백분위수(초) |
0.16 |
0.22 |
0.22 |
0.33 |
0.42 |
0.53 |
75번째 백분위수(초) |
0.42 |
0.64 |
0.51 |
0.69 |
0.73 |
0.89 |
.gif "2x1x1 토폴로지의 RPS 및 대기 시간을 보여 주는 차트")
.gif "2x1x1 토폴로지의 RPS 및 CPU 사용률을 보여 주는 차트")
3x1x1 토폴로지
이 섹션에서는 웹 서버가 3대이고 응용 프로그램 서버와 데이터베이스 서버가 각각 1대인 토폴로지에서 확인된 테스트 결과를 설명합니다.
결과 요약
이 문서 앞부분에 나와 있는 테스트 혼합 외에, 이 팜에는 사용자에 의한 피드 이벤트를 요청하는 Outlook Social Connector에서 생성하는 트래픽(24개 RPS)이 있습니다.
프런트 엔드 웹 서버가 3대이고 응용 프로그램 서버 및 SQL Server 컴퓨터가 각각 1대인 팜에서는 프런트 엔드 웹 서버에서 병목 현상이 발생함을 명확하게 확인할 수 있었습니다. 아래 표의 데이터와 같이, 이 문서 앞부분에서 설명한 트랜잭션 혼합을 사용하여 팜의 RPS를 629개로 높였을 때 프런트 엔드 웹 서버의 CPU 사용률이 약 76%까지 높아졌습니다.
이 구성의 안전 영역 RPS는 440이었으며 75% 대기 시간은 0.14초, 프런트 엔드 웹 서버 CPU 사용률은 대략 48%였습니다. 이 수치를 통해, 테스트에 사용된 테스트 혼합 및 하드웨어의 경우 이 팜은 약 440개의 RPS를 전달할 수 있음을 알 수 있습니다. 이 팜에서 전달 가능한 최대 영역 RPS는 615였으며 대기 시간은 0.22초, 프런트 엔드 웹 서버 CPU 사용률은 약 70%였습니다.
이 테스트 반복에서는 프런트 엔드 웹 서버 CPU에서 병목 현상이 발생했으므로 프런트 엔드 웹 서버를 더 추가하기로 결정했습니다. 이전에 프런트 엔드 웹 서버 1대를 추가했을 때 테스트 반복 간에 확인되었던 처리량의 차이를 고려하여, 이번에는 프런트 엔드 웹 서버 2대를 추가하기로 했습니다. 이를 통해 응용 프로그램 서버 또는 SQL Server 컴퓨터에서 병목 현상을 확인하고자 했습니다.
성능 카운터 및 그래프
아래 표 및 차트에는 3x1x1 팜을 테스트하는 동안 여러 VSTS 부하 단계에서 캡처한 다양한 성능 카운터가 나와 있습니다.
| VSTS 부하 | 156 | 231 | 306 | 381 | 456 | 531 |
|---|---|---|---|---|---|---|
RPS |
264 |
393 |
532 |
624 |
634 |
629 |
프런트 엔드 웹 서버 CPU |
30.5 |
46.3 |
62.55 |
72.95 |
75.4 |
76 |
응용 프로그램 서버 CPU |
22.7 |
35.6 |
34.2 |
32.5 |
32.5 |
29.4 |
SQL Server CPU |
10.4 |
14.8 |
20.8 |
22.5 |
22.8 |
22.4 |
75번째 백분위수(초) |
0.17 |
0.26 |
0.27 |
0.28 |
0.31 |
0.40 |
75번째 백분위수(초) |
0.63 |
1.08 |
0.76 |
0.68 |
0.88 |
0.98 |
.gif "3x1x1 토폴로지의 RPS 및 대기 시간을 보여 주는 차트")
.gif "3x1x1 토폴로지의 RPS 및 CPU 사용률을 보여 주는 차트")
5x1x1 토폴로지
이 섹션에서는 웹 서버가 5대이고 응용 프로그램 서버와 데이터베이스 서버가 각각 1대인 토폴로지에서 확인된 테스트 결과를 설명합니다.
결과 요약
이 문서 앞부분에 나와 있는 테스트 혼합 외에, 이 팜에는 사용자에 의한 피드 이벤트를 요청하는 Outlook Social Connector에서 생성하는 트래픽(40개 RPS)이 있습니다.
프런트 엔드 웹 서버가 5대이고 응용 프로그램 서버 및 SQL Server 컴퓨터가 각각 1대인 팜에서는 SQL Server CPU 및 응용 프로그램 서버 CPU 사용률이 크게 증가했지만 계속해서 프런트 엔드 웹 서버 CPU에 병목 현상이 발생했습니다. 아래 표의 데이터와 같이, 이 문서 앞부분에서 설명한 트랜잭션 혼합을 사용하여 팜의 RPS를 1315개로 높였을 때 프런트 엔드 웹 서버의 CPU 사용률이 약 88%까지 높아졌습니다.
이 구성의 안전 영역 RPS는 683이었으며 75% 대기 시간은 0.16초, 프런트 엔드 웹 서버 CPU 사용률은 대략 46%였습니다. 이 수치를 통해, 테스트에 사용된 테스트 혼합 및 하드웨어의 경우 이 팜은 약 683개의 RPS를 정상적으로 전달할 수 있음을 알 수 있습니다. 이 팜에서 전달 가능한 최대 영역 RPS는 971이었으며 대기 시간은 0.22초, 프런트 엔드 웹 서버 CPU 사용률은 약 68%였습니다.
이 추세를 고려하여 프런트 엔드 웹 서버 3대를 추가하고 8x1x1 구성에서 테스트를 수행하기로 했습니다. 이 구성에서는 응용 프로그램 서버 또는 SQL Server에서 병목 현상이 발생할 것으로 기대했습니다.
성능 카운터 및 그래프
아래 표에는 5x1x1 팜을 테스트하는 동안 여러 사용자 부하 단계에서 캡처한 다양한 성능 카운터가 나와 있습니다. 여기서는 VSTS 부하 또는 구성 변경이 대기 시간에 큰 영향을 주지 않았으므로 기록을 중지했습니다.
| VSTS 부하 | 260 | 385 | 510 | 635 | 760 | 885 |
|---|---|---|---|---|---|---|
RPS |
359 |
560 |
901 |
1188 |
1281 |
1315 |
프런트 엔드 웹 서버 CPU |
20.5 |
34 |
56.2 |
77.5 |
86.1 |
88 |
응용 프로그램 서버 CPU |
40.2 |
50.6 |
66.9 |
71.3 |
66.3 |
58.7 |
SQL Server CPU |
13.9 |
20.3 |
34.9 |
53.6 |
58.4 |
64 |
.gif "5x1x1 토폴로지의 RPS 및 CPU 사용률을 보여 주는 차트")
8x1x1 토폴로지
이 섹션에서는 웹 서버가 8대이고 응용 프로그램 서버와 데이터베이스 서버가 각각 1대인 토폴로지에서 확인된 테스트 결과를 설명합니다.
결과 요약
이 문서 앞부분에 나와 있는 테스트 혼합 외에, 이 팜에는 사용자에 의한 피드 이벤트를 요청하는 Outlook Social Connector에서 생성하는 트래픽(64개 RPS)이 있습니다.
프런트 엔드 웹 서버가 8대이고 응용 프로그램 서버 및 SQL Server 컴퓨터가 각각 1대인 팜에서는 SQL Server CPU에 병목 현상이 발생했습니다. 아래 표의 데이터와 같이, 이 문서 앞부분에서 설명한 트랜잭션 혼합을 사용하여 팜의 RPS를 1664개로 높였을 때 SQL Server의 CPU 사용률이 약 80%까지 높아졌습니다.
이 구성의 안전 영역 RPS는 793이었으며 75% 대기 시간은 0.31초, SQL Server CPU 사용률은 대략 30%였습니다. 그러나 응용 프로그램 서버 CPU 사용률은 약 48%였습니다. 이 수치를 통해, 테스트에 사용된 테스트 혼합 및 하드웨어의 경우 이 팜은 약 793개의 RPS를 정상적으로 전달할 수 있음을 알 수 있습니다. 이 팜에서 전달 가능한 최대 영역 RPS는 1655였으며 대기 시간은 0.31초, SQL Server CPU 사용률은 약 80%였습니다.
이 반복에서는 SQL Server CPU에 병목 현상이 발생했으므로, 다음 반복에서는 콘텐츠 데이터베이스와 서비스 데이터베이스를 두 SQL Server 인스턴스에 분리하여 병목 현상을 해결했습니다.
성능 카운터 및 그래프
아래 표 및 차트에는 8x1x1 팜을 테스트하는 동안 여러 VSTS 부하 단계에서 캡처한 다양한 성능 카운터가 나와 있습니다.
| VSTS 부하 | 416 | 616 | 816 | 1016 | 1216 | 1416 | 1616 |
|---|---|---|---|---|---|---|---|
RPS |
664 |
1101 |
1359 |
1530 |
1655 |
1664 |
1617.00 |
프런트 엔드 웹 서버 CPU |
26.7 |
44.4 |
54.7 |
61.5 |
67 |
65.9 |
65.10 |
응용 프로그램 서버 CPU |
37.6 |
49.4 |
57.9 |
61.9 |
67.1 |
65.3 |
63.10 |
SQL Server CPU |
23.2 |
42 |
57.9 |
69.5 |
79.5 |
80.8 |
77.30 |
.gif "8x1x1 토폴로지의 RPS 및 CPU 사용률을 보여 주는 차트")
8x1x2 토폴로지
이 섹션에서는 웹 서버가 8대이고 응용 프로그램 서버가 1대, 데이터베이스 서버가 2대인 토폴로지에서 확인된 테스트 결과를 설명합니다.
결과 요약
이 문서 앞부분에 나와 있는 테스트 혼합 외에, 이 팜에는 사용자에 의한 피드 이벤트를 요청하는 Outlook Social Connector에서 생성하는 트래픽(64개 RPS)이 있습니다.
프런트 엔드 웹 서버가 8대이고 응용 프로그램 서버가 1대, SQL Server 컴퓨터가 2대인 팜에서는 구성을 최대로 높일 수 있었습니다. 그 결과 프런트 엔드 웹 서버와 응용 프로그램 서버에서 모두 병목 현상이 발생한 반면, SQL Server 사용률의 합 역시 70% 후반이었습니다. 이 팜의 최대 부하 시 RPS는 1817이었습니다.
이 구성에서 마지막 반복 테스트를 수행했습니다. 토폴로지를 더 확장해야 하는 경우에는 두 컴퓨터가 응용 프로그램 서버 역할을 하도록 지정하면 됩니다. 이렇게 하면 프런트 엔드 웹 서버를 훨씬 많이 사용할 수 있어 각 프런트 엔드 웹 서버의 부하를 줄일 수 있습니다.
성능 카운터 및 그래프
아래 표 및 차트에는 8x1x2 팜을 테스트하는 동안 여러 VSTS 부하 단계에서 캡처한 다양한 성능 카운터가 나와 있습니다.
| VSTS 부하 | 466 | 666 | 866 | 1066 | 1266 | 1416 |
|---|---|---|---|---|---|---|
RPS |
466.00 |
873.40 |
1431.00 |
1703.00 |
1766.00 |
1817.00 |
프런트 엔드 웹 서버 CPU |
19.90 |
36.90 |
57.60 |
68.00 |
71.40 |
71.60 |
응용 프로그램 서버 CPU |
29.80 |
47.20 |
63.50 |
71.40 |
71.90 |
73.40 |
총 SQL Server CPU |
19.61 |
32.40 |
55.20 |
63.60 |
68.50 |
74.90 |
콘텐츠 SQL Server CPU |
9.93 |
17.90 |
31.90 |
40.10 |
42.30 |
45.90 |
서비스 SQL Server CPU |
9.68 |
14.50 |
23.30 |
23.50 |
26.20 |
29.00 |
.gif "8x1x2 토폴로지의 RPS 및 CPU 사용률을 보여 주는 차트")
저자 정보
Gaurav Doshi는 Microsoft의 프로그램 관리자입니다.
Wenyu Cai는 Microsoft의 테스트 소프트웨어 엔지니어입니다.