부서 포털 환경 실험 연구(SharePoint Server 2010)
적용 대상: SharePoint Server 2010
마지막으로 수정된 항목: 2016-11-30
이 문서에서는 Microsoft SharePoint Server 2010을 기반으로 하는 부서별 포털의 성능 및 용량 계획에 대한 지침을 제공합니다. 여기에는 다음 항목이 포함됩니다.
하드웨어, 팜 토폴로지 및 구성 등의 테스트 환경 사양
테스트 팜 데이터 집합
유사한 환경을 배포하는 데 필요한 하드웨어, 토폴로지 및 구성을 결정하는 방법과, 적절한 용량 및 성능 특성을 위해 환경을 최적화하는 방법에 대한 권장 사항 및 테스트 데이터
이 문서의 내용
환경 소개
용어
개요
사양
결과 및 분석
환경 소개
이 문서에서는 테스트 방법과 결과를 개괄적으로 설명함으로써 일반적인 부서 포털의 용량 계획을 위한 지침을 제공합니다. 부서 포털은 팀에서 주로 공동 작업을 수행하고 일부 콘텐츠를 게시하는 SharePoint Server 2010 배포입니다. 이 문서에서는 "부서"를 직원 수가 1천 명에서 1만 명 사이인 기업 내의 조직으로 가정합니다.
각 시나리오의 요구 사항은 서로 다릅니다. 따라서 작업 환경에서 사용 중인 하드웨어에 대해 추가 테스트를 수행하여 이 지침을 보완해야 합니다. 계획된 디자인 및 작업량이 이 문서에서 설명하는 환경과 비슷한 경우에는 이 문서의 내용을 참조하여 환경 수평/수직 확장에 대한 결론을 내릴 수 있습니다.
이 문서의 내용을 확인하면 다음 작업을 수행하는 방법을 이해할 수 있습니다.
사용자 수, 부하 및 사용하도록 설정하는 기능과 같이 지원해야 하는 확장을 지원하는 데 필요한 하드웨어 예측
최적의 안정성과 효율성을 위한 물리적 및 논리적 토폴로지 디자인. 고가용성/재해 복구에 대한 내용은 이 문서에 포함되어 있지 않습니다.
부서 포털 배포에 대한 지속적 RPS 검색 크롤링의 영향 이해
이 문서에서 설명하는 SharePoint Server 2010 환경은 대규모 회사의 프로덕션 환경을 모방하는 테스트 환경입니다. 프로덕션 환경에 대한 자세한 내용은 부서 공동 작업 환경 기술 사례 연구(SharePoint Server 2010)을 참조하십시오.
이 문서를 읽기 전에 SharePoint Server 2010 용량 관리의 기반이 되는 주요 개념을 이해하고 있어야 합니다. 다음 설명서는 용량 관리를 위한 권장 접근 방식에 대해 알아보는 데 유용한 내용을 제공하며 이 문서의 정보를 효과적으로 활용할 수 있도록 배경 정보를 제공합니다
또한 다음 문서의 내용도 확인하십시오.
용어
이 문서에는 몇 가지 전문 용어가 나옵니다. 다음은 주요 용어와 각각에 대한 정의입니다.
RPS 초당 요청 수를 나타냅니다. 팜이나 서버에서 1초 동안 받은 요청의 수로, 일반적으로 서버와 팜의 부하를 측정하는 데 사용되는 측정 단위입니다.
요청과 페이지 로드는 서로 다른 개념입니다. 각 페이지에는 여러 가지 구성 요소가 포함되어 있으며 이러한 구성 요소 각각은 페이지를 로드할 때 하나 이상의 요청을 생성합니다. 따라서 한 번의 페이지 로드에서 여러 개의 요청이 생성됩니다. 일반적으로 리소스를 많이 사용하지 않는 인증 검사와 이벤트는 RPS를 측정할 때 포함되지 않습니다.
안전 영역 서버에서 다음과 같은 일련의 조건을 유지할 수 있는 상태입니다.
요청의 75% 이상에 대해 서버 쪽 대기 시간이 0.5초 미만입니다.
모든 서버의 CPU 사용률이 50% 미만입니다.
참고
이 테스트 환경에서는 활성 검색 크롤링이 실행되지 않았으므로 검색 크롤링 부하용으로 10%를 예약하기 위해 데이터베이스의 CPU 사용률이 40% 이하로 유지되었습니다. 여기서는 프로덕션에서 Microsoft SQL Server 리소스 관리자를 사용하여 검색 크롤링 부하를 10% CPU로 제한한다고 가정합니다.
- 오류율이 0.01% 미만입니다.
위험 영역(최대값): 서버에서 다음과 같은 일련의 조건을 유지할 수 있는 상태입니다.
HTTP 요청 제한 기능이 사용되지만 503 오류(서버 작업 중)는 반환되지 않습니다.
오류 비율이 0.1% 미만입니다.
요청의 75% 이상에 대해 서버 쪽 대기 시간이 1초 미만입니다.
데이터베이스 서버 CPU 사용률이 75% 이하입니다. 따라서 검색 크롤링 부하를 위해 10%를 예약할 수 있습니다. 사용률은 SQL Server 리소스 관리자를 통해 제한됩니다.
모든 웹 서버의 CPU 사용률이 75% 이하입니다.
AxBxC(그래프 표기법): 각각 팜의 웹 서버, 응용 프로그램 서버 및 데이터베이스 서버 수입니다. 예를 들어 이 값이 2x1x1인 환경에는 웹 서버가 2대, 응용 프로그램 서버와 데이터베이스 서버가 각각 1대씩 있습니다.
**MDF 및 LDF:**SQL Server 실제 파일입니다. 자세한 내용은 파일 및 파일 그룹 아키텍처를 참조하십시오.
개요
이 섹션에서는 테스트에 사용된 가정 및 방법을 간략하게 설명합니다.
가정
이 테스트에서는 다음 사항을 가정했습니다.
이 테스트 범위에서는 디스크 I/O를 제한 요인으로 고려하지 않았으며, 스핀들을 수에 제한 없이 사용 가능하다고 가정했습니다.
테스트에서는 일반적인 부서 포털에서 피크 시간 사용률만 모델링했으며, 주간-야간 주기에서 발견되는 주기적 트래픽 변화는 고려하지 않았습니다. 또한 일반적으로 야간에 실행되도록 예약해야 하는 타이머 작업은 테스트 혼합에 포함되지 않았습니다.
이 테스트의 경우에는 부서 포털 배포에서 사용자 지정 코드가 실행되지 않는다고 가정했습니다. 실제 부서 포털에서 설치 및 실행되는 사용자 지정 코드/타사 솔루션의 동작은 보장할 수 없습니다.
이러한 테스트에서는 모든 서비스 데이터베이스 및 콘텐츠 데이터베이스가 동일한 Microsoft SQL Server 인스턴스에 배치되었습니다. 사용 현황 데이터베이스는 별도의 SQL Server 인스턴스에서 유지 관리되었습니다.
이 테스트에서는 BLOB 캐시가 사용되었습니다.
이 테스트에서는 검색 크롤링 트래픽을 고려하지 않았습니다. 그러나 지속적인 검색 크롤링의 영향을 적용하기 위해 정상 팜의 정의를 수정했습니다. 즉, 검색 크롤링에 사용되는 10%를 적용하여 SQL Server에 대해 안전 영역 정의를 40%로 설정했으며, 마찬가지로 최대 RPS의 조건으로 80% SQL Server CPU를 사용했습니다.
테스트 방법
Visual Studio Team System for Test 2008 SP2를 사용하여 성능 테스트를 수행했습니다. 테스트 목표는 각 토폴로지에 대해 안전 영역, 최대 영역 및 다양한 중간 시스템 상태의 성능 특성을 찾는 것이었습니다. "최대 영역"과 "안전 영역"의 자세한 정의는 용어 섹션에 나와 있지만(성능 카운터에서 특정 값으로 측정함), 일반적으로 성능 값이 "최대 영역" 중단점에 인접한 팜 구성은 부하가 높은 것으로 간주되고, 성능 값이 "안전 영역" 중단점 이내인 팜 구성은 정상 상태인 것으로 간주됩니다.
이 테스트에서는 가장 일반적인 팜 구성을 사용하여 작업을 시작한 다음 일련의 테스트를 실행하는 방식을 취했습니다. 첫 번째 테스트는 시스템 부하를 점진적으로 높여 성능 특성을 모니터링하는 것입니다. 이 테스트에서 다양한 사용자 부하에서의 처리량과 대기 시간 값을 파생시켰으며, 시스템 병목 현상을 파악했습니다. 이 데이터를 얻은 후에는 팜에서 안전 영역 특성과 최대 영역 특성을 나타내는 사용자 부하를 각각 파악했습니다. 그런 다음 이렇게 미리 파악된 일정한 사용자 부하에서 보다 긴 시간 동안 별도의 테스트를 실행했습니다. 이러한 테스트를 통해 팜 구성이 보다 긴 기간에 대해 개별 사용자 부하에서 일정한 안전 영역 및 최대 영역 성능을 제공할 수 있도록 했습니다.
그런 후에 다음 구성에 대해 테스트를 수행하는 동안 시스템을 수평 확장하여 이전 실행에서 파악된 병목 현상을 예측했습니다. 이러한 방식으로 SQL Server CPU 병목 현상이 나타날 때까지 테스트를 반복했습니다.
앞서 언급한 것처럼 웹 서버/응용 프로그램 서버/데이터베이스 서버가 각각 1대씩 포함된 최소 팜 구성에서 테스트를 시작했습니다. 테스트를 여러 번 반복하면서 최종적으로는 웹 서버가 3대이고 응용 프로그램 서버 및 데이터베이스 서버가 각각 1대인 팜 구성을 사용했는데, 이 구성에서 데이터베이스 서버 CPU가 최대값을 기록했습니다. 테스트에 대한 간단한 요약과 차트를 작성하기 전에 각 테스트를 반복하여 해당 구성에 대한 안전 영역과 최대 영역을 설정했습니다. 그런 다음 테스트를 또다시 반복하여 안전 영역과 최대 영역을 비교했으며, 이를 통해 권장 사항을 도출했습니다.
SharePoint 관리 도구 키트 팀에서는 "LTK(부하 테스트 도구 키트)"라는 도구를 작성했으며, 이 도구는 고객이 다운로드하여 사용할 수 있도록 공개되어 있습니다.
사양
이 섹션에서는 테스트 환경의 하드웨어, 소프트웨어, 토폴로지 및 구성에 대한 자세한 정보를 제공합니다.
하드웨어
아래 표에는 이 테스트에 사용된 컴퓨터의 하드웨어 사양이 나와 있습니다. 여러 차례의 테스트 반복 중에 서버 팜에 추가된 모든 웹 서버는 동일한 사양을 따릅니다.
| 웹 서버 | 응용 프로그램 서버 | 데이터베이스 서버 | |
|---|---|---|---|
프로세서 |
2개(4개 코어, 2.33GHz) |
2개(4개 코어, 2.33GHz) |
4개(4개 코어, 3.19GHz) |
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 |
소프트웨어 버전 |
SharePoint Server 2010 및 Office Web Applications 시험판 버전 |
SharePoint Server 2010 및 Office Web Applications 시험판 버전 |
SQL Server 2008 R2 CTP3 |
인증 |
Windows NTLM |
Windows NTLM |
Windows NTLM |
부하 분산 유형 |
F5 - 하드웨어 부하 분산 |
해당 없음 |
해당 없음 |
ULS 로깅 수준 |
보통 |
보통 |
해당 없음 |
바이러스 백신 설정 |
사용 안 함 |
사용 안 함 |
사용 안 함 |
로컬로 실행되는 서비스 |
Microsoft SharePoint Foundation 받는 전자 메일 Microsoft SharePoint Foundation 웹 응용 프로그램 Microsoft SharePoint Foundation 워크플로 타이머 서비스 검색 쿼리 및 사이트 설정 서비스 SharePoint Server Search |
중앙 관리 Excel Services Managed Metadata Web Service Microsoft SharePoint Foundation 받는 전자 메일 Microsoft SharePoint Foundation 웹 응용 프로그램 Microsoft SharePoint Foundation 워크플로 타이머 서비스 PowerPoint Services 검색 쿼리 및 사이트 설정 서비스 SharePoint Server Search Visio Graphics Services Word Viewing Service |
해당 없음 |
위의 표에는 테스트 환경에서 구축된 서비스가 나와 있습니다. User Profile Service 및 Web Analytics와 같은 기타 서비스는 구축되지 않습니다.
토폴로지 및 구성
다음 다이어그램에서는 테스트에 사용된 토폴로지를 보여 줍니다. 테스트를 반복하면서 웹 서버 수를 1대, 2대, 3대로 변경한 것을 제외하면 토폴로지는 동일하게 유지되었습니다.
.gif "이 환경의 팜 토폴로지 다이어그램")
데이터 집합 및 디스크 구조
테스트 팜에는 약 1.62TB의 콘텐츠를 채웠으며, 이러한 콘텐츠는 크기가 서로 다른 5개의 콘텐츠 데이터베이스로 분산되었습니다. 아래 표에서는 이 분산에 대해 설명합니다.
| 콘텐츠 데이터베이스 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
콘텐츠 데이터베이스 크기 |
36GB |
135GB |
175GB |
1.2TB |
75GB |
사이트 수 |
44 |
74 |
9 |
9 |
222 |
웹 수 |
1544 |
2308 |
2242 |
2041 |
1178 |
RAID 구성 |
0 |
0 |
0 |
0 |
0 |
MDF용 스핀들 수 |
1 |
1 |
5 |
3 |
1 |
LDF용 스핀들 수 |
1 |
1 |
1 |
1 |
1 |
트랜잭션 혼합
다음은 트랜잭션 혼합에 대한 중요한 참고 사항입니다.
부서 포털에서는 내 사이트가 구축되지 않습니다. 또한 내 사이트를 지원하는 User Profile Service도 팜에서 실행되지 않습니다. 트랜잭션 혼합에는 Outlook Social Connector와 관련된 내 사이트 페이지/웹 서비스 적중 또는 트래픽이 포함되지 않습니다.
테스트 혼합에는 문서 공동 작업으로 인해 생성된 트래픽이 포함되지 않습니다.
테스트 혼합에는 검색 크롤링의 트래픽이 포함되지 않습니다. 그러나 검색 크롤링에 CPU 사용률 중 10%를 사용할 수 있도록 안전 영역 정의를 표준 50%가 아닌 40% SQL Server CPU 사용률로 수정하여 검색 크롤링의 트래픽을 테스트에 적용했습니다. 마찬가지로, 최대 RPS에 대한 조건으로는 80% SQL Server CPU가 사용되었습니다.
아래 표에서는 전체 트랜잭션 혼합에 대해 설명합니다. 총 비율은 100%입니다.
| 기능 또는 서비스 | 작업 | 읽기/쓰기 | 혼합 비율 |
|---|---|---|---|
ECM |
정적 파일 가져오기 |
읽기 |
8.93% |
홈 페이지 보기 |
읽기 |
1.52% |
|
Microsoft InfoPath |
업사이징 목록 항목 및 새 양식 표시/편집 |
읽기 |
0.32% |
"다른 이름으로 저장" 기능을 사용하여 파일 다운로드 |
읽기 |
1.39% |
|
Microsoft OneNote 2010 |
Microsoft Office OneNote 2007 파일 열기 |
읽기 |
13.04% |
검색 |
OSSSearch.aspx 또는 SearchCenter를 통해 검색 |
읽기 |
4.11% |
워크플로 |
자동 시작 워크플로 시작 |
w |
0.35% |
Microsoft Visio |
PNG/XAML에서 Visio 파일 렌더링 |
읽기 |
0.90% |
Office Web Applications - PowerPoint |
Microsoft PowerPoint 렌더링(6개 슬라이드로 스크롤) |
읽기 |
0.05% |
Office Web Applications - Word |
PNG/Silverlight에서 Microsoft Word 문서 렌더링/스크롤 |
읽기 |
0.24% |
Microsoft SharePoint Foundation |
목록 - 항목 체크 아웃 후 체크 인 |
쓰기 |
0.83% |
목록 - 목록 가져오기 |
읽기 |
0.83% |
|
목록 - Outlook 동기화 |
읽기 |
1.66% |
|
목록 - 목록 항목 변경 내용 가져오기 |
읽기 |
2.49% |
|
목록 - 목록 항목 업데이트 및 새 항목 추가 |
쓰기 |
4.34% |
|
보기 및 보기 모음 가져오기 |
읽기 |
0.22% |
|
웹 가져오기 |
읽기 |
1.21% |
|
액세스가 거부된 페이지 찾아보기 |
읽기 |
0.07% |
|
목록 피드 찾아보기 보기 |
읽기 |
0.62% |
|
보기 목록 찾아보기 |
읽기 |
0.03% |
|
default.aspx(홈 페이지) 찾아보기 |
읽기 |
1.70% |
|
문서 라이브러리에 문서 업로드 찾아보기 |
쓰기 |
0.05% |
|
목록/라이브러리 기본 보기 찾아보기 |
읽기 |
7.16% |
|
DAV를 사용하여 문서 라이브러리에서 문서 삭제 |
쓰기 |
0.83% |
|
DAV를 사용하여 문서 라이브러리에서 문서 가져오기 |
읽기 |
6.44% |
|
DAV를 사용하여 문서 라이브러리에서 문서 잠금 및 잠금 해제 |
쓰기 |
3.32% |
|
DAV를 사용하여 목록 Propfind |
읽기 |
4.16% |
|
DAV를 사용하여 사이트 Propfind |
읽기 |
4.16% |
|
FPSE를 사용하여 문서 나열 |
읽기 |
0.91% |
|
FPSE를 사용하여 문서 업로드 |
쓰기 |
0.91% |
|
모든 사이트 콘텐츠 페이지 찾아보기 |
읽기 |
0.03% |
|
목록 또는 Wiki의 RSS 피드 보기 |
읽기 |
2.03% |
|
Excel Services |
작은/큰 Excel 파일 렌더링 |
읽기 |
1.56% |
작업 영역 |
WXP - Cobalt 내부 프로토콜 |
읽기 |
23.00% |
WXP를 사용하여 전체 파일 업로드 |
쓰기 |
0.57% |
결과 및 분석
이 섹션에서는 테스트 방법과 결과를 설명함으로써 일반적인 부서 포털의 용량 계획을 위한 지침을 제공합니다.
1x1 팜 구성의 결과
결과 요약
웹 서버와 데이터베이스 서버가 각각 1대인 팜에서는 동일한 컴퓨터가 웹 서버 작업을 수행할 뿐 아니라 응용 프로그램 서버 기능도 합니다. 웹 서버라고도 하는 이 컴퓨터에서 병목 현상이 발생함을 명확하게 관찰할 수 있었습니다. 아래의 데이터에서 확인할 수 있는 것처럼, 팜이 이 문서 앞부분에서 설명한 트랜잭션 혼합을 사용하여 사용자 125명의 부하를 처리하는 경우 웹 서버의 CPU 사용률이 약 86%를 기록했습니다. 이 시점에서 팜의 최대 RPS는 101.37이었습니다.
사용자 부하가 낮은 경우에도 이 팜을 정상 상태의 팜이라고 간주하기에는 웹 서버 사용률이 너무 높았습니다. 따라서 테스트에 사용된 작업량 및 데이터 집합에 대해서는 이 구성을 실제 배포로 사용하지 않는 것이 좋습니다.
"안전 영역"의 정의를 고려할 때 이 팜에는 실제로 "안전 영역"이 없었습니다. 즉, 이 팜은 부하가 적은 경우에도 항상 사용률이 높았습니다. "최대 영역"의 경우 부하가 가장 낮을 때(팜이 "최대 영역" 상태일 때) RPS는 75였습니다.
웹 서버가 응용 프로그램 서버로도 사용되어 병목 현상이 발생하기 때문에 다음 테스트 반복에서는 응용 프로그램 서버 역할을 자체 컴퓨터로 분리했습니다.
성능 카운터 및 그래프
아래 표에는 서로 다른 사용자 부하 단계에서 1x1 팜을 테스트하는 중에 캡처된 다양한 성능 카운터가 나와 있습니다.
| 사용자 부하 | 50 | 75 | 100 | 125 |
|---|---|---|---|---|
RPS |
74.958 |
89.001 |
95.79 |
101.37 |
Latency |
0.42 |
0.66 |
0.81 |
0.81 |
Web server CPU |
79.6 |
80.1 |
89.9 |
86 |
Application server CPU |
해당 없음 |
해당 없음 |
해당 없음 |
해당 없음 |
Database server CPU |
15.1 |
18.2 |
18.6 |
18.1 |
75th Percentile (sec) |
0.3 |
0.35 |
0.55 |
0.59 |
95th Percentile (sec) |
0.71 |
0.77 |
1.03 |
1 |
아래 차트에서는 1x1 구성의 RPS 및 대기 시간 결과를 보여 줍니다.
.gif "1x1 확장의 RPS 및 대기 시간이 나와 있는 차트")
아래 차트에서는 1x1 구성의 성능 카운터 데이터를 보여 줍니다.
.gif "1x1 확장의 성능 카운터가 나와 있는 차트")
1x1x1 팜 구성의 결과
결과 요약
웹 서버, 응용 프로그램 서버 및 데이터베이스 서버가 각각 1대인 팜에서는 웹 서버에서 병목 현상이 발생했습니다. 이 섹션의 데이터에서 확인할 수 있는 것처럼, 팜이 이 문서 앞부분에서 설명한 트랜잭션 혼합을 사용하여 사용자 150명의 부하를 처리하는 경우 웹 서버의 CPU 사용률이 약 85%를 기록했습니다. 이 시점에서 팜의 최대 RPS는 124.1이었습니다.
이 구성의 "안전 영역" RPS는 99였으며 75번째 백분위수 대기 시간은 0.23초였습니다. 그리고 웹 서버 CPU 사용률은 약 56%였습니다. 이 데이터에 따르면, 이 팜에서는 약 99의 RPS를 정상적으로 제공할 수 있습니다. 이 팜에서 제공한 "최대 영역" RPS는 123이었습니다(대기 시간: 0.25초, 웹 서버 CPU 사용률 약 85%).
이 테스트 반복에서는 웹 서버 CPU에서 병목 현상이 발생했으므로, 다음 반복에서는 다른 웹 서버를 추가하여 병목 현상을 해결했습니다.
성능 카운터 및 그래프
아래 표에는 서로 다른 사용자 부하 단계에서 1x1x1 팜을 테스트하는 중에 캡처된 다양한 성능 카운터가 나와 있습니다.
| 사용자 부하 | 25 | 50 | 75 | 100 | 125 | 150 |
|---|---|---|---|---|---|---|
RPS |
53.38 |
91.8 |
112.2 |
123.25 |
123.25 |
124.1 |
Latency |
34.2 |
56 |
71.7 |
81.5 |
84.5 |
84.9 |
Web server CPU |
23.2 |
33.8 |
34.4 |
32 |
30.9 |
35.8 |
Application server CPU |
12.9 |
19.7 |
24.1 |
25.2 |
23.8 |
40.9 |
Database server CPU |
0.22 |
0.23 |
0.27 |
0.32 |
0.35 |
0.42 |
75th Percentile (sec) |
0.54 |
0.52 |
0.68 |
0.71 |
0.74 |
0.88 |
아래 차트에서는 1x1x1 구성의 RPS 및 대기 시간 결과를 보여 줍니다.
.gif "1x1x1 확장의 RPS 및 대기 시간이 나와 있는 차트")
아래 차트에서는 1x1x1 구성의 성능 카운터 데이터를 보여 줍니다.
.gif "1x1x1 확장의 성능 카운터가 나와 있는 차트")
2x1x1 팜 구성의 결과
결과 요약
웹 서버가 2대이고 응용 프로그램 서버 및 데이터베이스 서버가 각각 1대인 팜에서는 웹 서버에서 병목 현상이 발생했습니다. 이 섹션의 데이터에서 확인할 수 있는 것처럼, 팜이 이 문서 앞부분에서 설명한 트랜잭션 혼합을 사용하여 사용자 200명의 부하를 처리하는 경우 웹 서버의 CPU 사용률이 약 76%를 기록했습니다. 이 시점에서 팜의 최대 RPS는 318이었습니다.
이 구성의 "안전 영역" RPS는 191이었으며 75번째 백분위수 대기 시간은 0.37초였습니다. 그리고 웹 서버 CPU 사용률은 약 47%였습니다. 이 데이터에 따르면, 이 팜에서는 약 191의 RPS를 정상적으로 제공할 수 있습니다. 이 팜에서 제공한 "최대 영역" RPS는 291이었습니다(대기 시간: 0.5초, 웹 서버 CPU 사용률 약 75%).
이 테스트 반복에서는 웹 서버 CPU에서 병목 현상이 발생했으므로, 다음 반복에서는 다른 웹 서버를 추가하여 병목 현상을 해결했습니다.
성능 카운터 및 그래프
아래 표에는 서로 다른 사용자 부하 단계에서 2x1x1 팜을 테스트하는 중에 캡처된 다양한 성능 카운터가 나와 있습니다.
| 사용자 부하 | 40 | 80 | 115 | 150 | 175 | 200 |
|---|---|---|---|---|---|---|
RPS |
109 |
190 |
251 |
287 |
304 |
318 |
Latency |
0.32 |
0.37 |
0.42 |
0.49 |
0.54 |
0.59 |
Web server CPU |
27.5 |
47.3 |
61.5 |
66.9 |
73.8 |
76.2 |
Application server CPU |
17.6 |
29.7 |
34.7 |
38 |
45 |
45.9 |
Database server CPU |
21.2 |
36.1 |
43.7 |
48.5 |
52.8 |
56.2 |
75th Percentile (sec) |
0.205 |
0.23 |
0.27 |
0.3 |
0.305 |
0.305 |
95th Percentile (sec) |
0.535 |
0.57 |
0.625 |
0.745 |
0.645 |
0.57 |
아래 차트에서는 2x1x1 구성의 RPS 및 대기 시간 결과를 보여 줍니다.
.gif "2x1x1 확장의 RPS 및 대기 시간이 나와 있는 차트")
아래 차트에서는 2x1x1 구성의 성능 카운터 데이터를 보여 줍니다.
.gif "2x1x1 확장의 성능 카운터가 나와 있는 차트")
3x1x1 팜 구성의 결과
결과 요약
마지막으로 웹 서버가 3대이고 응용 프로그램 서버 및 데이터베이스 서버가 각각 1대인 팜에서는 데이터베이스 서버 CPU에서 병목 현상이 발생했습니다. 이 섹션의 데이터에서 확인할 수 있는 것처럼, 팜이 이 문서 앞부분에서 설명한 트랜잭션 혼합을 사용하여 사용자 226명의 부하를 처리하는 경우 데이터베이스 서버의 CPU 사용률이 약 76%를 기록했습니다. 이 시점에서 팜의 최대 RPS는 310이었습니다.
이 구성의 "안전 영역" RPS는 242였으며 75번째 백분위수 대기 시간은 0.41초였습니다. 그리고 데이터베이스 서버 CPU 사용률은 약 44%였습니다. 이 데이터에 따르면, 이 팜에서는 약 242의 RPS를 정상적으로 제공할 수 있습니다. 이 팜에서 제공한 "최대 영역" RPS는 318이었습니다(대기 시간: 0.5초, 데이터베이스 서버 CPU 사용률 약 75%).
이 구성은 테스트 시리즈의 마지막 구성입니다.
성능 카운터 및 그래프
아래 표에는 서로 다른 사용자 부하 단계에서 3x1x1 팜을 테스트하는 중에 캡처된 다양한 성능 카운터가 나와 있습니다.
| 사용자 부하 | 66 | 103 | 141 | 17 | 202 | 226 |
|---|---|---|---|---|---|---|
RPS |
193.8 |
218.5 |
269.8 |
275.5 |
318.25 |
310 |
Latency |
0.3 |
0.41 |
0.47 |
0.58 |
0.54 |
0.78 |
Web server CPU |
33 |
38.3 |
45.8 |
43.3 |
51 |
42.5 |
Application server CPU |
28 |
32.6 |
46.5 |
40 |
45.1 |
43.7 |
Database server CPU |
41.6 |
44.2 |
52.6 |
48 |
61.8 |
75 |
75th Percentile (sec) |
0.22 |
0.24 |
0.30 |
0.65 |
0.78 |
0.87 |
95th Percentile (sec) |
0.49 |
0.57 |
0.72 |
1.49 |
0.51 |
1.43 |
아래 차트에서는 3x1x1 구성의 RPS 및 대기 시간 결과를 보여 줍니다.
.gif "3x1x1 확장의 RPS 및 대기 시간이 나와 있는 차트")
아래 차트에서는 3x1x1 구성의 성능 카운터 데이터를 보여 줍니다.
.gif "3x1x1 확장의 성능 카운터가 나와 있는 차트")
비교
반복 테스트를 수행함으로써 구성이 최대 영역 또는 안전 영역으로 진입하는 지점을 확인할 수 있었습니다. 아래 표에 이러한 지점이 나와 있습니다.
이 문서의 표와 차트에서는 문서 앞부분에 나온 모든 결과를 요약하여 보여 줍니다.
| 토폴로지 | 1x1 | 1x1x1 | 2x1x1 | 3x1x1 |
|---|---|---|---|---|
최대 RPS |
75 |
123 |
291 |
318 |
안전 영역 RPS |
해당 없음 |
99 |
191 |
242 |
최대 대기 시간 |
0.29 |
0.25 |
0.5 |
0.5 |
안전 영역 대기 시간 |
0.23 |
0.23 |
0.37 |
0.41 |
아래 차트에서는 여러 구성에서의 RPS를 간략하게 보여 줍니다.
.gif "각 확장의 RPS를 비교한 차트")
아래 차트에서는 여러 구성에서의 대기 시간을 간략하게 보여 줍니다.
.gif "모든 확장의 대기 시간 비교")
디스크 I/O 참고 사항
이 문서에서 권장 사항을 지정할 때 디스크 I/O 기반 병목 현상은 고려되지 않았습니다. 그러나 이 추세를 확인해 볼 필요는 있습니다. 해당 값은 다음과 같습니다.
| 구성 | 1x1 | 1x1x1 | 2x1x1 | 3x1x1 |
|---|---|---|---|---|
최대 RPS |
75 |
154 |
291 |
318 |
읽기/초 |
38 |
34 |
54 |
58 |
쓰기/초 |
135 |
115 |
230 |
270 |
테스트는 1시간 동안 실행되었으며 사이트/웹/문서 라이브러리 등의 고정된 집합만 사용되었으므로 SQL Server에서는 모든 데이터를 캐시할 수 있었습니다. 따라서 이 테스트에서는 읽기 I/O가 거의 발생하지 않았으며, 읽기보다는 쓰기 I/O 작업이 더 많았습니다. 이러한 현상은 테스트 방법을 사용한 결과이므로 실제 배포를 정확하게 보여준다고 할 수는 없습니다. 대부분의 일반 부서 포털에서는 읽기 작업이 쓰기 작업보다 3~4배 더 많습니다.
다음 차트에는 서로 다른 RPS에서의 I/O가 나와 있습니다.
.gif "모든 확장의 IOPS가 나와 있는 차트")
검색 증분 크롤링을 포함한 테스트
앞서 설명한 것처럼, 지금까지의 모든 테스트는 검색 크롤링 트래픽을 포함하지 않고 수행되었습니다. 지속적인 검색 크롤링이 팜 성능에 어떤 영향을 줄 수 있는지에 대한 정보를 제공하기 위해, 테스트 혼합에 검색 크롤링 트래픽을 포함하여 최대 사용자 RPS 및 그에 해당하는 사용자 대기 시간을 확인하기로 결정했습니다. 이를 위해 3x1x1 팜에 웹 서버를 하나 더 추가하고 크롤링 대상으로 지정했습니다. 이 경우 일반 3x1x1 구성에서 확인되었던 원래 RPS와 비교할 때 RPS가 17% 하락했습니다.
동일한 팜에 대한 또 다른 테스트에서는 리소스 관리자를 사용하여 검색 크롤링에 사용 가능한 리소스를 10%로 제한했습니다. 검색에서 사용하는 리소스가 줄어들면서 팜의 최대 RPS는 6% 상승했습니다.
| 기준 3x1x1 | 증분 크롤링만 | 리소스 관리자 사용 안 함 | 리소스 관리자 10% | |
|---|---|---|---|---|
RPS |
318 |
해당 없음 |
276 |
294.5 |
기준과의 RPS 차이 비율 |
0% |
해당 없음 |
83% |
88% |
데이터베이스 서버 CPU(%) |
83.40 |
8.00 |
86.60 |
87.3 |
SA 데이터베이스 서버 CPU(%) |
3.16 |
2.13 |
3.88 |
4.2 |
웹 서버 CPU(%) |
53.40 |
0.30 |
47.00 |
46.5 |
응용 프로그램 서버 CPU(%) |
22.10 |
28.60 |
48.00 |
41.3 |
크롤링 웹 서버 CPU(%) |
0.50 |
16.50 |
15.00 |
12.1 |
아래 차트에서는 증분 검색 크롤링을 설정한 상태의 테스트 결과를 보여 줍니다.
.gif "검색 실행 시 초당 요청 수")
중요
여기서는 콘텐츠가 많이 변경되지 않는 팜의 증분 크롤링에 대해서만 고려합니다. 전체 검색 크롤링을 수행하거나 콘텐츠가 너무 많이 변경되는 경우에는 리소스 사용률 10%로는 부족합니다. 따라서 전체 검색 크롤링을 실행하거나 팜에서 일반적으로 크롤링 간에 많은 양의 콘텐츠가 변경되는 경우에는 리소스 사용률을 10%로 제한하지 않는 것이 좋습니다.
결과 및 권장 사항 요약
테스트를 수행한 모든 구성의 결과를 요약하자면 다음과 같습니다.
테스트용으로 선택한 구성, 데이터 집합 및 테스트 작업량에서는 SQL Server에서 CPU 병목 현상이 발생할 때까지 최대 3대의 웹 서버까지 수평 확장할 수 있었습니다. 이 시점까지 도달할 수 있었던 최대 RPS 절대값은 약 318이었습니다.
웹 서버를 하나씩 추가할 때마다 RPS도 거의 그에 비례하여 증가했습니다. 따라서 SQL Server에서 병목 현상이 발생하지 않는다면 웹 서버를 계속 더 추가할 수 있으며 그에 따라 RPS가 증가할 것임을 추정할 수 있습니다.
이 테스트에서는 SQL Server에서 병목 현상에 접근했으므로 대기 시간에 큰 영향이 없습니다.
증분 검색 크롤링은 구성에서 제공하는 RPS에 직접적인 영향을 줍니다. 리소스 관리자를 사용하면 이 영향을 최소화할 수 있습니다.
이러한 테스트 결과를 통해, 부서 포털의 RPS를 높여야 하는 경우 RPS 증가 값을 어떻게 하면 보다 높일 수 있는지에 대한 몇 가지 권장 사항을 얻을 수 있었습니다.
1x1 팜의 경우 RPS를 75까지 제공할 수 있지만, 일반적으로 사용률이 높으므로 프로덕션 환경의 부서 포털에 적합한 구성은 아닙니다.
콘텐츠 데이터베이스와 서비스 데이터베이스를 별도의 SQL Server 인스턴스로 분리합니다. 테스트에 사용된 테스트 작업량에서는 SQL Server에서 CPU에 병목 현상이 발생하는 경우 트래픽의 3%만이 서비스 데이터베이스에 사용되었습니다. 따라서 이 단계에서는 앞서 테스트에서 확인한 것보다 약간 더 효율적인 수평 확장이 가능합니다. 그러나 일반적으로는 콘텐츠 데이터베이스 및 서비스 데이터베이스를 분리하여 수평 확장 범위를 넓히는 작업은 팜의 서비스 데이터베이스에 대한 트래픽에 직접 비례합니다.
개별 콘텐츠 데이터베이스를 별도의 SQL Server 인스턴스로 분리합니다. 테스트에 사용된 데이터 집합에는 콘텐츠 데이터베이스가 5개 있었으며, 이들 데이터베이스는 모두 동일한 SQL Server 인스턴스에 배치되었습니다. 콘텐츠 데이터베이스를 다른 컴퓨터로 분리하면 여러 컴퓨터로 CPU 사용률을 분산시킬 수 있으므로 RPS 수치가 훨씬 높아집니다.
마지막으로, SQL Server에서 CPU에 병목 현상이 발생할 때 SQL Server에 CPU를 더 추가하면 팜의 RPS가 거의 CPU 수와 비례하여 증가할 수 있습니다.
테스트 결과를 배포에 직접 적용하는 방법
이 문서에서는 RPS 및 대기 시간으로 측정한 결과에 대해 설명했습니다. 그러면 이러한 결과를 실제 배포에는 어떻게 적용할 수 있을까요? 다음은 Microsoft 내부의 부서 포털 환경을 기반으로 한 몇 가지 수식입니다.
Microsoft의 부서 포털은 공동 작업을 매우 많이 수행하는 8천 명의 직원을 지원하며, 평균 RPS는 110입니다. 따라서 사용자 대 RPS 비율은 최대 72 정도입니다(8000/110). 이 비율과 문서 앞부분에서 설명한 결과를 토대로 하여 특정 팜 구성에서 문제 없이 지원할 수 있는 사용자 수를 예측할 수 있습니다.
| 팜 구성 | "안전 영역" RPS | 지원 가능한 대략적인 사용자 수 |
|---|---|---|
1x1x1 |
99 |
7128 |
2x1x1 |
191 |
13452 |
3x1x1 |
242 |
17424 |
물론 이러한 수치는 실제로 사용하는 트랜잭션 혼합 및 하드웨어가 이 문서에서 설명한 테스트에 사용된 것과 정확히 동일한 경우에만 직접 적용 가능합니다. 실제 부서 포털의 사용 현황 패턴은 각각 다를 수 있으므로, 이 비율을 직접 적용할 수는 없지만 대략적으로는 적용해 볼 수 있습니다.
저자 정보
Gaurav Doshi는 Microsoft의 SharePoint Server 프로그램 관리자입니다.
Raj Dhrolia는 Microsoft의 SharePoint Server 소프트웨어 테스트 엔지니어입니다.
Wayne Roseberry는 Microsoft의 SharePoint Server 테스트 책임자입니다.