SharePoint Server 2010의 웹 콘텐츠 관리에 대한 성능 및 용량 요구 사항 예측

 

적용 대상: SharePoint Server 2010

마지막으로 수정된 항목: 2016-11-30

이 문서에는 게시 인프라를 사용하는 Microsoft SharePoint Server 2010 사이트와 관련된 용량 관리에 대한 지침이 나와 있습니다. 이 문서에서는 SharePoint Server 2010과 관련된 사항만 다루므로 SharePoint Foundation에는 여기에 설명된 내용이 적용되지 않습니다.

이 문서에서는 다음 시나리오에 대해 설명합니다.

• 인터넷 게시 사이트 - 회사 소개 사이트

  이러한 종류의 사이트는 인터넷에 게시되며 익명 인터넷 사용자가 회사에 관한 정보를 찾을 때 사용할 수 있습니다. 이와 같은 사이트에는 상표가 있으며 콘텐츠가 엄격하게 관리됩니다.

• 인트라넷 게시 사이트 - 내부 뉴스 사이트

  이러한 종류의 사이트는 조직 내부에 게시되며 주로 조직 내의 인증된 사용자 간에 정보를 공유하는 데 사용됩니다. 사이트의 정보는 엄격하게 관리되거나 일부 영역은 느슨하게 관리될 수도 있습니다.

• 엔터프라이즈 위키 - 지식 저장소

  엔터프라이즈 위키는 작성자가 새로운 페이지를 만들어 페이지를 이미 있거나 아직 만들어지지 않은 다른 페이지에 연결함에 따라 그 크기가 유기적으로 증가하는 단일 팜 사이트입니다. 엔터프라이즈 위키는 일반적으로 조직 내부에 게시됩니다. 이 사이트를 사용하면 회사나 조직의 사용자가 사이트에 통합되어 있으며 SharePoint 환경을 통해 향상된 솔루션을 사용하여 지식을 얻고 공유할 수 있습니다.

이 문서를 읽고 나면 다음 개념을 이해할 수 있습니다.

• 많은 읽기 작업을 지원하도록 최적화해야 할 주요 메트릭(처리량)

• 웹 콘텐츠 관리 SharePoint Server 2010 배포와 관련된 다양한 잠재적 병목 현상

• 처리량을 극대화하는 데 있어서 출력 캐시의 중요성

• 쓰기 작업이 최종 사용자의 읽기 경험에 가져오는 영향

이 문서의 내용:

• 사전 필수 정보

• 테스트 세부 정보 및 접근 방식

• 웹 콘텐츠 관리 배포

• 최적화할 항목

• 테스트 결과 및 권장 사항

• 저자 정보

사전 필수 정보

이 문서를 읽기 전에 SharePoint Server 2010 용량 관리의 기반이 되는 주요 개념을 이해하고 있어야 합니다. 다음 설명서는 용량 관리를 위한 권장 접근 방식에 대해 알아보는 데 유용한 내용을 제공하며 이 문서의 정보를 효과적으로 활용할 수 있도록 하는 배경 정보를 제공합니다.

이 문서의 내용을 파악하는 데 도움이 되는 성능 및 용량 관리에 대한 자세한 개념 정보는 다음 문서를 참조하십시오.

• SharePoint Server 2010의 용량 관리 및 크기 조정(영문일 수 있음)

• 성능 및 용량 기술 사례 연구(SharePoint Server 2010)(영문일 수 있음)

테스트 세부 정보 및 접근 방식

각 테스트에서는 실제 환경에서 존재할 수 있는 일부 변수를 뽑아 구체적인 권장 사항을 보여 줍니다. 따라서 사용자 고유의 환경에서 테스트 및 모니터링을 수행하여 예상되는 요청 볼륨을 만족하도록 배포를 적절히 확장해야 합니다. 용량 관리 개념에 대한 자세한 내용은 SharePoint Server 2010의 용량 관리 및 크기 조정 개요를 참조하십시오.

이 문서에서는 사이트 모음 기능, SharePoint Server 게시 인프라 및 출력 캐싱 기능을 사용하여 성능에 대해 설명합니다. 이러한 기능은 SharePoint Server 게시 인프라가 사용하도록 설정된 경우에만 사용할 수 있습니다. 게시 포털에서는 이 기능이 기본적으로 사용됩니다.

데이터 집합

실제 웹 콘텐츠 관리 배포와 공통된 특성을 공유하는 데이터 집합을 사용하여 테스트가 수행되었습니다. 부하는 일정했지만 요청된 페이지는 다양했습니다. 다음 표에서는 테스트에 사용된 데이터 집합을 보여 줍니다.

데이터 집합

개체	게시 사이트
콘텐츠 데이터베이스 크기	2.63GB
콘텐츠 데이터베이스 수	1
사이트 모음 수	1
웹 응용 프로그램 수	1
사이트 수	50
페이지 수	20,000페이지(1,000페이지씩 모두 20개 폴더에 분리)
페이지 구성	두 개의 이미지에 대한 참조를 포함하는 기본 HTML 형식의 문서 페이지
페이지 크기	42KB(압축하지 않았을 때), 12KB(압축했을 때)
이미지	각각 30KB-1.3MB의 이미지 3,000개

기본 설정 대신 항상 파일을 압축하도록 IIS(인터넷 정보 서비스)를 구성하여 파일을 동적으로 압축하는 것이 좋습니다. 동적 압축을 사용하는 경우 CPU 사용률이 특정 임계값을 초과할 때까지 페이지를 압축합니다. CPU 사용률이 특정 임계값을 초과하면 IIS에서는 사용률이 임계값 아래로 떨어질 때까지 페이지 압축을 중단합니다. 이 문서의 테스트는 항상 압축을 사용하여 수행되었습니다.

이 테스트 데이터 집합에서는 제품에 포함된 기본 SharePoint Server 2010 기능만 사용했습니다. 사용자 사이트에는 이러한 기본 기능 외에 사용자 지정한 내용이 포함되어 있을 수 있으므로 반드시 고유 솔루션의 성능을 테스트해야 합니다.

하드웨어

팜의 웹 서버 수는 테스트마다 달랐지만 하드웨어는 모두 동일했습니다. 다음 표에서는 테스트에 사용된 웹 서버 및 응용 프로그램 서버의 하드웨어에 대해 설명합니다.

응용 프로그램 서버 및 웹 서버의 하드웨어 사양

	웹 서버
