評估 SharePoint Server 2010 中 Access Services 的效能與容量規劃
適用版本： SharePoint Server 2010 Enterprise
上次修改主題的時間： 2016-11-30
本文指示的 Microsoft SharePoint Server 2010 的 Access Services 使用是在執行 Microsoft SharePoint Server 2010 的拓撲之上。
本文內容：
測試伺服器陣列特性
測試結果
建議
疑難排解
測試伺服器陣列特性
本節說明測試期間所使用的資料集；收集效能期間產品的工作量；測試期間所使用的硬體；以及硬體部署方式的拓撲。
資料集
Access Services 的容量和效能與服務主控的應用程式架構高度相關。資料表的大小和查詢的複雜性通常對容量和效能的影響最大。本測試使用代表性的大小和複雜性，但是每一個應用程式和資料集均不同。容量和效能取決於使用的應用程式、其特定複雜性及資料大小。
為了評估容量設定檔，會在 Access Services 專用的伺服器陣列 (未執行其他任何 SharePoint 測試) 上模擬 Access Services 應用程式。此伺服器陣列包含下列代表性網站：
1,500 個 Access Services 應用程式，其設定檔大小為「小」；每個清單最多 100 個項目。
1,500 個 Access Services 應用程式，其設定檔大小為「中」；每個清單最多 2,000 個項目。
1,500 個 Access Services 應用程式，其設定檔大小為「大」；每個清單最多 10,000 個項目。
每個應用程式是由多個清單所組成，其他清單會隨此最大清單適當調整大小。Access Services 可以處理比 10,000 個項目更多的資料。「大」設定檔之所以選擇此數目，是因為更大的應用程式應該不常見。
這些應用程式會平均分散至下列應用程式：
連絡人 由單一清單控制的簡單連絡人管理應用程式。
專案 由兩個清單 (每個專案相關聯的專案和工作) 控制的簡單工作和專案追蹤應用程式。
訂單 簡單的訂單輸入系統，類似 Microsoft Access 的北風貿易範例，但是規模較小，且包含許多相互關聯的清單 (訂單、訂單詳細資料、發票、發票詳細資料、採購單、採購單詳細資料等)。
工作量
為了模擬應用程式使用量，我們建立了工作量，以執行下列一或多個作業：
開啟表單
分頁表單
篩選及排序資料工作表
更新、刪除及插入記錄
發佈應用程式
轉譯報表
每個工作量在使用者動作之間含有 5 至 20 秒的「考慮時間」。這與其他 SharePoint 容量規劃文件不同。Access Services 為可設定狀態；使用者互動之間會維護記憶體游標和記錄集。您必須模擬完整的使用者工作階段，而不僅是個別要求。單一使用者工作量每秒平均有兩個要求。
下表顯示用來決定要使用之應用程式和應用程式大小的百分比。
| 小 | 中 | 大 | |
|---|---|---|---|
連絡人 |
16% |
10% |
9% |
專案 |
18% |
12% |
10% |
訂單 |
11% |
8% |
6% |
綠色和紅色區域定義
每個設定會執行兩個測試，以決定「綠色區域」和「紅色區域」。綠色區域是建議可以維持的輸送量。紅色區域是短時間可容許的最大輸送量，但應該避免。
綠色區域會定義為執行的測試最多使用瓶頸資源一半的臨界點。在此情況下，瓶頸資源為下列三層任一層的 %CPU：前端網頁伺服器、應用程式伺服器 (Access Data Services) 或資料庫伺服器 (SQL Server)。首先會識別特定設定的瓶頸。如果瓶頸為 Access Data Services CPU，請確定綠色區域測試所使用的 Access Data Services 電腦 CPU 介於 40% 和 50% 範圍之間。
針對紅色區域，其臨界點會選在達到最大輸送量時。結果是介於 80% 和 90% 的 CPU 範圍之間。搜尋瓶頸時，會檢視 %CPU、記憶體使用量 (私用位元組)、磁碟佇列長度、網路 I/O，以及其他可能導致瓶頸的資源。
綠色和紅色區域測試在固定使用者負載下會執行 1 小時。
您的結果可能會不同
本文中所呈現的特定容量與效能數據，會和實際工作環境中所使用的數據不同。此模擬不過是實際使用者可能執行的作業預估。所呈現的數據主要是做為開始設計可適當調整的環境適用的最初依據。在完成初始系統設計之後，您應該測試設定，判斷系統是否支援環境中各項因素。
硬體設定及拓撲
實驗室硬體
為提供高階測試結果詳細資料，測試使用了數個伺服器陣列設定。伺服器陣列設定的範圍可以是一至四部網頁伺服器、一至四部應用程式伺服器 (如有 Access Services 或 Access Data Services)，以及執行 Microsoft SQL Server 2008 的單一資料庫伺服器電腦。此外，測試會透過四部用戶端電腦來執行。所有伺服器電腦均為 64 位元，而所有用戶端電腦則是 32 位元。
下表列出用於測試的特定硬體。
| 機器角色 | CPU | 記憶體 | 網路 | 磁碟 |
|---|---|---|---|---|
前端網頁伺服器 |
雙處理器、4 核心 2.33 GHz |
8 GB |
1 GB |
雙主軸 RAID 5 |
應用程式伺服器 (Access Data Services) |
雙處理器、4 核心 2.33 GHz |
8 GB |
1 GB |
雙主軸 RAID 5 |
資料庫伺服器 (SQL Server) |
4 處理器、4 核心 2.6 GHz |
32GB |
1 GB |
每個邏輯單位編號 (LUN) 的直接連接儲存裝置 (DAS) 附加 RAID 0 |
拓撲
根據經驗，Access Data Services 執行所在之應用程式伺服器層的 CPU 是輸送量的重要限制因素。透過新增額外的 Access Data Services 電腦來改變拓撲，直到其不再是瓶頸為止，然後新增前端網頁伺服器以取得更多輸送量。
**1x1：**一部前端網頁伺服器電腦對一部 Access Data Services 電腦
**1x2：**一部前端網頁伺服器電腦對兩部 Access Data Services 電腦
**1x3：**一部前端網頁伺服器電腦對三部 Access Data Services 電腦
**1x4：**一部前端網頁伺服器電腦對四部 Access Data Services 電腦
**2x1：**兩部前端網頁伺服器電腦對一部 Access Data Services 電腦
**2x2：**兩部前端網頁伺服器電腦對兩部 Access Data Services 電腦
**2x4：**兩部前端網頁伺服器電腦對四部 Access Data Services 電腦
執行 SQL Server 的電腦是比較強固的電腦，因此在任何時候都不會成為瓶頸 (不過開始達到 2x4 測試的 CPU 飽和度)，因此我們在拓撲中不做變更。根據屬於實際作業應用程式混合一部分的查詢，資料庫伺服器 (SQL Server) 層預期會成為瓶頸。
在所有測試中，Reporting Services 會以已連線模式執行，並於應用程式伺服器 (Access Data Services) 層執行。
測試結果
下表顯示 Access Services 的測試結果。每組測試僅會變更特定變數，以顯示伺服器陣列效能的漸進影響。
本文中報告的所有測試均含有考慮時間或等候時間。這與其他 SharePoint 組件的容量規劃結果不同。
如需 Access Services 瓶頸的資訊，請參閱本文稍後的＜常見瓶頸及其原因 (可能為英文網頁)＞。
整體規模
下表及下圖摘要說明將其他前端網頁伺服器和專用 Access Data Services 電腦新增至伺服器陣列的影響。這些輸送量數字是針對 Access Data Services 電腦，不反映整個伺服器陣列的影響。
| 拓撲 | 基準解決方案最大值 (RPS) | 建議的基準 (RPS) |
|---|---|---|
1x1 |
25 |
15 |
1x2 |
54 |
29 |
1x3 |
82 |
45 |
1x4 |
88 |
48 |
2x1 |
25 |
15 |
2x2 |
55 |
29 |
2x4 |
116 |
58 |
.gif "最大及建議的 RPS")
建議的結果
下圖顯示建議可維持之輸送量的結果。
.gif "輸送量與 ADS")
如本文稍早所述，新增第四部 Access Data Services 電腦會將瓶頸轉移至前端網頁伺服器，而新增第二部前端網頁伺服器會解決前端網頁伺服器層的資源限制問題。換句話說，1x1、1x2 及 1x3 為合理的設定。但是，新增第四部 Access Data Services 電腦之後，也應該新增一部前端網頁伺服器。由於縮放比例呈線性成長 (介於 1x1 至 1x4 的直線)，因此可假設新增第七部 Access Data Services 電腦，也意味著新增第三部網頁伺服器以滿足伺服器陣列的需求，並依此類推。
請記住，這些結果僅根據模擬工作量，您應該監視實際部署，找出需要額外前端網頁伺服器的時間點，以支援其他的 Access Data Services 電腦。此外，前端網頁伺服器專屬於 Access Services，但是實際上，其他 SharePoint 工作量可能會共用前端網頁伺服器。下圖顯示結果。
.gif "回應時間與 ADS")
下圖顯示此輸送量層級的回應時間。回應時間很快，平均每個要求不到 ¼ 秒。
.gif "SQL %CPU 與 ADS")
這些結果顯示 SQL Server 電腦不是瓶頸，因為新增第二部前端網頁伺服器會解決資源短缺的情況，且 SQL Server CPU 一律低於 50%。但是，請注意 SQL Server 的執行個體會與其他 SharePoint 服務及 SharePoint 本身共用，因此累計效果可能會使得 CPU 或磁碟 I/O 佇列長度成為瓶頸。
最大值
下圖顯示超過可維持之輸送量的結果。
在此圖中，再次顯示需要第二部前端網頁伺服器，才能最大化第四部 Access Data Services 電腦的效用。同樣地，您的結果可能會不同，因為這與應用程式及其使用模式高度相關。
.gif "輸送量與 ADS")
在本例中，由於整體系統負荷甚重，因此回應時間會增加。但是，這些層級仍然接近一秒，而在大多數使用者可接受的範圍內。
您可能會覺得奇怪，在擁有四部 Access Data Services 電腦的情況下，兩部前端網頁伺服器的回應時間竟然會比一部前端網頁伺服器長。這是因為擁有兩部前端網頁伺服器之系統的整體輸送量增加所致。
SQL Server 在此處同樣也不是限制因素，因為新增第二部前端網頁伺服器會讓我們回到線性縮放。但是，我們幾乎達到 90% 的 SQL Server 執行個體 CPU 使用量。因此，所剩空餘空間有限。如果新增第五部 Access Data Services 電腦，SQL Server 電腦可能會成為瓶頸。
.gif "SQL %CPU 與 ADS")
詳細結果
下表顯示建議設定的詳細結果。
| 整體 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
要求/秒 |
14.96 |
28.76 |
45.22 |
48.01 |
14.85 |
28.77 |
58.02 |
測試/秒 |
2.00 |
3.81 |
6.11 |
6.42 |
1.99 |
3.81 |
7.80 |
平均延遲 |
235.80 |
241.21 |
247.21 |
244.87 |
240.70 |
242.26 |
250.94 |
| 平均前端網頁伺服器層 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
13.82 |
24.40 |
41.02 |
43.62 |
6.31 |
12.48 |
26.18 |
最大 w3wp 私用位元組 |
9.46E+08 |
2.31E+08 |
1.49E+09 |
1.55E+09 |
8.43E+08 |
9.84E+08 |
1.19E+09 |
| 平均應用程式伺服器 (Access Data Services) 層 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
46.30 |
42.83 |
43.74 |
34.51 |
46.56 |
43.45 |
42.13 |
%CPU w3wp |
33.61 |
31.15 |
30.71 |
24.29 |
33.48 |
31.64 |
29.72 |
%CPU RS |
8.62 |
7.94 |
9.17 |
6.84 |
9.03 |
8.02 |
8.71 |
最大私用位元組總計 |
4.80E+09 |
4.89E+09 |
4.91E+09 |
4.62E+09 |
5.32E+09 |
4.82E+09 |
5.07E+09 |
最大 w3wp 私用位元組 |
2.10E+09 |
1.97E+09 |
2.04E+09 |
1.86E+09 |
2.00E+09 |
2.00E+09 |
2.07E+09 |
最大 RS 私用位元組 |
1.78E+09 |
2.00E+09 |
1.97E+09 |
1.86E+09 |
2.30E+09 |
1.89E+09 |
2.02E+09 |
| 資料庫伺服器 (SQL Server) 層 (單一電腦) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
12.07 |
18.64 |
32.53 |
36.05 |
9.89 |
21.42 |
47.46 |
平均私用位元組 |
2.96E+10 |
3.22E+10 |
3.25E+10 |
3.25E+10 |
2.89E+10 |
3.22E+10 |
3.25E+10 |
最大私用位元組 |
3.26E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
平均磁碟佇列長度總計 |
0.74 |
1.18 |
1.64 |
1.77 |
0.67 |
1.24 |
2.18 |
下表顯示最大設定的詳細結果。
| 整體 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
要求/秒 |
14.96 |
28.76 |
45.22 |
48.01 |
14.85 |
28.77 |
58.02 |
測試/秒 |
2.00 |
3.81 |
6.11 |
6.42 |
1.99 |
3.81 |
7.80 |
平均延遲 |
235.80 |
241.21 |
247.21 |
244.87 |
240.70 |
242.26 |
250.94 |
| 平均前端網頁伺服器層 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
13.82 |
24.40 |
41.02 |
43.62 |
6.31 |
12.48 |
26.18 |
最大 w3wp 私用位元組 |
9.46E+08 |
2.31E+08 |
1.49E+09 |
1.55E+09 |
8.43E+08 |
9.84E+08 |
1.19E+09 |
| 平均應用程式伺服器 (Access Data Services) 層 | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
46.30 |
42.83 |
43.74 |
34.51 |
46.56 |
43.45 |
42.13 |
%CPU w3wp |
33.61 |
31.15 |
30.71 |
24.29 |
33.48 |
31.64 |
29.72 |
%CPU RS |
8.62 |
7.94 |
9.17 |
6.84 |
9.03 |
8.02 |
8.71 |
最大私用位元組總計 |
4.80E+09 |
4.89E+09 |
4.91E+09 |
4.62E+09 |
5.32E+09 |
4.82E+09 |
5.07E+09 |
最大 w3wp 私用位元組 |
2.10E+09 |
1.97E+09 |
2.04E+09 |
1.86E+09 |
2.00E+09 |
2.00E+09 |
2.07E+09 |
最大 RS 私用位元組 |
1.78E+09 |
2.00E+09 |
1.97E+09 |
1.86E+09 |
2.30E+09 |
1.89E+09 |
2.02E+09 |
| 資料庫伺服器 (SQL Server) 層 (單一電腦) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
%CPU |
12.07 |
18.64 |
32.53 |
36.05 |
9.89 |
21.42 |
47.46 |
平均私用位元組 |
2.96E+10 |
3.22E+10 |
3.25E+10 |
3.25E+10 |
2.89E+10 |
3.22E+10 |
3.25E+10 |
最大私用位元組 |
3.26E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
平均磁碟佇列長度總計 |
0.74 |
1.18 |
1.64 |
1.77 |
0.67 |
1.24 |
2.18 |
建議
本節提供一般的效能及容量建議。
Access Services 的容量和效能與服務主控的應用程式架構高度相關。資料表的大小和查詢的複雜性通常影響最大。本測試使用代表性的大小和複雜性，但是每一個應用程式和資料集均不同。因此，容量和效能取決於使用的應用程式、其特定複雜性及資料大小。
硬體建議
Access Services 使用前端網頁伺服器和應用程式伺服器的標準硬體；不需要任何特殊需求。SharePoint Server 2010 的一般 CPU 數目、速度及記憶體指導方針，適用於應用程式伺服器 (Access Data Services) 層的電腦。
向上擴充和向外擴充的拓撲
若要增加其中一個起始點拓撲的容量和效能，您可以執行下列兩個動作之一。您可以向上擴充以增加現有伺服器的容量，或向外擴充以將其他的伺服器新增至拓撲。本節說明數種向外擴充拓撲的一般效能特性。
範例拓撲表示下列向外擴充 Access Services 案例之拓撲的常用方式：
若要提供更多使用者負載，請檢查現有 Access Services 應用程式伺服器的 CPU，並在可能的情況下，將額外的 CPU 及 (或) 核心新增至這些伺服器。請視需要新增更多 Access Services 伺服器電腦。您可以在前端網頁伺服器成為瓶頸時執行此作業，然後視需要新增前端網頁伺服器。
在我們的測試中，前端網頁伺服器層和應用程式伺服器 (Access Data Services) 層的記憶體不是瓶頸。根據結果集的大小，記憶體可能會成為問題。但是，這種情況應該不常見。請如此處所述追蹤 Access Data Services w3wp 處理程序的私用位元組。
在我們的測試中，SQL Server 不是瓶頸。但是，我們的測試是在與其他 SharePoint Server 2010 服務隔離的情況下執行。您應該監視 SQL Server CPU 和磁碟 I/O，並視需要新增其他伺服器或主軸。
效能相關的 Access Services 設定
控制 Access Services 之效能特性的其中一個方式，是限制可執行的查詢大小和複雜性。Access Services 提供一組可設定的節流，以控制查詢。下列每個查詢都可以透過 SharePoint 管理中心來設定 (在 [應用程式管理] 區段中，按一下 [管理服務應用程式]，然後再按一下 [Access Services])。
一般而言，為了執行查詢而必須從 SharePoint 擷取的資料量，對效能會有很大的影響。您可以透過多種方式加以控制。首先，您可以限制查詢的輸入：
每個查詢的來源上限
每個資料表的記錄上限
其次，您可以限制所產生的查詢大小：
每個查詢的欄上限
每個查詢的列上限
允許外部聯結
除了查詢的大小 (進出的資料大小) 之外，您也可以控制資料處理的複雜性，以降低應用程式伺服器 (Access Data Services) 層的 CPU 負載：
每個查詢的計算結果欄上限
每個查詢的 Order By 子句上限
很明顯地，上述設定會影響伺服器上可能執行的應用程式。例如，如果以來自查詢的 40 個輸出欄編寫應用程式，且設定低於此層級，應用程式會發生執行階段錯誤。使用者需求與可接受的效能之間的平衡必定會受到影響，並且會與伺服器陣列上預期執行的 Access 應用程式類型高度相關。
您還可以採取一個更極端的措施。SharePoint Server 2010 本來就支援一組查詢作業，再由 Access Services 加以擴充以涵蓋一組更廣泛的應用程式案例。為了讓 Access Services 改善來自 SharePoint 的查詢，可能必須從 SharePoint 內容資料庫擷取大量資料。相反地，您可以設定 Access Services 僅使用 SharePoint 原本就支援的查詢作業，因而避免較複雜的作業需要擷取資料：
- 允許不可在遠端處理的查詢
最佳化
常見瓶頸及其原因
在效能測試期間，會發現幾個不同的常見瓶頸。瓶頸是伺服器陣列特定區域的容量已滿的情況。 這會導致伺服器陣列輸送量停滯或降低。
本文稍後＜疑難排解＞中的表格會列出一些常見的瓶頸，並說明其原因及可能的解決方法。
效能監視
為協助決定何時必須向上擴充或向外擴充系統，請使用效能計數器監視系統健康狀態。請使用下表中的資訊，以判斷所要監視的效能計數器，以及應該套用效能計數器的處理程序。
前端網頁伺服器
下表顯示監視伺服器陣列中網頁伺服器的效能計數器和處理程序。
| 效能計數器 | 套用至物件 | 附註 |
|---|---|---|
% Processor Time |
Processor(_Total) |
顯示此執行緒使用處理器執行指令的經過時間百分比。 |
Private Bytes |
Process(w3wp) |
此值不應該達到為 w3wp 處理程序設定的最大私用位元組。如果達到，則需要進一步調查使用記憶體的元件為何。 |
Access Data Services
下表顯示監視伺服器陣列中應用程式伺服器的效能計數器和處理程序，或在本例中，伺服器陣列內的 Access Data Services (Access Data Services)。
| 效能計數器 | 套用至物件 | 附註 |
|---|---|---|
% Processor Time |
Processor(_Total) |
顯示此執行緒使用處理器執行指令的經過時間百分比。 |
% Processor Time |
Process(w3wp) |
Access Data Services 在其本身的 w2wp 處理程序內執行，至於是哪一個 w2wp 處理程序則很明顯，因為該處理程序會佔用大量 CPU 時間。 |
Avg. Disk Queue Length |
PhysicalDisk(_Total) |
注意是否有太多基於記錄的磁碟寫入。 |
% Processor Time |
Process(ReportingServicesService) |
報表會由 SQL Server Reporting Services 來處理。如果執行太多報表，或報表非常複雜，則此處理程序的 CPU 和私用位元組都會很高。 |
Private Bytes |
Process(w3wp) |
Access Services 會從記憶體中快取使用者的工作階段到期 (可設定其逾時) 之前的查詢結果。如果透過 Access Data Services 處理大量資料，Access Data Services 之 w3wp 的記憶體使用量會增加。 |
Private Bytes |
Process(ReportingSrevicesService) |
報表會由 SQL Server Reporting Services 來處理。如果執行太多報表，或報表非常複雜，則此處理程序的 CPU 和私用位元組都會很高。 |
資料庫伺服器
下表顯示監看伺服器陣列中資料庫伺服器的效能計數器和處理程序。
| 效能計數器 | 套用至物件 | 附註 |
|---|---|---|
% Processor Time |
Processor(_Total) |
顯示此執行緒使用處理器執行指令的經過時間百分比。 |
% Processor Time |
Process(sqlservr) |
平均值大於 80% 表示資料庫伺服器的處理器容量不足。 |
Private Bytes |
Process(sqlservr) |
顯示 SQL Server 使用的平均記憶體數量。 |
Avg. Disk Queue Length |
PhysicalDisk(_Total) |
顯示平均磁碟佇列長度；資料庫要求等候磁碟認可。這通常是 SQL Server 執行個體變得超載的良好指標，增加磁碟主軸可能可以協助分散負載。 |
疑難排解
下表列出一些常見的瓶頸，並說明其原因及可能的解決方法。
| 瓶頸 | 原因 | 解決方法 |
|---|---|---|
Access Data Services CPU |
Access Services 需要在應用程式伺服器層進行大量處理。如果使用 1x1、1x2 或 1x3 設定，第一個遇到的瓶頸可能是 Access Data Services 伺服器上的 CPU。 |
增加現有 Access Data Services 電腦中的 CPU 及 (或) 核心數目。如果可能的話，請新增其他 Access Data Services 電腦。 |
網頁伺服器 CPU 使用量 |
當網頁伺服器的使用者要求超過負荷時，平均 CPU 使用量將達到百分之百。如此會讓網頁伺服器無法快速回應要求，而且可能在用戶端電腦造成逾時現象和產生錯誤訊息。 |
這個問題有兩種方式可以解決。您可以在伺服器陣列中新增更多網頁伺服器來分散使用者負載，或者，加入更高速的處理器來升級網頁伺服器。 |
資料庫伺服器磁碟 I/O |
當硬碟的 I/O 要求數量超過磁碟的 I/O 容量時，將會佇列要求。因此，完成每個要求的時間就會增加。 |
將資料檔散佈至多個實體磁碟可允許平行 I/O。SharePoint 磁碟配置與磁碟 I/O (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x404) (可能為英文網頁) 部落格文章中包含解決磁碟 I/O 問題的實用資訊。 |
Reporting Services CPU 使用率 |
Reporting Services 處理程序使用大部分的 CPU 資源。 |
將電腦設定為 Reporting Services 專用的電腦可減輕應用程式伺服器 (Access Data Services) 層 (已連線模式) 或前端網頁伺服器層 (本機模式) 中的負載。 |