PerformancePoint Services의 성능 및 용량 요구 사항 예측
적용 대상: SharePoint Server 2010
마지막으로 수정된 항목: 2017-01-18
이 문서에서는 PerformancePoint Services를 사용할 경우 Microsoft SharePoint Server 2010이 실행되는 토폴로지에 발생하는 영향에 대해 설명합니다.
참고
이 문서에 나와 있는 구체적인 용량 및 성능 수치는 실제 환경의 수치와 다릅니다. 여기에 나와 있는 수치는 적절한 규모의 환경을 디자인하기 위한 시작점을 제공하기 위한 것입니다. 초기 시스템 디자인을 완료한 후 구성을 테스트하여 시스템이 사용자 환경의 여러 요소를 지원하는지 여부를 확인하십시오.
이 문서의 내용:
테스트 팜 특성
테스트 결과
권장 사항
SharePoint Server 2010에 대한 용량 계획을 세우고 실행하는 방법에 대한 일반적인 정보는 SharePoint Server 2010의 용량 관리 및 크기 조정을 참조하십시오.
테스트 팜 특성
데이터 집합
데이터 집합은 중간 크기의 단일 대시보드가 들어 있는 PerformancePoint Services 및 SharePoint Server 2010을 사용하여 작성된 회사 포털로 구성되어 있습니다. 대시보드에는 성과 기록표 하나에 연결된 필터 두 개, 차트 두 개 그리고 표 하나가 포함되어 있습니다. 또한 대시보드는 SQL Server 2008 Analysis Services 큐브에 대한 AdventureWorks 예제 데이터베이스를 사용하는 단일 Microsoft SQL Server 2008 Analysis Services(SSAS) 데이터 원본을 기반으로 만들어졌습니다.
아래 표에서는 대시보드에 있는 각 요소의 유형과 크기에 대해 설명합니다.
| 이름 | 설명 | 크기 |
|---|---|---|
필터 1 |
구성원 선택 필터 |
차원 구성원 7개 |
필터 2 |
구성원 선택 필터 |
차원 구성원 20개 |
성과 기록표 |
성과 기록표 |
차원 구성원 행 15개 x 열 4개(KPI 2개) |
차트 1 |
꺾은선형 차트 |
3 계열 x 열 12개 |
차트 2 |
누적 가로 막대형 차트 |
37 계열 x 열 3개 |
표 |
분석 표 |
행 5개 x 열 3개 |
중간 크기의 대시보드에는 머리글 및 두 열 서식 파일이 사용되고 대시보드 항목 크기는 자동 크기 또는 대시보드의 특정 비율로 설정되었습니다. 대시보드의 각 항목은 웹 브라우저 창 크기에서 나타나는 차이를 시뮬레이션하기 위해 400에서 500픽셀 사이의 높이 및 너비로 렌더링되었습니다. 차트가 웹 브라우저 창 크기를 기반으로 하기 때문에 각 대시보드 항목의 높이와 너비를 변경하는 것은 중요합니다.
테스트 시나리오 및 프로세스
이 섹션에서는 테스트 시나리오를 정의하고 각 시나리오에 사용된 테스트 프로세스에 대해 설명합니다. 테스트 결과 및 특정 매개 변수와 같은 자세한 정보는 이 문서 뒷부분에 있는 테스트 결과 섹션에서 제공됩니다.
| 테스트 이름 | 테스트 설명 |
|---|---|
상호 작용 간 15초의 일시 중지 시간을 적용하여 대시보드를 렌더링하고 두 필터 중 하나를 다섯 번 임의로 변경합니다. |
|
상호 작용 간 15초의 일시 중지 시간을 적용하여 대시보드를 렌더링하고 차트를 선택한 다음 확장 및 축소합니다. |
|
상호 작용 간 15초의 일시 중지 시간을 적용하여 대시보드를 렌더링하고 표를 선택한 다음 확장 및 축소합니다. |
|
시작된 테스트 비율이 다음과 같은 단일 테스트 혼합이 사용되었습니다.
| 테스트 이름 | 테스트 혼합 |
|---|---|
다섯 번에 걸쳐 대시보드를 렌더링하고 두 필터 중 하나를 임의로 변경합니다. |
80% |
다섯 번에 걸쳐 대시보드를 렌더링하고 차트를 선택하고 해당 차트를 확장 및 축소합니다. |
10% |
다섯 번에 걸쳐 대시보드를 렌더링하고 표를 선택하고 해당 표를 확장 및 축소합니다. |
10% |
필터를 임의로 변경하고 표와 차트를 탐색하는 사용자를 시뮬레이션하는 일련의 웹 테스트 및 부하 테스트를 만들기 위해 Microsoft Visual Studio 2008 Load Testing 도구가 사용되었습니다. 이 문서에 사용된 테스트에는 상호 작용 사이에 "인지 시간"이라고도 하는 15초의 일시 중지 시간과 15초의 테스트 반복 간 인지 시간에 대한 정규 분포가 포함되어 있습니다. 성과 기록표 또는 보고서를 렌더링할 때 2초의 평균 응답 시간을 생성하도록 부하가 적용되었습니다. 평균 응답 시간은 처음 10분의 준비 기간이 지난 후 15분 동안 측정했습니다.
각각의 새 테스트 반복에서는 5천 개의 계정으로 구성된 풀에서 각기 다른 사용자 계정을 선택하고 약 2,200개의 주소로 구성된 풀에서 임의의 IP 주소(Visual Studio IP Switching 사용)를 선택합니다.
테스트 혼합은 동일한 중간 크기의 대시보드에 대해 두 번 실행되었습니다. 첫 번째 실행에서는 공통된 계정을 사용하여 데이터를 요청하는 무인 서비스 계정을 사용하도록 데이터 원본 인증이 구성되었습니다. 데이터 결과는 여러 사용자에게 동일하며 PerformancePoint Services에서는 캐싱을 사용하여 성능을 개선할 수 있습니다. 두 번째 실행에서는 데이터 원본 인증이 사용자별 ID를 사용하도록 구성되었고 SQL Server Analysis Services 큐브는 동적 보안을 사용하도록 구성되었습니다. 이 구성의 PerformancePoint Services에서는 사용자의 ID를 사용하여 데이터를 요청합니다. 데이터 결과가 다를 수 있으므로 사용자 간에 캐싱을 공유할 수는 없습니다. Analysis Services 동적 보안이 구성되어 있지 않고 Microsoft Windows 사용자 및 그룹에 할당되는 Analysis Services 역할이 동일한 경우 같은 특정한 상황에서는 사용자별 ID에 대한 캐싱을 공유할 수 있습니다.
하드웨어 설정 및 토폴로지
테스트용 하드웨어
자세한 테스트 결과를 제공하기 위해 테스트에 여러 가지 팜 구성이 사용되었습니다. 팜 구성은 1~3개의 웹 서버와 1~4개의 응용 프로그램 서버 그리고 Microsoft SQL Server 2008이 실행되는 단일 데이터베이스 서버로 이루어져 있습니다. 또한 SharePoint Server 2010의 기본 엔터프라이즈 설치를 수행했습니다.
다음 표에는 테스트에 사용된 하드웨어가 나와 있습니다.
| 웹 서버 | 응용 프로그램 서버 | SQL Server가 실행되는 컴퓨터 | Analysis Services가 실행되는 컴퓨터 | |
|---|---|---|---|---|
프로세서 |
프로세서 2개 x 4코어(2.66GHz) |
프로세서 2개 x 4코어(2.66GHz) |
프로세서 2개 x 4코어(2.66GHz) |
프로세서 4개 x 6코어(2.4GHz) |
RAM |
16GB |
32GB |
16GB |
64GB |
운영 체제 |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
NIC |
1x1기가비트 |
1x1기가비트 |
1x1기가비트 |
1x1기가비트 |
인증 |
NTLM 및 Kerberos |
NTLM 및 Kerberos |
NTLM 및 Kerberos |
NTLM 및 Kerberos |
팜을 여러 개의 웹 서버로 수평 확장한 후에는 하드웨어 부하 분산 기능을 통해 원본-주소 선호도를 사용하여 사용자 부하를 여러 웹 서버에 분산했습니다. 원본-주소 선호도에서는 들어오는 요청의 원본 IP 주소와 이러한 요청의 부하가 분산된 서비스 호스트를 기록하며 이후의 모든 트랜잭션을 동일한 호스트로 채널링합니다.
토폴로지
시작 토폴로지는 두 대의 실제 서버, 즉 웹 및 응용 프로그램 서버 역할을 하는 서버 한 대와 데이터베이스 서버로 사용되는 서버 한 대로 구성되어 있습니다. 이 시작 토폴로지는 2M(Two-machine) 토폴로지 또는 "1 x 0 x 1" 토폴로지로 간주되는데, 이 경우 전용 웹 서버의 수가 먼저 나열되고 그 다음이 전용 응용 프로그램 서버 그리고 데이터베이스 서버입니다.
웹 서버는 이 문서 뒷부분에서 웹 프런트 엔드(WFE)라고도 합니다. 부하는 제한 요인이 발생할 때까지 적용되었습니다. 일반적으로 웹 또는 응용 프로그램 서버의 CPU가 제한 요인이었으며 이러한 제한을 해결하기 위해 리소스가 추가되었습니다. 제한 요인과 토폴로지는 무인 서비스 계정 또는 동적 큐브 보안을 사용하는 사용자별 ID의 데이터 원본 인증 구성에 따라 크게 달랐습니다.
테스트 결과
테스트 결과에는 PerformancePoint Services의 용량을 정의하는 데 도움이 되는 세 가지 주요 측정값이 포함되어 있습니다.
| 측정값 | 설명 |
|---|---|
사용자 수 |
Visual Studio에서 보고한 총 사용자 수입니다. |
초당 요청 수(RPS) |
Visual Studio에서 보고한 총 RPS로, 모든 요청과 정적 파일 요청(예: 이미지 및 스타일시트)이 포함됩니다. |
초당 보기 수(VPS) |
PerformancePoint Services에서 렌더링할 수 있는 총 보기 수입니다. 보기는 PerformancePoint Services에서 렌더링하는 모든 필터, 성과 기록표, 표 또는 차트이거나 RenderWebPartContent 또는 CreateReportHtml이 포함된 렌더링 서비스 URL에 대한 웹 요청입니다. CreateReportHtml 및 RenderWebPartContent에 대한 자세한 내용은 PerformancePoint Services RenderingService 프로토콜 사양(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=200609&clcid=0x412)(영문일 수 있음)을 참조하십시오. PerformancePoint Services의 용량 계획을 손쉽게 세우도록 이러한 요청에 대해 IIS 로그를 구문 분석할 수 있습니다. 또한 이 측정값을 사용하면 수치의 대시보드 구성에 대한 의존도가 훨씬 줄어듭니다. 보기가 두 개인 대시보드를 보기가 10개인 대시보드와 비교할 수 있습니다. |
팁
무신 서비스 계정 인증을 사용하도록 구성된 데이터 원본을 사용하는 경우 전용 서버의 비율에 대한 규칙은 PerformancePoint Services가 실행되는 응용 프로그램 서버 두 대당 웹 서버 하나입니다.
팁
사용자별 인증을 사용하도록 구성된 데이터 원본을 사용하는 경우 전용 서버의 비율에 대한 규칙은 PerformancePoint Services가 실행되는 네 대 이상의 응용 프로그램 서버마다 웹 서버 하나입니다.
응용 프로그램 서버가 네 대를 초과하는 토폴로지에서는 Analysis Services 서버에 병목 현상이 발생할 수 있습니다. 이러한 경우에는 Analysis Services의 CPU 및 쿼리 시간을 모니터링하여 Analysis Services를 여러 대의 서버로 수평 확장해야 할지 여부를 결정하는 것이 좋습니다. Analysis Services 서버의 쿼리 시간에 지연이 발생하면 PerformancePoint Services의 평균 응답 시간이 대폭 증가하여 원하는 임계값인 2초를 뛰어넘게 됩니다.
아래 표에는 2~7대의 서버로 수평 확장할 경우 무인 서비스 계정 인증 및 사용자별 인증 모두에 대한 테스트 결과가 요약되어 있습니다. 추가 성능 카운터가 포함된 자세한 결과는 이 문서 뒷부분에 나와 있습니다.
무인 서비스 계정 인증 요약
| 토폴로지(WFE x APP x SQL) | 사용자 | 초당 요청 수(RPS) | 초당 보기 수(VPS) |
|---|---|---|---|
2M(1x0x1) |
360 |
83 |
50 |
3M(1x1x1) |
540 |
127 |
75 |
4M(1x2x1) |
840 |
196 |
117 |
5M(1x3x1) |
950 |
215 |
129 |
6M(2x3x1) |
1,250 |
292 |
175 |
7M(2x4x1) |
1,500 |
346 |
205 |
사용자별 인증 요약
| 토폴로지(WFE x APP x SQL) | 사용자 | 초당 요청 수(RPS) | 초당 보기 수(VPS) |
|---|---|---|---|
2M(1x0x1) |
200 |
47 |
27 |
3M(1x1x1) |
240 |
56 |
33 |
4M(1x2x1) |
300 |
67 |
40 |
5M(1x3x1) |
325 |
74 |
44 |
2M 및 3M 토폴로지
트랜잭션당 하드웨어 비용 및 응답 시간 곡선을 손쉽게 설명하기 위해 2M 및 3M 토폴로지에 대해 최대 사용자 부하까지 네 개의 증가하는 사용자 부하를 적용하여 부하 테스트를 실행했습니다.
무인 서비스 계정 인증
| 사용자 수 | 50 | 150 | 250 | 360 |
|---|---|---|---|---|
평균 WFE/APP CPU |
19.20% |
57.70% |
94.00% |
96.70% |
RPS |
18 |
53 |
83 |
83 |
초당 보기 수 |
10.73 |
31.72 |
49.27 |
49.67 |
평균 응답 시간(초) |
0.12 |
0.15 |
0.38 |
2 |
.png "PPS_CapicityChart1")
사용자별 인증
| 사용자 수 | 50 | 100 | 150 | 200 |
|---|---|---|---|---|
평균 WFE/APP CPU |
30.80% |
61.30% |
86.50% |
93.30% |
RPS |
17 |
32 |
43 |
47 |
초당 보기 수 |
10.3 |
19.32 |
26.04 |
27.75 |
평균 응답 시간(초) |
0.28 |
0.45 |
0.81 |
2 |
.png "PPS_CapicityChart2")
3M(1x1x1) 팜 결과
무인 서비스 계정 인증
| 사용자 수 | 100 | 250 | 400 | 540 |
|---|---|---|---|---|
RPS |
36 |
87 |
124 |
127 |
초당 보기 수 |
21 |
52 |
74 |
75 |
평균 응답 시간(초) |
0.12 |
0.18 |
0.65 |
2 |
평균 WFE CPU |
11% |
28% |
43% |
46% |
SharePoint Server IIS(인터넷 정보 서비스) 작업자 프로세스 W3WP의 최대 WFE 전용 바이트 |
0.7GB |
1.4GB |
2.0GB |
2.4GB |
평균 APP CPU |
25% |
62% |
94% |
95% |
PerformancePoint Services W3WP의 최대 APP 전용 바이트 |
5.9GB10.8GB |
10.8GB |
14.1GB |
14.6GB |
.png "PPS_CapicityChart3")
사용자별 인증
| 사용자 수 | 50 | 120 | 180 | 240 |
|---|---|---|---|---|
RPS |
17 |
39 |
52 |
56 |
초당 보기 수 |
10 |
23 |
31 |
33 |
평균 응답 시간(초) |
0.28 |
0.48 |
0.91 |
2 |
평균 WFE CPU |
5% |
12% |
17% |
19% |
SharePoint Server W3WP의 최대 WFE 전용 바이트 |
0.78GB |
1.3GB |
1.6GB |
1.9GB |
평균 APP CPU |
25% |
57% |
81% |
81% |
PerformancePoint Services W3WP의 최대 APP 전용 바이트 |
19GB |
20.1GB |
20.5GB |
20.9GB |
.png "PPS_CapicityChart4")
무인 서비스 계정 인증에 대한 4M 이상의 결과
4M 토폴로지부터는 성과 기록표 또는 보고서를 렌더링할 때 2초의 평균 응답 시간을 생성하도록 부하를 적용했습니다. 그런 다음 제한 요인(항상 웹 서버 또는 응용 프로그램 서버의 CPU)을 해결하기 위해 별도의 서버를 추가한 다음 테스트 혼합을 다시 실행했습니다. 이 논리는 서버 수가 총 일곱 대에 이를 때까지 반복되었습니다.
| 4M(1x2x1) | 5M(1x3x1) | 6M(2x3x1) | 7M(2x4x1) | |
|---|---|---|---|---|
사용자 수 |
840 |
950 |
1,250 |
1,500 |
RPS |
196 |
216 |
292 |
346 |
초당 보기 수 |
117 |
131 |
175 |
206 |
평균 WFE CPU |
77% |
63% |
54% |
73% |
SharePoint Server W3WP의 최대 WFE 전용 바이트 |
2.1GB |
1.7GB |
2.1GB |
2.0GB |
평균 APP CPU |
83% |
94% |
88% |
80% |
PerformancePoint Services W3WP의 최대 APP 전용 바이트 |
16GB |
12GB |
15GB |
15GB |
사용자별 인증에 대한 4M 이상의 결과
사용자별 인증을 사용하도록 구성된 데이터 원본에 대해서도 동일한 테스트를 반복했습니다. Analysis Services에서 발생시킨 쿼리 지연으로 인해 응용 프로그램 서버를 추가하여 응용 프로그램 네 개로 구성된 서버 토폴로지를 만들어도 PerformancePoint Services에서 지원할 수 있는 초당 사용자 또는 요청 수는 늘어나지 않았습니다.
| 3M(1x1x1) | 4M(1x2x1) | 5M(1x3x1) | 6M(1x4x1) | |
|---|---|---|---|---|
사용자 수 |
240 |
300 |
325 |
325 |
RPS |
56 |
67 |
74 |
74 |
초당 보기 수 |
33 |
40 |
44 |
45 |
평균 WFE CPU |
19% |
24% |
26% |
12% |
SharePoint Server W3WP의 최대 WFE 전용 바이트 |
2.1GB |
1.9GB |
1.9GB |
1.5GB |
평균 APP CPU |
89% |
68% |
53% |
53% |
PerformancePoint Services W3WP의 최대 APP 전용 바이트 |
20GB |
20GB |
20GB |
20GB |
Analysis Services CPU |
17% |
44% |
57% |
68% |
.png "PPS_CapicityChart5")
권장 사항
하드웨어 권장 사항
테스트 표의 메모리 및 프로세서 카운터는 PerformancePoint Services의 설치를 위한 하드웨어 요구 사항을 결정하는 데 사용해야 합니다. 웹 서버의 경우 PerformancePoint Services에서는 권장되는 SharePoint Server 2010 하드웨어 요구 사항을 사용합니다. PerformancePoint Services에서 많은 양의 메모리를 사용하는 경우 응용 프로그램 서버 하드웨어 요구 사항을 변경해야 할 수 있습니다. 이러한 상황은 데이터 원본이 사용자별 인증을 사용하도록 구성되어 있거나 응용 프로그램 서버에서 데이터 원본 제한 시간이 긴 많은 수의 대시보드를 실행하는 경우에 발생합니다.
데이터 서버는 테스트 도중 병목 현상을 발생시키지 않았으며 7M 무인 서비스 계정 인증 대시보드에서 최대 31%의 CPU 사용량을 나타냈습니다. 보고서, 성과 기록표, KPI 등의 PerformancePoint Services 콘텐츠 정의는 SharePoint 목록에 정의되며 PerformancePoint Services를 통해 메모리에 캐시되어 데이터베이스 서버에 발생하는 부하를 줄입니다.
메모리 사용
PerformancePoint Services는 특정 상황에서 많은 양의 메모리를 사용할 수 있으므로 PerformancePoint Services 응용 프로그램 풀의 메모리 사용량을 모니터링하는 일은 중요합니다. PerformancePoint Services에서는 데이터 원본 캐시 수명(기본값 10분)에 대한 Analysis Services 및 다른 데이터 원본 쿼리 결과를 포함하여 여러 항목을 메모리에 캐시합니다. 무인 서비스 계정 인증을 사용하도록 구성된 데이터 원본을 사용하는 경우에는 이러한 쿼리 결과가 한 번만 저장되고 여러 사용자 간에 공유됩니다. 하지만 사용자별 인증 및 Analysis Services 동적 큐브 보안을 사용하도록 구성된 데이터 원본을 사용하는 경우에는 쿼리 결과가 각 보기에 대해 사용자별로 한 번씩(즉, "필터당" 조합) 저장됩니다.
PerformancePoint Services에서 사용하는 기본 캐시 API는 ASP.NET 캐시 API입니다. 이 API를 사용하면 ASP.NET에서 캐시를 관리하고 메모리 제한에 따라 트림이라고도 하는 항목을 제거하여 메모리 부족 오류를 방지하는 중요한 이점을 얻게 됩니다. 기본 메모리 제한은 실제 메모리의 60%입니다. 이러한 제한에 도달한 후 PerformancePoint Services에서는 여전히 보기를 렌더링했지만 ASP.NET에서 캐시된 항목을 제거할 때 잠시 동안 응답 시간이 대폭 증가했습니다.
PerformancePoint Services를 호스팅하는 응용 프로그램 풀의 성능 카운터 "ASP.NET Applications\Cache API Trims"는 메모리 부족으로 인해 발생하는 ASP.NET 캐시 트림을 모니터링하는 데 사용할 수 있습니다. 이 카운터가 0보다 크면 다음 표에서 적용 가능한 해결 방법을 검토하십시오.
| 문제 | 해결 방법 |
|---|---|
응용 프로그램 서버 프로세서의 사용량이 낮고 다른 서비스가 응용 프로그램 서버에서 실행 중입니다. |
실제 메모리를 추가하거나 ASP.NET 캐시의 메모리를 제한합니다. |
응용 프로그램 서버 프로세서의 사용량이 낮고 PerformancePoint Services만 응용 프로그램 서버에서 실행 중입니다. |
허용되는 경우 캐시에서 더 많은 메모리를 사용하도록 ASP.NET 캐시 설정을 구성하거나 메모리를 추가합니다. |
응용 프로그램 서버 프로세서의 사용량이 높습니다. |
다른 응용 프로그램 서버를 추가합니다. |
사용자의 Analysis Services 역할 구성원 자격 집합이 동일하고 동적 큐브 보안이 구성되어 있지 않은 경우 사용자별 인증을 사용하도록 구성된 데이터 원본에서는 쿼리 결과 및 캐시 항목을 공유할 수 있습니다. 이는 Microsoft SharePoint Server 2010의 PerformancePoint Services의 새로운 기능입니다. 예를 들어 사용자 A가 역할 1 및 2에 있고 사용자 B가 역할 1 및 2에 있으며 사용자 C가 역할 1, 2 및 3에 있으면 사용자 A와 B만 캐시 항목을 공유할 수 있습니다. 동적 큐브 보안이 있는 경우 사용자 A와 B 그리고 사용자 C는 캐시 항목을 공유하지 못합니다.
Analysis Services
PerformancePoint Services를 사용자별 인증으로 테스트할 때 다중 사용자 처리량 성능을 개선하도록 두 개의 Analysis Services 속성을 변경했습니다. 다음 표에서는 변경한 속성과 각 속성의 새 값을 보여 줍니다.
| Analysis Services 속성 | 값 |
|---|---|
Memory\HeapTypeForObjects |
0 |
Memory\MemoryHeapType |
2 |
이러한 두 메모리 설정은 Analysis Services에서 Analysis Services 힙 대신 Windows 힙을 사용하도록 구성합니다. 이러한 속성을 변경하기 전에 사용자 부하를 추가하자 웹, 응용 프로그램 및 Analysis Services 서버의 CPU는 낮게 유지되면서 응답 시간이 0.2초에서 30초 이상으로 대폭 증가했습니다. 문제 해결을 위해 Analysis Services DMV(Dynamic Management Wiew)를 사용하여 쿼리 시간을 수집한 결과 개별 쿼리 시간이 10밀리초에서 5,000밀리초로 증가한 것으로 나타났습니다. 이러한 결과로 인해 위의 메모리 설정을 수정하게 되었습니다.
Analysis Services 팀에 따르면 이러한 설정을 수정하면 처리량이 대폭 증가하지만 단일 사용자 쿼리에 작지만 무시할 수 없는 손실이 발생한다고 합니다.
Analysis Services 속성을 변경하기 전에는 SQL Server 2008 백서: Analysis Services 성능 가이드(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x412)(영문일 수 있음)를 참조하여 다중 사용자 처리량 성능을 개선하기 위한 최상의 방법을 확인하십시오.
일반적인 병목 현상 및 원인
성능 테스트를 수행하는 동안 여러 가지 일반적인 병목 현상이 발견되었습니다. 병목 현상은 팜의 특정 구성 요소가 용량 한도에 도달한 상황을 의미합니다. 이로 인해 팜 처리량이 더 이상 늘어나지 않거나 줄어들게 됩니다. 높은 프로세서 사용률이 병목 현상으로 나타나는 경우 이를 해결하기 위해 서버를 추가했습니다. 다음 표에서는 프로세서 사용률이 낮으며 병목 현상이 아니라는 가정하에 몇 가지 일반적인 병목 현상과 적용 가능한 해결 방법을 소개하고 있습니다.
| 발생 가능한 병목 현상 | 원인 및 모니터링 항목 | 해결 방법 |
|---|---|---|
Analysis Services 메모리 힙 성능 |
기본적으로 Analysis Services에서는 Windows 힙 대신 고유한 메모리 힙을 사용하므로 다중 사용자 처리량 성능이 열악합니다. DMV를 사용하는 Analysis Services 쿼리 시간을 검토하여 사용자 부하로 인해 쿼리 시간이 증가하며 Analysis Services 프로세서 사용률이 낮은지 확인하십시오. |
Analysis Services에서 Windows 힙을 사용하도록 변경합니다. 자세한 내용은 이 문서 앞부분의 "Analysis Services" 섹션과 SQL Server 2008 백서: Analysis Services 성능 가이드(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x412)(영문일 수 있음)를 참조하십시오. |
Analysis Services 쿼리 및 처리 스레드 |
기본적으로 Analysis Services에서는 쿼리 및 쿼리에 대한 처리 스레드의 수를 제한합니다. 실행 시간이 긴 쿼리와 높은 사용자 부하는 사용 가능한 모든 스레드를 사용할 수 있습니다. MSAS 2008:Threads 범주에 속하는 유휴 스레드 및 작업 큐 성능 카운터를 모니터링하십시오. |
쿼리 및 프로세스에서 사용할 수 있는 스레드의 수를 늘립니다. 자세한 내용은 SQL Server 2008 백서: Analysis Services 성능 가이드(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x412)(영문일 수 있음)의 "Analysis Services" 섹션을 참조하십시오. |
응용 프로그램 서버 메모리 |
PerformancePoint Services에서는 데이터 원본 캐시 수명 동안 Analysis Services 및 다른 데이터 원본 쿼리 결과를 메모리에 캐시합니다. 이러한 항목에서는 많은 양의 메모리를 사용할 수 있습니다. PerformancePoint Services 응용 프로그램 풀의 ASP.NET Applications\Cache API Trims를 모니터링하여 부족한 메모리로 인해 ASP.NET에서 캐시 제거 또는 트림을 강제로 적용하는지 여부를 확인합니다. |
메모리를 추가하거나 기본 ASP.NET 캐시 메모리 제한을 늘립니다. 자세한 내용은 이 문서 앞부분의 메모리 사용 섹션을 참조하십시오. 또한 caching 요소에 대한 cache 요소(ASP.NET 설정 스키마)(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=200610&clcid=0x412)(영문일 수 있음) 및 Thomas Marquardt의 블로그 게시물인 ASP.NET 캐시 메모리 제한과 관련된 몇 가지 역사(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=200611&clcid=0x412)(영문일 수 있음)를 참조하십시오. |
WCF 제한 설정 |
PerformancePoint Services는 WCF 서비스로 구현됩니다. WCF 제한은 서비스 제한 동작으로 나타낸 최대 동시 호출 수입니다. 장시간 실행되는 쿼리는 이 병목 현상에 도달할 수 있지만 이는 일반적이지 않은 병목 현상입니다. PerformancePoint Services에 대해 발생한 WCF/Service Model 성능 카운터 호출을 모니터링하고 현재 최대 동시 호출 수와 비교하십시오. |
필요한 경우 WCF(Windows Communication Foundation) 제한 동작을 변경합니다. 자세한 내용은 WCF 서비스 제한 동작(https://go.microsoft.com/fwlink/?linkid=200612&clcid=0x412) 및 Wenlong Dong의 블로그 게시물인 WCF 요청 제한 및 서버 확장성(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x412)(영문일 수 있음)을 참조하십시오. |
성능 모니터링
시스템을 수직 또는 수평 확장해야 할 시기를 파악하려면 성능 카운터를 사용하여 시스템 상태를 모니터링합니다. PerformancePoint Services는 ASP.NET WCF 서비스이며 다른 모든 ASP.NET WCF 서비스를 모니터링하는 데 사용되는 것과 동일한 성능 카운터를 사용하여 모니터링할 수 있습니다. 또한 다음 표의 정보를 활용하여 모니터링할 보조 성능 카운터와 성능 카운터를 적용할 프로세스를 확인하십시오.
| 성능 카운터 | 카운터 인스턴스 | 참고 |
|---|---|---|
ASP.NET Applications/Cache API Trims |
PerformancePoint Services 응용 프로그램 풀 |
값이 0보다 크면 "메모리 사용"을 검토하십시오. |
MSAS 2008:Threads/Query pool idle threads |
해당 없음 |
값이 0이면 SQL Server 2008 백서: Analysis Services 성능 가이드(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x412)(영문일 수 있음)의 "Analysis Services" 섹션을 참조하십시오. |
MSAS 2008:Threads/Query pool job queue length |
해당 없음 |
값이 0보다 크면 SQL Server 2008 백서: Analysis Services 성능 가이드(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x412)(영문일 수 있음)의 "Analysis Services" 섹션을 참조하십시오. |
MSAS 2008:Threads/Processing pool idle threads |
해당 없음 |
값이 0보다 크면 SQL Server 2008 백서: Analysis Services 성능 가이드(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x412)(영문일 수 있음)의 "Analysis Services" 섹션을 참조하십시오. |
MSAS 2008:Threads/Processing pool job queue length |
해당 없음 |
값이 0보다 크면 Analysis Services 성능 가이드(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x412)(영문일 수 있음)의 "Analysis Services" 섹션을 참조하십시오. |
WCF CountersServiceModelService 3.0.0.0(*)\Calls Outstanding |
PerformancePoint Service 인스턴스 |
값이 0보다 크면 WCF 요청 제한 및 서버 확장성(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x412)(영문일 수 있음)을 참조하십시오. |