프로세서	쿼드 코어 2개(2.33GHz)
RAM	8GB
운영 체제	Windows Server 2008(64비트)
SharePoint 드라이브 크기	300GB
네트워크 어댑터 수	2
네트워크 어댑터 속도	1기가비트
인증	Windows 기본
부하 분산 유형	하드웨어 부하 분산
소프트웨어 버전	SharePoint Server 2010(시험판)
로컬로 실행되는 서비스	중앙 관리 Microsoft SharePoint Foundation 받는 전자 메일 Microsoft SharePoint Foundation 웹 응용 프로그램 Microsoft SharePoint Foundation 워크플로 타이머 서비스

다음 표에서는 테스트에 사용된 데이터베이스 서버 하드웨어에 대해 설명합니다.

데이터베이스 서버의 하드웨어 사양

	데이터베이스 서버
프로세서	쿼드 코어 4개(3.19GHz)
RAM	16GB
운영 체제	Windows Server 2008(64비트)
저장소	300GB 디스크 15개(15,000RPM)
네트워크 어댑터 수	2
네트워크 어댑터 속도	1기가비트
인증	NTLM
소프트웨어 버전	Microsoft SQL Server 2008

용어

이 문서에는 몇 가지 전문 용어가 나옵니다. 다음은 주요 용어와 각각에 대한 정의입니다.

• RPS   초당 요청 수를 나타냅니다. 팜이나 서버에서 1초 동안 받은 요청의 수로, 일반적으로 서버와 팜의 부하를 측정하는 데 사용되는 측정 단위입니다.

  요청과 페이지 로드는 서로 다른 개념입니다. 각 페이지에는 여러 가지 구성 요소가 포함되어 있으며 이러한 구성 요소 각각은 페이지를 로드할 때 하나 이상의 요청을 생성합니다. 따라서 한 번의 페이지 로드에서 여러 개의 요청이 생성됩니다. 일반적으로 리소스를 많이 사용하지 않는 인증 검사와 이벤트는 RPS를 측정할 때 포함되지 않습니다.

• 녹색 지대   서버에서 다음과 같은 일련의 조건을 유지할 수 있는 상태입니다.

  • 요청의 75% 이상에 대해 서버 쪽 대기 시간이 1초 미만입니다.

  • 모든 서버의 CPU 사용률이 50% 미만입니다.

  • 오류 비율이 0.01% 미만입니다.

웹 콘텐츠 관리 배포

SharePoint 게시 사이트에서 콘텐츠를 제작하는 데 사용되는 모델은 두 가지이며 사용되는 모델에 따라 선택할 서버 팜 토폴로지가 결정됩니다.

전체 제작 모델에서는 제작자와 방문자가 단일 사이트 모음을 공유합니다. 제작자는 언제든지 콘텐츠를 만들고 업데이트할 수 있으므로 어느 한 날짜에 읽기 및 쓰기 작업의 배포가 달라질 수 있습니다. 이 서버 팜에서는 일반적으로 많은 횟수의 읽기 작업과 적절한 횟수의 쓰기 작업이 발생합니다.

다음 다이어그램에서는 토폴로지 측면에서 전체 제작 모델의 작동 방식을 보여 줍니다.

콘텐츠 배포 모델에서는 여러 사이트 모음에서 개별적으로 그리고 독점적으로 콘텐츠 제작과 게시를 지원합니다. 제작 환경에서 콘텐츠가 만들어져 업데이트된 다음 방문자가 읽을 수 있도록 예약된 일정에 따라 게시 환경에 배포됩니다. 제작 환경에서 콘텐츠가 배포될 때를 제외하고는 게시 환경에서는 주로 읽기 요청을 처리합니다. 전체 제작 모델과는 달리 콘텐츠 배포로 인해 발생하는 서버 부하는 예약된 간격에 맞게 조정이 가능합니다.

다음 다이어그램에서는 토폴로지 측면에서 콘텐츠 배포 모델의 작동 방식을 보여 줍니다.

두 가지 콘텐츠 제작 모델을 함께 사용할 수 없습니다.

인터넷 게시 사이트와 인트라넷 게시 사이트에서는 전체 제작 모델이나 콘텐츠 배포 모델 중 하나를 사용할 수 있지만 엔터프라이즈 위키는 전체 제작 모델에서 가장 잘 작동합니다. 엔터프라이즈 위키에서는 일반적으로 사용자의 대부분이 페이지를 편집할 수 있으므로 읽기 작업에 비해 쓰기 작업이 상대적으로 많이 이루어집니다. 엔터프라이즈 위키 페이지는 게시 문서 페이지와는 다르며 따라서 다른 성능 특성을 보여 줍니다.

최적화할 요소

이 섹션에서는 웹 콘텐츠 관리 환경을 최적화하는 것에 관한 정보를 제공합니다. 환경을 최적화하려면 처리량, 병목 현상 및 캐싱을 관리하는 방법을 이해해야 합니다.

이 섹션의 내용:

• 주요 메트릭으로 작용하는 처리량

• 병목 현상 및 수정

• 캐싱 도움말

주요 메트릭으로 작용하는 처리량

처리량과 응답 시간은 SharePoint Server 2010 웹 콘텐츠 관리 배포의 용량을 계획할 때 최적화해야 할 가장 중요한 메트릭입니다. 처리량은 서버 팜에서 초당 수행할 수 있는 작업의 수를 나타내며 RPS(초당 요청 수)로 측정됩니다.

병목 현상 및 수정

병목 현상이란 시스템 리소스가 모두 사용되어 서버 팜에서 추가 요청을 처리하지 못하는 상태를 말합니다. 다음 다이어그램에서는 서버 팜의 요소와 병목 현상을 야기할 수 있는 리소스 및 모니터링해야 할 항목을 보여 줍니다.

웹 서버 CPU 사용률

웹 서버 CPU는 가장 손쉽게 확장할 수 있는 구성 요소이므로 적절히 조정된 토폴로지에서도 병목 현상을 야기할 수 있습니다. 부하 부산 장치는 웹 서버 간에 요청을 라우팅하여 모든 서버가 고르게 사용되도록 합니다.

웹 서버의 CPU 사용률이 100%에 도달한 후에도 추가 사용자가 사이트를 방문할 수는 있지만 이 경우 사용자가 경험하는 서버 응답 시간이 늘어납니다. 이러한 동작은 급증한 요청의 양을 관리하는 데 도움이 됩니다. 그러나 서버 팜의 용량을 넘어서는 부하는 결국 요청 백로그를 만들어 대기 중인 요청 임계값을 초과할 수 있습니다. 이때 웹 서버에서는 요청을 제한하고 HTTP 오류 503으로 응답합니다. 다음 그림에서는 대기 중인 요청 임계값에 도달한 후 서버 응답 시간이 줄어드는데 이는 HTTP 오류만 제공되기 때문입니다.

