評估 PerformancePoint Services 的效能與容量需求
適用版本： SharePoint Server 2010
上次修改主題的時間： 2017-01-18
本文說明使用 PerformancePoint Services 對執行 Microsoft SharePoint Server 2010 之拓撲的影響。
注意
請注意，本文中所呈現的特定容量與效能數據，會和實際工作環境中所使用的數據不同。所呈現的數據主要是做為設計一個可適當延展環境之起點。在完成初始系統設計之後，請測試設定，判斷系統是否支援環境中各項因素。
本文內容：
測試伺服器陣列特性
測試結果
建議
如需如何規劃與為 SharePoint Server 2010 執行容量規劃的一般資訊，請參閱＜Capacity management and sizing for SharePoint Server 2010＞。
測試伺服器陣列特性
資料集
資料集是由使用 SharePoint Server 2010 和 PerformancePoint Services 所建立的公司入口網站所組成，內含一個中型儀表板。此儀表板包含兩個篩選，連結至一個計分卡、兩個圖表及一個方格；並依據 SQL Server 2008 Analysis Services Cube 之 AdventureWorks 範例資料庫的單一 Microsoft SQL Server 2008 Analysis Services (SSAS) 資料來源
下表說明儀表板上每個元素的類型及大小。
| Name | 描述 | 大小 |
|---|---|---|
篩選 1 |
成員選取篩選 |
7 個維度成員 |
篩選 2 |
成員選取篩選 |
20 個維度成員 |
計分卡 |
計分卡 |
15 個維度成員資料列乘以 4 個資料行 (2 個 KPI) |
圖表 1 |
折線圖 |
3 個數列乘以 12 個資料行 |
圖表 2 |
堆疊橫條圖 |
37 個數列乘以 3 個資料行 |
方格 |
分析方格 |
5 個資料列乘以 3 個資料行 |
中型儀表板使用「頁首及兩個資料行」範本，且儀表板項目大小設為自動調整大小或儀表板的特定百分比。儀表板上的每個項目會以介於 400 至 500 像素的隨機高度與寬度轉譯，以模擬網頁瀏覽器視窗大小的差異。由於圖表是根據網頁瀏覽器視窗大小所轉譯，因此請務必變更每個儀表板項目的高度與寬度。
測試案例及程序
本節定義測試案例，並討論每個案例所使用的測試程序。本文稍後的＜測試結果＞一節將提供測試結果及特定參數等詳細資訊。
| 測試名稱 | 測試描述 |
|---|---|
轉譯儀表板並隨機變更兩個篩選之一，共進行五次，且互動間暫停 15 秒。 |
|
轉譯儀表板、選取圖表，然後予以展開及摺疊，共進行五次，且互動間暫停 15 秒。 |
|
轉譯儀表板、選取方格，然後予以展開及摺疊，共進行五次，且互動間暫停 15 秒。 |
|
使用單一測試混合，其中包含以下啟動的測試百分比。
| 測試名稱 | 測試混合 |
|---|---|
轉譯儀表板並隨機變更兩個篩選之一，共進行五次。 |
80% |
轉譯儀表板、選取圖表，然後予以展開及摺疊，共進行五次。 |
10% |
轉譯儀表板、選取方格，然後予以展開及摺疊，共進行五次。 |
10% |
Microsoft Visual Studio 2008 負載測試工具可用以建立一組 Web 測試及負載測試，以模擬使用者隨機變更篩選及在方格和圖表上瀏覽。本文中所使用的測試包含互動間暫停 15 秒 (又稱為「考慮時間」)，以及測試反覆項目間的 15 秒考慮時間之常態分佈。套用負載後，會產生兩秒平均回應時間，以轉譯計分卡或報表。平均回應時間的測量方式，是依據初始 10 分鐘熱身時間後的 15 分鐘期間。
每個新測試反覆項目會從內含五千個帳戶的集區中，選取不同的使用者帳戶，並從內含約 2,200 個位址的集區中，選取一個隨機 IP 位址 (使用 Visual Studio IP 切換)。
系統會對相同的中型儀表板執行兩次測試混合。第一次執行時，資料來源驗證設定為使用自動服務帳戶，此驗證使用公用帳戶要求資料。多位使用者會有相同的資料結果，且 PerformancePoint Services 可以使用快取改善效能。第二次執行時，資料來源驗證設定為使用每個使用者的識別，且 SQL Server Analysis Services Cube 設定為使用動態安全性。在此設定中，PerformancePoint Services 使用使用者的識別要求資料。由於資料結果可能不同，因此使用者無法共用快取。在特定情況下，如果未設定 Analysis Services 動態安全性，且指派給 Microsoft Windows 使用者及群組的 Analysis Services 角色相同，則可以共用每個使用者識別的快取。
硬體設定及拓撲
實驗室硬體
為提供高階測試結果詳細資料，使用了數個伺服器陣列設定進行測試。伺服器陣列測試的範圍可以是一至三部網頁伺服器、一至四部應用程式伺服器，以及執行 Microsoft SQL Server 2008 的單一資料庫伺服器。已執行 SharePoint Server 2010 的預設企業安裝。
下表列出用於測試的特定硬體。
| 網頁伺服器 | 應用程式伺服器 | 執行 SQL Server 的電腦 | 執行 Analysis Services 的電腦 | |
|---|---|---|---|---|
處理器 |
2px4c @ 2.66 GHz |
2px4c @ 2.66 GHz |
2px4c @ 2.66 GHz |
4px6c @ 2.4 GHz |
RAM |
16 GB |
32 GB |
16 GB |
64 GB |
作業系統 |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
NIC |
1x1 GB |
1x1 GB |
1x1 GB |
1x1 GB |
驗證 |
NTLM 和 Kerberos |
NTLM 和 Kerberos |
NTLM 和 Kerberos |
NTLM 和 Kerberos |
將伺服器陣列擴充為多部網頁伺服器之後，會使用硬體負載平衡器透過「來源位址相關性」來平衡多部網頁伺服器上的使用者負載。來源位址相關性記錄連入要求的來源 IP 位址及平衡負載的目標服務主機，並將未來所有交易導向相同的主機。
拓撲
起始拓撲是由兩部實體伺服器所組成，其中一部伺服器做為網頁伺服器暨應用程式伺服器，第二部伺服器做為資料庫伺服器。起始拓撲可視為兩部機器 (2M) 拓撲，或「1 x 0 x 1」拓撲，其中會先列出專用網頁伺服器的數目，再依序列出專用應用程式伺服器及資料庫伺服器的數目。
網頁伺服器在本文件稍後又稱為 Web 前端 (WFE)。負載會一直套用至發生限制因素為止。一般而言，網頁伺服器或應用程式伺服器上的 CPU 即為限制因素，在這之後，會新增資源以解決該限制。限制因素及拓撲會隨資料來源驗證設定是自動服務帳戶或搭配動態 Cube 安全性的每個使用者識別，而有顯著的不同。
測試結果
測試結果包含三個重要量值，可協助定義 PerformancePoint Services 容量。
| 測量 | 描述 |
|---|---|
使用者人數 |
Visual Studio 報告的使用者總人數。 |
每秒要求數目 (RPS) |
Visual Studio 報告的 RPS 總計，包含所有要求及靜態檔案要求 (例如影像和樣式表)。 |
每秒檢視次數 (VPS) |
PerformancePoint Services 可以轉譯的檢視數總計。檢視是 PerformancePoint Services 所轉譯的任何篩選、計分卡、方格或圖表，或包含 RenderWebPartContent 或 CreateReportHtml 之任何對轉譯服務 URL 的 Web 要求。若要深入瞭解 CreateReportHtml 和 RenderWebPartContent，請參閱 PerformancePoint Services RenderingService 通訊協定規格(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=200609&clcid=0x404)(可能為英文網頁)。 您可以剖析這些要求的 IIS 記錄，以協助規劃 PerformancePoint Services 的容量。此外，使用此方法提供一個比較不依賴儀表板組合的數字。具有兩個檢視的儀表板可以與具有 10 個檢視的儀表板進行比較。 |
提示
當您使用設定為使用自動服務帳戶驗證的資料來源時，專用伺服器的比例規則是一部網頁伺服器比兩部執行 PerformancePoint Services 的應用程式伺服器。
提示
當您使用設定為使用每個使用者驗證的資料來源時，專用伺服器的比例規則是一部網頁伺服器比四部 (含) 以上之執行 PerformancePoint Services 的應用程式伺服器。
在大於四部應用程式伺服器的拓撲中，Analysis Services 伺服器可能成為瓶頸。請考慮監視 Analysis Services 伺服器的 CPU 及查詢時間，以判斷是否應該將 Analysis Services 擴充為多部伺服器。Analysis Services 伺服器上若有任何查詢時間延遲，都會大幅增加 PerformancePoint Services 的平均回應時間，而遠超過所需的兩秒臨界值。
下表顯示從兩部伺服器擴充為七部伺服器時，自動服務帳戶驗證與每個使用者驗證的測試結果摘要。本文件稍後提供內含其他效能計數器的詳細結果。
自動服務帳戶驗證摘要
| 拓撲 (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 Internet Information Services (IIS) 工作者處理序 W3WP 的最大 WFE 私用位元組。 |
0.7 GB |
1.4 GB |
2.0 GB |
2.4 GB |
平均 APP CPU |
25% |
62% |
94% |
95% |
PerformancePoint Services W3WP 的最大 APP 私用位元組 |
5.9 GB 10.8 GB |
10.8 GB |
14.1 GB |
14.6 GB |
.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.78 GB |
1.3 GB |
1.6 GB |
1.9 GB |
平均 APP CPU |
25% |
57% |
81% |
81% |
PerformancePoint Services W3WP 的最大 APP 私用位元組 |
19 GB |
20.1 GB |
20.5 GB |
20.9 GB |
.png "PPS_CapicityChart4")
自動服務帳戶驗證的 4M+ 結果
從 4M 拓撲開始，套用負載後，會產生兩秒平均回應時間，以轉譯計分卡或報表。接著會新增其他伺服器以解決限制因素 (一律是網頁伺服器或應用程式伺服器上的 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.1 GB |
1.7 GB |
2.1 GB |
2.0 GB |
平均 APP CPU |
83% |
94% |
88% |
80% |
PerformancePoint Services W3WP 的最大 APP 私用位元組 |
16 GB |
12 GB |
15 GB |
15 GB |
每個使用者驗證的 4M+ 結果
使用每個使用者驗證的資料來源會重複相同測試。請注意，新增應用程式伺服器以建立四部應用程式伺服器拓撲，並無法增加 PerformancePoint Services 可支援的使用者人數或每秒要求數目，因為 Analysis 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.1 GB |
1.9 GB |
1.9 GB |
1.5 GB |
平均 APP CPU |
89% |
68% |
53% |
53% |
PerformancePoint Services W3WP 的最大 APP 私用位元組 |
20 GB |
20 GB |
20 GB |
20 GB |
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 動態 Cube 安全性的資料來源時，每次使用者檢視一次查詢結果，即會儲存一次 (亦即「依據篩選」組合)。
PerformancePoint Services 使用的基礎快取 API 是 ASP.NET 快取 API。使用此 API 的明顯優點是 ASP.NET 會根據記憶體限制管理快取及移除項目 (又稱為修剪)，以免發生記憶體不足的錯誤。預設記憶體限制為實體記憶體的 60%。達到此限制後，在 ASP.NET 移除快取的項目時，PerformancePoint Services 仍可暫時轉譯檢視，但是回應時間會大幅增加。
主控 PerformancePoint Services 之應用程式集區的效能計數器 "ASP.NET Applications \ Cache API Trims"，可用來監視由於記憶體嚴重不足所發生的 ASP.NET 快取修剪。如果此計數器大於零，請檢閱下表以取得可能的解決方法。
| 問題 | 解決方案 |
|---|---|
應用程式伺服器處理器使用量很低，且應用程式伺服器上有其他服務正在執行。 |
增加更多實體記憶體或限制 ASP.NET 快取的記憶體。 |
應用程式伺服器處理器使用量很低，且應用程式伺服器上只有 PerformancePoint Services 正在執行。 |
如果可以接受，請設定 ASP.NET 快取設定讓快取使用更多記憶體，或增加更多記憶體。 |
應用程式伺服器處理器使用量很高。 |
新增其他應用程式伺服器。 |
如果使用者的 Analysis Services 角色成員資格集相同，且未設定動態 Cube 安全性，則設定為使用每個使用者驗證的資料來源可以共用查詢結果及快取項目。這是 Microsoft SharePoint Server 2010 的 PerformancePoint Services 的新功能。例如，若使用者 A 的角色為 1 和 2、使用者 B 的角色為 1 和 2，而使用者 C 的角色為 1、2 及 3，只有使用者 A 和使用者 B 可以共用快取項目。如果使用動態 Cube 安全性，使用者 A、B 及 C 則無法共用快取項目。
Analysis Services
使用每個使用者驗證測試 PerformancePoint Services 時，會變更兩個 Analysis Services 屬性以改善多位使用者的輸送量效能。下表顯示變更的屬性及每個屬性的新值。
| Analysis Services 屬性 | 值 |
|---|---|
Memory \ HeapTypeForObjects |
0 |
Memory \ MemoryHeapType |
2 |
這兩個記憶體設定會將 Analysis Services 設定為使用 Windows 堆積，而不是 Analysis Services 堆積。變更這些屬性之前，以及增加使用者負載期間，回應時間會從 0.2 秒大幅增加為 30 秒以上，但是網頁伺服器、應用程式伺服器及 Analysis Services 伺服器上的 CPU 仍維持很低。為了進行疑難排解，使用 Analysis Services 動態管理檢視 (DMV) 所收集的查詢時間顯示，個別查詢時間從 10 毫秒增加為 5000 毫秒。這些結果會導致修改以上記憶體設定。
請務必注意，雖然這會大幅改善輸送量，但是根據 Analysis Services 小組，變更這些設定會對單一使用者查詢造成雖小但值得注意的成本。
變更任何 Analysis Services 屬性之前，請參閱 SQL Server 2008 白皮書：Analysis Services 效能指南(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x404)(可能為英文網頁)，以取得改善多位使用者輸送量效能的最佳作法。
常見瓶頸及其原因
在效能測試期間，會發現幾個常見的瓶頸。瓶頸是伺服器陣列特定區域的容量已滿的情況。這會導致伺服器陣列輸送量停滯或降低。如果發生處理器使用量很高的瓶頸，請新增其他伺服器以解決瓶頸。下表列出一些常見的瓶頸及可能的解決方法，其中假設處理器使用量很低而不構成瓶頸。
| 潛在瓶頸 | 原因及監視內容 | 解決方式 |
|---|---|---|
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=0x404)(可能為英文網頁)。 |
Analysis Services 查詢及處理執行緒 |
Analysis Services 預設會限制查詢數目及查詢的處理執行緒數目。長時間執行的查詢及高使用者負載可能會使用所有可用的執行緒。請依據 MSAS 2008:Threads 類別，監視閒置執行緒及工作佇列效能計數器。 |
增加查詢及處理序可用的執行緒數目。如需相關指示，請參閱 SQL Server 2008 白皮書：Analysis Services 效能指南(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x404)(可能為英文網頁) 的＜Analysis Services＞一節。 |
應用程式伺服器記憶體 |
PerformancePoint Services 會在資料來源快取週期期間，從記憶體快取 Analysis Services 及其他資料來源查詢結果。這些項目可能會耗用大量記憶體。請監視 PerformancePoint Services 應用程式集區的 ASP.NET Applications \ Cache API Trims，以判斷是否由於記憶體不足，已由 ASP.NET 強制移除或修剪快取。 |
增加記憶體，或增加預設 ASP.NET 快取記憶體限制。如需其他討論，請參閱本文件稍早的＜記憶體耗用量＞一節。另請參閱 ASP.NET 快取項目設定(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=200610&clcid=0x404)(可能為英文網頁)，以及 Thomas Marquardt 的部落格文章：ASP.NET 快取記憶體限制的一些歷史(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=200611&clcid=0x404)(可能為英文網頁)。 |
WCF 節流設定 |
PerformancePoint Services 會實作為 WCF 服務。WCF 將同時呼叫的最大值限制為服務節流行為。雖然長時間執行的查詢可能會達到此瓶頸，但是並不常見。請監視 PerformancePoint Services 特別大量的 WCF / Service Model 效能計數器呼叫，並且與目前同時呼叫的最大值進行比較。 |
請視需要變更 Windows Communication Foundation (WCF) 節流行為。請參閱 WCF 服務節流行為 (https://go.microsoft.com/fwlink/?linkid=200612&clcid=0x404)，以及 Wenlong Dong 的部落格文章：WCF 要求節流及伺服器延展性(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x404)(可能為英文網頁)。 |
效能監視
為協助決定何時必須向上擴充或向外擴充系統，請使用效能計數器監視系統健康狀態。PerformancePoint Services 是 ASP.NET WCF 服務，可透過用於監視其他任何 ASP.NET WCF 服務的相同效能計數器進行監視。此外，請使用下表中的資訊，以判斷所要監視的輔助效能計數器，以及應該套用效能計數器的處理序。
| 效能計數器 | 計數器執行個體 | 附註 |
|---|---|---|
ASP.NET Applications / Cache API Trims |
PerformancePoint Services 應用程式集區 |
如果值大於零，請檢閱＜記憶體耗用量＞。 |
MSAS 2008:Threads / Query pool idle threads |
無 |
如果值等於零，請檢閱 SQL Server 2008 白皮書：Analysis Services 效能指南(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x404)(可能為英文網頁) 的＜Analysis Services＞一節。 |
MSAS 2008:Threads / Query pool job queue length |
無 |
如果值大於零，請檢閱 SQL Server 2008 白皮書：Analysis Services 效能指南(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x404)(可能為英文網頁) 的＜Analysis Services＞一節。 |
MSAS 2008:Threads / Processing pool idle threads |
無 |
如果值大於零，請檢閱 SQL Server 2008 白皮書：Analysis Services 效能指南(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x404)(可能為英文網頁) 的＜Analysis Services＞一節。 |
MSAS 2008:Threads / Processing pool job queue length |
無 |
如果值大於零，請檢閱 SQL Server 2008 白皮書：Analysis Services 效能指南(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x404)(可能為英文網頁) 的＜Analysis Services＞一節。 |
WCF CountersServiceModelService 3.0.0.0(*)\Calls Outstanding |
PerformancePoint Service 執行個體 |
如果值大於零，請參閱 WCF 要求節流及伺服器延展性(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x404)(可能為英文網頁)。 |