이 다이어그램에는 다음과 같은 변경이 나타나 있습니다.

1. 웹 서버의 CPU 사용률이 100%에 도달하면 응답 시간이 늘어납니다.

2. 대기 중인 요청 임계값을 초과한 후에는 추가 요청에 대해 오류가 반환됩니다.

기타 병목 현상

웹 서버 CPU가 병목 현상을 야기하는 요인이 아니라면 그 다음에는 팜 토폴로지, 팜 구성 또는 제공되는 페이지의 콘텐츠로 인해 병목 현상이 발생하지 않는지 조사해야 합니다. 이러한 요소가 지닌 잠재적인 병목 현상은 다음과 같습니다.

1. 네트워크    처리량이 높은 상황에서는 웹 서버와 데이터베이스 서버 사이에서 또는 웹 서버와 최종 사용자 사이에서 네트워크가 포화 상태가 될 수도 있습니다. 이러한 상황이 발생하지 않도록 하려면 웹 서버에 듀얼 기가비트 네트워크 어댑터를 사용하는 것이 좋습니다.

2. 데이터베이스 서버 CPU    데이터베이스 서버 CPU에서 병목 현상을 일으키는 경우에는 서버 팜에 웹 서버를 추가해도 팜에서 지원할 수 있는 최대 처리량이 늘어나지 않습니다. 웹 서버 CPU가 아니라 데이터베이스 CPU로 인한 병목 현상은 다음과 같은 두 가지 상황을 반영할 수 있습니다.

   1. 캐시 설정이 잘못되었거나 매우 느린 페이지 특히, 출력 캐시를 사용하지 않는 페이지가 있을 수 있습니다. 이러한 경우 데이터베이스 서버 CPU 사용률이 높지만 처리량은 낮거나 보통이며 웹 서버 사용률도 낮거나 보통입니다.

   2. 데이터베이스 서버가 팜에 필요한 처리량 용량에 도달했을 수 있습니다. 이러한 경우에는 처리량이 높은 상태에서 웹 서버와 데이터베이스 서버의 CPU 사용률이 높습니다.

캐싱 도움말

SharePoint Server 2010에서는 세 가지 종류의 캐싱을 사용합니다. 이러한 캐시의 일반적인 목적은 자주 요청되는 데이터에 대한 데이터베이스 호출 수를 줄여 효율성을 개선하는 데 있습니다. 캐시를 사용하면 페이지에 대한 이후 요청을 웹 서버의 캐시에서 처리할 수 있으므로 웹 서버 및 데이터베이스 서버의 리소스 사용률이 현저히 줄어듭니다.

세 가지 캐싱은 다음과 같습니다.

• 출력 캐시   이 캐시는 요청된 페이지 콘텐츠를 웹 서버의 메모리에 저장합니다. 출력 캐시에 대한 자세한 내용은 출력 캐싱 및 캐시 프로필(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=121543&clcid=0x412)(영문일 수 있음)을 참조하십시오.

• 개체 캐시   이 캐시는 웹 및 목록 항목 메타데이터와 같은 SharePoint 개체를 웹 서버의 메모리에 저장합니다. 개체 캐시에 대한 자세한 내용은 개체 캐싱(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=123948&clcid=0x412)(영문일 수 있음)을 참조하십시오.

• BLOB(Binary Large Object)용 디스크 기반 캐시   이 캐시는 이미지, 사운드, 비디오 파일 및 기타 대용량 이진 파일을 디스크에 저장합니다. BLOB 캐시에 대한 자세한 내용은 Binary Large Object를 위한 디스크 기반 캐싱(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=123947&clcid=0x412)(영문일 수 있음)을 참조하십시오.

이 세 가지 캐시는 높은 처리량을 유지하는 데 모두 중요한 역할을 하지만 그 중에서도 출력 캐싱이 가장 큰 영향을 줍니다. 이 문서에서는 출력 캐싱에 대해 자세히 설명합니다.

테스트 결과 및 권장 사항

이 섹션에서는 테스트가 수행된 특정 영역에 대해 설명하고 테스트를 통해 얻은 권장 사항을 제시합니다.

이 섹션의 내용:

• 출력 캐시 사용이 가져오는 영향

• 익명 사용자 및 인증된 사용자

• 읽기/쓰기 작업의 수평 확장 특성

• 출력 캐시의 단점

• 읽기 볼륨이 CPU 및 응답 시간에 가져오는 영향

• 쓰기 작업이 처리량에 가져오는 영향

• 콘텐츠 배포의 영향

• 콘텐츠 배포 내보내기 중 데이터베이스 스냅숏이 가져오는 영향

• 콘텐츠 특성

출력 캐시 사용이 가져오는 영향

출력 캐시는 많은 읽기 작업에 대해 SharePoint Server 2010 솔루션을 최적화하는 데 사용할 수 있는 매우 유용한 기능입니다.

테스트에서는 최대 RPS를 결정하기 위해 데이터베이스 서버 또는 웹 서버 중 하나의 CPU 사용률이 100%에 도달해 병목 현상을 일으킬 때까지 팜에서 요청을 생성하는 활성 사용자의 수를 계속 늘렸습니다. 이 테스트는 다양한 출력 캐시 적중률에서 웹 서버 수평 확장의 효과를 보여 줄 수 있도록 1x1(웹 서버 1대와 데이터베이스 서버 1대), 2x1, 4x1 및 8x1 팜 토폴로지에서 수행되었습니다.

출력 캐시 적중률

출력 캐시 적중률은 출력 캐시 적중 횟수 대 누락 횟수의 비율을 측정한 것입니다.

• 캐시 적중은 캐시에서 이미 캐시에 저장되어 있는 개체 데이터에 대한 요청을 받을 때 발생합니다.

• 캐시 누락은 캐시에 저장되어 있지 않은 개체 데이터에 대한 요청을 받을 때 발생합니다. 캐시 누락이 발생할 경우 캐시에서는 요청된 개체 데이터를 저장하여 해당 데이터에 대한 이후 요청을 캐시에서 처리할 수 있도록 합니다.

페이지 요청 시 캐시 누락이 발생하는 데는 몇 가지 이유가 있습니다.

• 출력 캐시를 사용하지 않도록 구성되어 있는 페이지

• 개인 설정 페이지(예: 현재 사용자와 관련된 데이터가 포함된 페이지)

• 출력 캐시 변형 키당 최초로 탐색하는 경우

• 캐시된 콘텐츠가 만료된 후 최초로 탐색하는 경우

다음 다이어그램에서는 웹 서버가 1~4대이고 데이터베이스 서버가 1대인 팜에서 출력 캐시가 최대 처리량에 주는 영향을 보여 줍니다.

다음 표에서는 웹 서버가 1~4대이고 데이터베이스 서버가 1대인 팜 토폴로지에서 출력 캐시 적중률이 가져오는 영향을 보여 줍니다.

다양한 팜 토폴로지에서 출력 캐시 적중률이 가져오는 영향

출력 캐시 적중률	측정값	1x1	2x1	4x1
100%	최대 RPS SQL Server CPU 사용률	3,463 0%	7,331 0%	11,032 0%
95%	최대 RPS SQL Server CPU 사용률	2,137 5.93%	3,945 12.00%	5,937 21.80%
90%	최대 RPS SQL Server CPU 사용률	1,518 7.12%	2,864 14.40%	4,518 28.00%
50%	최대 RPS SQL Server CPU 사용률	459 9.86%	913 19.50%	1,596 42.00%
0%	최대 RPS SQL Server CPU 사용률	172 9.53%	339 19.00%	638 36.30%

출력 캐시 사용이 가져오는 영향 결론 및 권장 사항

출력 캐시 적중률이 높을수록 최대 RPS도 현저히 증가합니다. 따라서 출력 캐싱을 사용하여 SharePoint Server 2010 게시 솔루션을 최적화하는 것이 좋습니다. 사이트 모음의 출력 캐시 설정 페이지에서 출력 캐시를 구성할 수 있습니다. 자세한 내용은 Office.Microsoft.com 웹 사이트에서 사이트 모음의 페이지 출력 캐시 설정 구성(https://go.microsoft.com/fwlink/?linkid=205058&clcid=0x412)을 참조하십시오.

출력 캐싱을 사용하고 수행된 테스트에서 페이지를 캐시한 첫 번째 요청은 제외되었습니다. 즉, 페이지의 일부는 이미 캐시에 저장되어 있습니다. 사용자가 캐시되지 않은 페이지를 처음 요청하면 해당 페이지가 캐시에 추가됩니다. 캐시가 용량에 도달했거나 거의 도달하면 가장 오래 전에 요청된 데이터가 정리됩니다.

0%의 캐시 적중률은 환경에서 사용 중인 출력 캐시가 비워진 후 다시 채워지는 사이의 짧은 기간을 시뮬레이션합니다. 예를 들어 실제 환경에서는 매일 응용 프로그램 풀이 재생될 때 캐시 적중률 0%가 관찰됩니다. 응용 프로그램 풀 재생과 다음 페이지 요청 및 캐싱 사이에 캐시 적중률이 0%인 짧은 기간을 허용하도록 하드웨어를 적절히 수직 또는 수평 확장해야 합니다. 0%의 캐시 적중률은 출력 캐싱이 사용되지 않는 환경도 시뮬레이션합니다.

익명 사용자 및 인증된 사용자

앞의 테스트에서는 사이트에 대한 모든 요청이 익명 독자에 의해 이루어지는 것으로 가정합니다. 그러나 사용자 고유의 사이트에서는 사용자 중 일부 또는 모두가 인증을 받을 수도 있습니다. 인증된 읽기 시나리오의 예로는 회사 인트라넷 게시 사이트와 인터넷 사이트의 회원 전용 콘텐츠를 들 수 있습니다.

출력 캐시 프로필을 사용하면 인증된 사용자에 대해 익명 사용자와는 다른 출력 캐시 동작을 지정할 수 있습니다.

캐시 프로필

캐시 프로필은 사이트 배포의 페이지, 페이지 항목, 콘텐츠 형식 및 여러 수준의 요소에 적용할 수 있는 설정을 모아 놓은 것입니다. 캐시 프로필은 다음과 같은 유형의 캐시 동작을 정의합니다.

• 항목이 캐시에 보관되어야 하는 기간

• 보안 조정 정책

• 기간 및 변경 등의 설정 만료

• 사용자 사용 권한, 사용자 권한 및 기타 사용자 지정 변수를 기반으로 하는 캐시된 콘텐츠의 변형

캐시 프로필이 변경되면 사이트의 해당되는 모든 콘텐츠가 곧바로 영향을 받습니다. 익명 사용자와 인증된 사용자에 대해 서로 다른 캐시 프로필을 설정할 수 있습니다.

익명 사용자에게는 공용 인터넷(익명) 출력 캐시 프로필이 사용되고 인증된 사용자에게는 엑스트라넷(게시된 사이트) 출력 캐시 프로필이 사용되었습니다.

다음 차트에서는 인증된 처리량이 데이터베이스 서버 CPU 사용률에 가져오는 영향을 보여 줍니다.

인증 모델은 Windows 기본 인증이었습니다. 인터넷 사이트에는 Windows 기본 인증을 사용하지 않는 것이 좋지만 이 인증 방법을 선택한 이유는 인증으로 인한 최소한의 오버헤드를 보여 주기 위해서였습니다. 이 오버헤드의 규모는 해당 인증 메커니즘마다 다릅니다. 고유의 배포를 테스트할 때는 인증 메커니즘으로 인한 영향을 고려해야 합니다. SharePoint Server 2010에서 지원하는 인증 메커니즘에 대한 자세한 내용은 인증 방법 계획(SharePoint Server 2010)을 참조하십시오.

익명 사용자 및 인증된 사용자 결론 및 권장 사항

인증된 사용자 환경은 RPS를 낮추고 수평 확장 잠재력을 떨어뜨리는데, 이는 자격 증명을 검사하는 추가 작업으로 인해 데이터베이스 서버에서 부하가 발생하기 때문입니다. 테스트 결과에서 보여 주듯이 사용자가 인증될 때 관찰되는 최대 RPS는 익명 액세스 팜보다 눈에 띄게 낮습니다.

읽기/쓰기 작업의 수평 확장 특성

이 테스트에서는 시간당 쓰기 횟수를 기록했습니다. 이 문서에서 쓰기란 새 게시 페이지를 만들고 체크 인하는 것 또는 기존 게시 페이지를 편집하고 체크 인하는 것을 의미합니다.

다음 테스트에서는 웹 서버 CPU 사용률이 80~90%에 도달할 때까지 시스템에 독자를 추가한 다음 인위적 지연을 사용하여 환경에서 쓰기 작업을 수행했습니다. 이 테스트에서 시간당 총 쓰기 횟수는 대략 500회였습니다. 모든 테스트에 90%의 출력 캐시 적중률을 사용했습니다. 1x1, 2x1 및 4x1 팜에서도 동일한 테스트를 수행했으며 웹 서버와 SQL Server CPU 사용률을 관찰하고 각 구성에서의 총 읽기 처리량도 관찰했습니다. 그뿐만 아니라 익명 읽기 전용 구성을 기준점으로 삼아 테스트했으며 Windows 기본 인증을 사용하여 인증된 독자를 포함하는 구성도 테스트했습니다.

읽기 전용 수평 확장 테스트에서는 웹 서버 CPU가 100% 사용되었지만 쓰기가 포함된 수평 확장 테스트에서는 웹 서버 CPU를 80~90%로 유지했습니다. 이는 쓰기 작업이 수행되는 동안 추가 CPU를 사용할 수 있는 여지를 남겨 놓기 위해서였습니다.

다음 차트에서는 각 테스트에서 관찰된 총 읽기 RPS를 보여 줍니다. 읽기 RPS는 웹 서버가 추가됨에 따라 연속적으로 확장되며 이는 쓰기 작업이 이루어지는 경우에도 마찬가지입니다. 그러나 쓰기 작업이 통합되는 경우에는 RPS가 줄어듭니다.

데이터베이스 서버 CPU 사용량은 웹 서버의 수가 늘어남에 따라 증가했습니다. 다음 차트에서는 다양한 구성에서 SQL Server CPU 사용량이 늘어나는 패턴을 보여 줍니다. 이 문서 앞부분의 익명 사용자 및 인증된 사용자 섹션에서 살펴봤듯이 인증은 데이터베이스 서버 CPU 사용률에 영향을 주며 이러한 영향은 쓰기 작업이 추가됨에 따라 더 두드러지게 나타납니다. 이 또한 데이터베이스 서버 CPU 사용률에 영향을 줍니다.

SQL Server 사용량의 예측된 추세는 SQL Server가 인증된 읽기 요청이 있는 6대의 웹 서버에서 병목 현상을 일으킨다는 것을 보여 줍니다. 그러나 익명 읽기의 경우 웹 서버의 수를 수평 확장하면 이러한 부하를 감당할 수 있습니다.

일반적인 배포의 추가 요인은 데이터베이스 서버의 부하에 영향을 주므로 용량 계획을 세울 때 이러한 요인을 반드시 고려해야 합니다. 일반적인 데이터베이스 서버 CPU 사용률에 대한 녹색 지대를 결정하는 방법에 대한 자세한 내용은 SharePoint Server 2010의 용량 관리 및 크기 조정 개요를 참조하십시오.

읽기/쓰기 작업의 수평 확장 특성 결론 및 권장 사항

테스트 데이터에 비추어 봤을 때 데이터베이스 서버에서 병목 현상을 일으키지 않는 경우 웹 서버의 수를 수평 확장하는 것이 처리량을 늘리는 데 효과적인 전략임을 알 수 있습니다. 평균적으로 익명 읽기/인증된 쓰기 테스트를 혼합했을 때는 익명 읽기/쓰기 없음 테스트를 혼합했을 때에 비해 웹 서버 CPU 사용률이 52% 증가했습니다. 또한 인증된 읽기는 많은 추가 SQL Server 부하를 야기하는데 이는 각 요청에서 추가 인증 검사가 수행되도록 하며 이로 인해 SQL Server로의 왕복이 필요하기 때문입니다.

다음 차트에서는 처리량이 데이터베이스 서버 CPU 사용률에 가져오는 영향을 보여 줍니다.

출력 캐시의 단점

용량 관리 계획에서 RPS를 최대화하는 문제만 고려해도 된다면 테스트 결과에 비추어 봤을 때 최적의 캐시 적중률은 100%입니다. 그러나 데이터 새로 고침 요구 사항이나 메모리 제한으로 인해 페이지의 일부 또는 모두에 대해 출력 캐시를 사용하는 것이 가능하지 않거나 바람직하지 않을 수도 있습니다.

데이터 새로 고침

출력 캐시에서 제공하는 데이터에 원래 콘텐츠에 발생한 최신 업데이트가 포함되어 있지 않을 수도 있습니다. 콘텐츠 배포 원본에서 또는 인증된 제작자의 경우 프로덕션 내 제작 시나리오에서 제작자는 기존 콘텐츠를 업데이트한 후 최신 변경 내용을 곧바로 확인하고 싶어할 것입니다.

이 문제는 캐시 프로필에서 기간 속성을 설정하여 해결할 수 있습니다. 속성은 캐시된 페이지가 만료되기 전에 출력 캐시에 유지되는 기간을 지정합니다. 페이지가 만료되면 캐시에서 제거되며 해당 페이지에 대한 이후 요청에 대해서는 캐시 누락이 발생하여 그 결과 페이지 콘텐츠가 새로 고쳐집니다.

변경 내용 확인 캐시 프로필 속성을 설정하여 서버에서 페이지가 캐시된 시간과 사이트 모음에서 콘텐츠가 마지막으로 수정된 시간을 비교하도록 할 수도 있습니다. 타임스탬프가 일치하지 않는 페이지가 요청될 경우 사이트 모음의 모든 페이지에 대해 캐시가 무효화됩니다. 변경 내용 확인 속성은 사이트 모음의 모든 페이지에 영향을 주므로 업데이트 빈도가 낮고 기본적으로 정적인, 인증된 전체 제작 솔루션이 있는 경우에만 이 옵션을 설정하는 것이 좋습니다. 이 옵션과 함께 기간 속성 값을 길게 설정하면 사이트가 업데이트될 때까지 모든 페이지가 캐시에서 제공됩니다.

변경 내용 확인 속성은 기본적으로 설정되어 있지 않습니다. 즉, 웹 서버에서는 기본이 되는 원래 ASPX 페이지가 수정되었는지 여부에 관계없이 아직 만료되지 않은 페이지에 대한 요청에 응답하여 출력 캐시에서 데이터를 제공합니다.

1x1 서버 팜에서 수행된 이 테스트는 변경 내용 확인 속성을 제외하면 읽기/쓰기 작업의 수평 확장 특성 섹션의 테스트와 모든 변수가 동일합니다. 변경 내용 확인 속성이 설정되어 있으면 캐시가 더 자주 비워져 출력 캐시 적중률이 낮아집니다.

다음 차트에서는 변경 내용 확인 속성이 처리량에 가져오는 영향을 보여 줍니다.

특별한 경우를 제외하면 변경 내용 확인 출력 캐시 프로필 속성은 설정하지 않는 것이 좋습니다. 전체 제작 모델을 사용하며 콘텐츠가 자주 변경되지 않는 사이트의 경우 인증된 사용자에 대해 긴 캐시 기간과 함께 이 속성을 설정하면 효과가 있을 수도 있지만 그 외 다른 종류의 사이트에서는 RPS가 저하될 가능성이 높습니다.

고유의 요구 사항에 따라 즉시 또는 기본 설정에서 허용하는 것보다 빠르게 사이트에 올려야 할 시간을 다투는 콘텐츠가 있을 수도 있습니다. 이 경우 기간을 줄이거나 출력 캐싱을 사용하지 않아야 합니다.

출력 캐시의 단점 결론 및 권장 사항

출력 캐싱으로 용량 관리와 관련된 모든 문제가 해결되는 것은 아니며 출력 캐싱이 적합하지 않은 경우도 있습니다. 따라서 출력 캐시를 사용하고 출력 캐시 프로필을 구성할 때 이러한 점을 고려해야 합니다.

읽기 볼륨이 CPU 및 응답 시간에 가져오는 영향

이 테스트는 익명 액세스 및 출력 캐싱을 사용하여 1x1 팜에서 수행되었습니다.

다음 차트에서는 읽기 볼륨이 CPU 및 응답 시간에 가져오는 영향을 보여 줍니다.

읽기 볼륨이 CPU 및 응답 시간에 가져오는 영향 결론 및 권장 사항

병목 현상 및 수정 섹션에 나오듯이 서버 응답 시간은 웹 서버에서 웹 서버의 CPU를 완전히 사용할 정도로 충분한 요청 볼륨을 받을 때까지 일반적으로 일정하게 유지됩니다. 웹 서버 CPU가 완전히 사용되면 응답 시간이 눈에 띄게 증가합니다. 그러나 서버 팜에서는 여전히 어느 정도의 추가 요청 볼륨을 처리할 수 있습니다.

쓰기 작업이 처리량에 가져오는 영향

테스트에서 만들기 작업과 편집 작업은 비율이 고르게 분산되었습니다. 시간당 쓰기 횟수는 최대 500회까지 테스트되었는데 시간당 500페이지 이상을 만들거나 편집하는 것은 대부분의 SharePoint 배포가 작동하는 범위를 벗어나기 때문입니다. 콘텐츠 배포와 같은 자동화된 프로세스는 테스트에서 다루지 않았는데 이에 대해서는 콘텐츠 배포의 영향 섹션에 설명되어 있습니다. 이러한 만들기 및 편집 작업은 여러 가지 SQL Server 작업을 발생시킬 수도 있습니다. 따라서 테스트에서 측정한 쓰기 횟수는 SQL Server 수준의 쓰기 작업이 아니라 사용자가 일반적으로 생각하는 쓰기 작업을 나타냅니다. 모든 RPS 대 시간당 쓰기 횟수 테스트는 1x1 팜에서 수행되었습니다.

먼저 웹 서버 CPU가 60~80%가 되어 트래픽 급증을 감당할 버퍼가 남아 있을 때까지 테스트에 읽기 작업을 추가했으며 테스트가 끝날 때까지 평균 사용률을 이 수준으로 유지했습니다. 그런 다음 쓰기 작업의 수를 제어하기 위해 인위적 지연을 사용하여 쓰기 작업을 시작했습니다. 그러나 쓰기 작업이 수행되는 동안 웹 서버 및 SQL Server CPU 사용량이 급증했습니다. 다음 차트에서 볼 수 있듯이 일부 캐시 적중률의 경우 트래픽 급증 중 일부는 일반 작업에 대한 임계값을 초과했지만 평균적으로는 일반 작업의 범위에 머물렀습니다.

앞의 차트에서 볼 수 있듯이 환경에 쓰기 작업이 추가됨에 따라 처리량이 다소 감소했습니다. 이 그래프는 읽기 전용 시나리오와 읽기 작업과 동시에 시간당 대략 500회의 쓰기가 수행되는 시나리오 간의 처리량 변화를 보여 줍니다. 각 출력 캐시 적중률에 대해 두 개의 데이터 요소가 기록되었습니다. 따라서 데이터 요소 간의 관계가 반드시 선형은 아닙니다.

다음 차트에서 볼 수 있듯이 캐시 적중률이 낮을 경우 백분율 감소가 더 두드러지게 나타납니다. 총 읽기 RPS는 쓰기에 관계없이 일반적으로 캐시 적중률에 따라 좌우됩니다.

다음 차트에서는 시스템에 쓰기 작업이 추가되었을 때 데이터베이스 서버 CPU 사용률이 크게 증가하지 않았음을 보여 줍니다. 세로 축은 CPU 용량을 0~10%로 나타낸 것입니다.

쓰기 작업 중 추가 SQL Server 부하가 관찰되었으며 이는 예상된 것입니다. 그러나 가장 큰 증가는 추가 2.06%인데 이는 그다지 중요하지 않습니다. 모든 테스트에서 평균 데이터베이스 서버 CPU 사용률은 10% 미만에 머물렀습니다. 이 테스트는 1x1 팜에서 수행되었습니다. 데이터베이스 서버 CPU 사용량은 웹 서버의 수를 수평 확장하면 증가합니다. 이에 대해서는 읽기/쓰기 작업의 수평 확장 특성에 자세히 설명되어 있습니다.

테스트 중 웹 서버 CPU 사용률도 측정되었습니다. 다음 차트에서는 테스트 중 시간당 쓰기 횟수가 500회에 도달했을 때를 포함하여 평균 웹 서버 CPU 사용률이 60~80%로 유지되었음을 보여 줍니다.

그러나 다음 차트에서 볼 수 있듯이 쓰기가 수행될 때는 실제로 측정되는 CPU 사용률이 급증합니다. 일반적으로 이러한 CPU 급증은 특별한 문제를 나타내지 않습니다. 녹색 지대의 목표는 CPU 부하의 급증을 흡수할 CPU 여유 공간을 제공하는 데 있습니다. 또한 웹 서버가 추가됨에 따라 부하 급증이 가져오는 영향이 서버 간에 분산되어 단일 웹 서버 CPU에 미치는 영향이 줄어듭니다. 그러나 실제 배포에서 쓰기 작업이 균일하게 분산되지 않으면 이러한 급증이 발생할 수 있다는 점을 알고 있어야 합니다. 하지만 이러한 CPU 부하 급증은 일반적으로 갑자기 발생하지는 않습니다.

일반적인 배포에서 90%의 캐시 적중률은 매우 낮습니다. 읽기 작업이 많이 수행되는 대부분의 SharePoint Server 2010 배포에서는 출력 캐시 적중률이 95% 이상입니다.

쓰기 작업이 처리량에 가져오는 영향 결론 및 권장 사항

이 문서에 나온 데이터는 독자의 측면에서 쓰기 작업이 시스템의 전반적인 처리량에 그다지 많은 영향을 주지 않음을 보여 줍니다. 쓰기 작업이 CPU 사용량 급증을 야기할 수 있다는 점을 알고 있어야 하며 이러한 급증에 대비할 수 있도록 일반 구성을 계획해야 합니다. 이러한 급증을 평준화하는 전략으로는 여러 웹 서버로 수평 확장하는 방법이 있습니다. 이 경우 다음과 같은 두 가지 장점을 얻을 수 있습니다.

• 쓰기 부하를 여러 웹 서버로 분산하여 전반적인 급증을 완화합니다.

• 특히 출력 캐시 적중률이 높을 때 증가된 읽기 RPS를 제공합니다.

콘텐츠 배포의 영향

편집과 읽기에 단일 환경을 사용하는 전체 제작 모델 대신 제작 환경과 프로덕션 환경이라는 두 개의 별개 환경으로 나누고 콘텐츠 배포를 통해 제작 환경에서 프로덕션 환경으로 콘텐츠를 복사하는 방법을 선택할 수도 있습니다.

이 구성에서는 콘텐츠 배포를 통해 콘텐츠를 가져오는 경우를 제외하고는 쓰기 작업이 거의 또는 전혀 이루어지지 않습니다. 이 테스트에서는 웹 서버 CPU 사용량이 70~80%가 될 때까지 읽기 작업이 추가되었습니다. 그런 다음 콘텐츠 배포 작업을 통해 페이지가 각각 500개가 포함된 10개의 사이트를 패키지로 제작 사이트 모음에서 내보낸 후 이 패키지를 게시 사이트 모음으로 가져왔습니다. 배포된 패키지의 크기는 실제 환경에서 일반적으로 관찰할 수 있는 것보다 컸는데 이는 콘텐츠 배포 작업의 기간을 충분히 늘려 테스트 결과를 확인하기 위해서였습니다. 배포된 콘텐츠의 특성에 대한 자세한 내용은 데이터 집합 섹션을 참조하십시오.

내보내기가 완료된 후 콘텐츠를 별개의 사이트 모음으로 가져오고 가져오기가 진행되는 동안 응용 프로그램 서버와 SQL Server의 부하 및 처리량을 측정했습니다. 가져오기 테스트는 몇 가지 서로 다른 출력 캐시 적중률에서 수행되었습니다.

테스트에서 주로 관찰된 결과는 다음 차트에서 볼 수 있듯이 가져오기 작업이 전반적인 읽기 RPS에 별다른 영향을 주지 않는다는 것입니다. 또한 다음 표에서 볼 수 있듯이 가져오기 작업은 캐시 적중률에 관계없이 웹 서버 CPU 사용률에 별다른 영향을 주지 않음을 알 수 있습니다. 그러나 다음 차트에서 볼 수 있듯이 SQL Server CPU는 좀 더 눈에 띄는 영향을 받습니다. 이는 예상된 것으로, 데이터베이스 서버로 콘텐츠를 가져오는 동안 데이터베이스 서버에서 추가 부하가 발생하기 때문입니다. 그러나 SQL Server CPU 사용량은 가져오기 작업 중에도 테스트된 모든 캐시 적중률에서 12% 이하에 머물렀습니다.

다음 표에서는 콘텐츠 배포 가져오기가 웹 서버 및 데이터베이스 서버 CPU 사용률에 가져오는 영향을 보여 줍니다.

콘텐츠 배포 가져오기가 웹 서버 CPU 사용률에 가져오는 영향

캐시 적중	100%	99%	98%	95%	90%	50%	0%
기준선	72.32%	73.26%	71.28%	73.53%	71.79%	68.05%	63.97%
가져오기를 수행할 경우	70.93%	74.45%	69.56%	74.12%	70.95%	67.93%	63.94%

콘텐츠 배포 가져오기가 데이터베이스 서버 CPU 사용률에 가져오는 영향

캐시 적중	100%	99%	98%	95%	90%	50%	0%
기준선	1.19%	1.64%	2.01%	3.00%	3.73%	5.40%	6.82%
가져오기를 수행할 경우	6.03%	6.82%	6.97%	7.96%	8.52%	10.29%	10.56%

콘텐츠 배포의 영향 결론 및 권장 사항

테스트 결과 일반 사이트 작업 중 콘텐츠 배포 작업을 수행하면 성능에 별다른 영향을 주지 않는다는 점을 알 수 있습니다. 이러한 결과는 콘텐츠 배포 작업이 전반적인 성능에 가져오는 영향을 최소화하기 위해 이 작업을 꼭 트래픽이 적은 시간대에 수행할 필요는 없다는 점과 배포 시간은 성능 요구 사항이 아니라 비즈니스 요구 사항에 따라 결정된다는 사실을 보여 줍니다.

콘텐츠 배포 내보내기 중 데이터베이스 스냅숏이 가져오는 영향

SharePoint Server 2010에서는 원본 콘텐츠 데이터베이스에서 콘텐츠를 내보내기 전에 데이터베이스의 스냅숏을 만들도록 콘텐츠 배포를 구성할 수 있습니다. 이렇게 하면 내보내기 중 발생할 수 있는 제작 작업으로부터 내보내기 프로세스가 효과적으로 보호됩니다. 그러나 스냅숏은 쓰기의 배수로 작동하기 때문에 데이터베이스 서버의 쓰기 성능에 영향을 줄 수 있습니다. 예를 들어 원본 데이터베이스의 스냅숏이 두 개 있는 경우 원본 데이터베이스에 쓰면 데이터베이스 서버에서 각 스냅숏에 기존 데이터를 복사한 다음 새 데이터를 원본 데이터베이스에 씁니다. 이는 원본 데이터베이스에 대한 한 번의 쓰기가 실제로는 세 번의 쓰기를 발생시킨다는 것을 의미합니다. 즉, 원본 데이터베이스에 대해 한 번 그리고 각 데이터베이스 스냅숏에 대해 각각 한 번씩 총 세 번의 쓰기가 수행됩니다.

스냅숏이 제작 환경에 가져오는 영향을 확인하기 위해 내보내기 작업과 쓰기 작업이 동시에 수행되는 동안 웹 서버, 데이터베이스 서버 및 응용 프로그램 서버의 CPU 사용률, 응답 시간 및 쓰기 RPS를 측정했습니다. 다음 표에서는 그 결과를 보여 줍니다.

콘텐츠 배포 내보내기 중 데이터베이스 스냅숏이 가져오는 영향

메트릭	시간당 쓰기 횟수 4회 - 스냅숏을 사용하지 않을 경우	시간당 쓰기 횟수 4회 - 스냅숏을 사용할 경우
쓰기 RPS	0.2	0.16
응답 시간	0.13	0.15
웹 서버 CPU 사용률(%)	0.42%	0.27%
응용 프로그램 서버 CPU 사용률(%)	8.67%	8.98%
데이터베이스 서버 CPU 사용률(%)	3.34%	2.41%

콘텐츠 배포 중 데이터베이스 스냅숏이 가져오는 영향

메트릭	시간당 쓰기 횟수 8회 - 스냅숏을 사용하지 않을 경우	시간당 쓰기 횟수 8회 - 스냅숏을 사용할 경우
쓰기 RPS	0.44	0.44
응답 시간	0.13	0.13
웹 서버 CPU 사용률(%)	0.61%	0.73%
응용 프로그램 서버 CPU 사용률(%)	14.6%	12%
데이터베이스 서버 CPU 사용률(%)	7.04%	7.86%

콘텐츠 배포 내보내기 중 데이터베이스 스냅숏이 가져오는 영향 결론 및 권장 사항

테스트 결과 데이터베이스 스냅숏을 사용해도 측정된 데이터 요소 중 어떤 것에도 별다른 영향을 주지 않는다는 점을 알 수 있습니다. 기록된 모든 차이는 허용되는 오차 한계 내에 있습니다. 따라서 성능을 크게 염려하지 않고 데이터베이스 스냅숏을 사용할 수 있다는 사실을 확실히 알 수 있습니다.

콘텐츠 특성

몇 가지 질문에 대한 답을 제시하기 위해 단일 데이터 집합에 대해 여러 가지 테스트가 수행되었습니다. 데이터 집합은 시간이 경과함에 따라 변화하고 변경됩니다. 이 섹션에서는 페이지 라이브러리의 페이지 수 및 페이지에 포함된 기능과 같은 콘텐츠 특성이 용량 관리와 관련된 결정 사항에 어떤 영향을 주는지 검토합니다.

페이지 수

다양한 페이지 라이브러리 크기에서 최대 RPS가 테스트되었습니다. 이 테스트는 출력 캐싱을 사용하지 않고 익명 액세스를 사용하는 4x1 토폴로지에서 수행되었습니다. 모든 페이지는 압축되지 않았을 때 42KB이고 압축되었을 때 12KB입니다. 다음 표에서는 테스트 결과를 보여 줍니다.

라이브러리 페이지 수가 RPS에 가져오는 영향

페이지 수	3	1,000	20,000
최대 RPS	860	801	790

페이지 수를 20,000개로 늘려도 최대 RPS에 큰 영향이 발생하지 않았습니다.

다중값 조회 필드

다중값 조회 필드는 다른 목록의 항목을 하나 이상 참조하는 목록의 열로, 엔터프라이즈 관리 메타데이터를 사용하는 열을 예로 들 수 있습니다. 이러한 필드는 일반적으로 페이지의 검색 키워드로 사용되며 반드시 렌더링될 필요는 없습니다. 엔터프라이즈 위키와 같은 항목의 경우 이러한 필드 값을 페이지의 콘텐츠에 렌더링하게 됩니다. 예를 들어 페이지를 만들 때 페이지를 범주(예: 뉴스 사이트의 국제 뉴스, 사건/사고 및 스포츠)별로 분류하고 마스터 페이지에는 페이지에 지정된 범주를 사용자에게 표시하는 자리 표시자를 포함할 수 있습니다.

다중값 조회 필드는 페이지가 요청될 때마다 더 많은 데이터를 가져오도록 합니다. 따라서 페이지에 다중값 조회 필드가 많으면 성능에 영향을 줄 수 있습니다.

다음 차트에서는 다중값 조회 필드가 처리량에 가져오는 영향을 보여 줍니다.

다음 차트에서는 다중값 조회 필드가 팜 리소스 사용률에 가져오는 영향을 보여 줍니다.

다중값 조회 필드의 수가 늘어남에 따라 웹 서버와 데이터베이스 서버 간의 네트워크에 영향을 주게 되고 최대 RPS가 감소합니다.

사용 현황 보고의 영향

사용 현황 보고는 관리자가 사이트 사용 통계를 모니터링하는 데 사용할 수 있는 서비스입니다. 사용 현황 보고에 대한 자세한 내용은 Configure usage and health data collection (SharePoint Server 2010)을 참조하십시오.

사용 현황 보고 타이머 작업이 1x1 팜의 최대 RPS에 가져오는 영향을 테스트했습니다. 다음 표에서는 이 테스트의 결과를 보여 줍니다.

사용 현황 로깅이 성능에 가져오는 영향(RPS)

	사용 현황 DB 설정	사용 현황 DB 해제	차이
출력 캐시 설정	3,459	3,463	4
출력 캐시 해제	629	638	9

테스트 결과 사용 현황 로깅을 사용하더라도 읽기 전용 시나리오의 RPS에는 별다른 영향을 주지 않는다는 점을 알 수 있습니다.

저자 정보

Joshua Stickler는 Microsoft의 SharePoint Server 2010 프로그램 관리자입니다.

Tyler Butler는 Microsoft의 SharePoint Server 2010 프로그램 관리자입니다.

Zhi Liu는 Microsoft의 SharePoint Server 2010 테스트 그룹 소프트웨어 개발 엔지니어입니다.

Cheuk Dong은 Microsoft의 SharePoint Server 2010 테스트 그룹 소프트웨어 개발 엔지니어입니다.

Philippe Flamm은 Microsoft의 SharePoint Server 2010 테스트 그룹 소프트웨어 개발 엔지니어입니다.