評估 SharePoint Server 2010 中工作流程的效能與容量規劃
適用版本： SharePoint Server 2010
上次修改主題的時間： 2016-11-30
本文所述的效能與容量計劃，是針對在執行 Microsoft SharePoint Server 2010 的拓撲上使用工作流程所造成的影響提供指示。
如需 SharePoint Server 2010 容量計劃的一般資訊，請參閱＜效能及容量管理 (SharePoint Server 2010)＞。
內容
測試伺服器陣列特性
測試結果
建議
疑難排解
測試伺服器陣列特性
下列各節說明測試伺服器陣列的特性：
資料集
工作量
硬體、設定及拓撲
資料集
為了取得基準點，大部分的測試是在伺服器陣列的單一網站集合上預設的小組網站上執行。手動開始測試會以含有 8,000 個項目的清單開始工作流程。
工作量
測試此案例有助於開發人員預估不同的伺服器陣列組態如何回應下列變數的變更：
前端伺服器數量對於跨多台電腦手動開始的宣告性工作流程輸送量所產生的影響
前端伺服器數量對於跨多台電腦建立項目的自動開始宣告性工作流程輸送量的影響
前端伺服器數量對於跨多台電腦完成工作輸送量的影響
本文中所呈現的特定容量與效能數據，會和實際工作環境中所使用的數據不同。所呈現的數據主要是做為開始設計可適當調整的環境適用的最初依據。在完成初始系統設計之後，請測試設定，判斷系統是否支援環境中的各項因素。
本節定義測試案例，並討論每個案例所使用的測試程序。本文稍後的每個測試結果小節將提供測試結果及特定參數等詳細資訊。
| 測試名稱 | 測試描述 |
|---|---|
手動開始工作流程的輸送量 |
|
建立項目時，自動開始工作流程的輸送量 |
|
完成工作流程工作的輸送量 |
|
硬體、設定及拓撲
這些測試所使用的拓撲是將單一電腦用於內容資料庫，另使用預設安裝 SharePoint Server 2010 的一到四部前端電腦。雖然 Microsoft SharePoint Foundation 2010 中並沒有提供用於這些測試的工作流程，但是測試結果可以用來預估部署時的類似案例。這些測試所使用的資料集包含一個網站集合，並有一個網站是採用單一內容資料庫上的小組網站範本。
為提供高階測試結果詳細資料，測試使用數個伺服器陣列組態進行。伺服器陣列組態的範圍從一到四部網頁伺服器，以及一部執行 Microsoft SQL Server 2008 的電腦。執行測試時使用一部用戶端電腦。資料庫伺服器與所有網頁伺服器均為 64 位元，而用戶端電腦則是 32 位元。
下表列出用於測試的特定硬體。
| 網頁伺服器 | 資料庫伺服器 | |
|---|---|---|
處理器 |
2px4c@2.33GH |
4px4c@2.4GHz |
RAM |
4 GB |
16 GB |
作業系統 |
Windows Server 2008 R2 x64 |
Windows Server 2008 R2 x64 |
儲存裝置 |
680 GB |
4.2 TB |
網路介面卡數目 |
2 |
2 |
網路介面卡速度 |
1 GB |
1 GB |
驗證 |
NTLM |
NTLM |
軟體版本 |
4747 |
SQL Server 2008 R1 |
SQL Server 執行個體數 |
1 |
1 |
負載平衡器類型 |
無負載平衡器 |
無負載平衡器 |
ULS 記錄層級 |
中 |
中 |
工作流程容量計劃拓撲
.gif "工作流程規劃拓撲")
測試結果
下表顯示 SharePoint Server 2010 中工作流程的測試結果。每組測試僅會變更特定變數，以顯示伺服器陣列效能的漸進效果。
本文中報告的所有測試都不含考慮時間 (think time)，也就是連續作業間的自然延遲現象。在實際環境中，由於使用者要執行工作中的下一個步驟，因此每個作業後會有小段延遲。相較之下，測試中每個作業後會自動執行下一個作業，因此會持續載入伺服器陣列。這種載入會造成資料庫爭用，並產生會對效能造成負面影響的其他因素。
升級網頁伺服器對輸送量的影響
下列輸送量測試使用 SharePoint Server 2010 中隨附的核准工作流程執行。工作流程關聯指派一個工作，所有執行個體都在單一清單上執行。此工作流程的每個執行個體會在內容資料庫中建立下列項目：
工作流程表格中的項目，用於儲存工作流程狀態
五個次要清單項目 (一個工作與四個歷程記錄項目)
四個事件接收器，用來處理工作流程上層項目與工作上的事件
將「工作流程延遲臨界值」(Workflow Postpone Threshold) 設定成極大值，如此工作流程作業將永遠不會進入佇列。每個測試會執行五次，每次測試執行 5 分鐘。
手動開始輸送量
下表中的測試顯示增加前端伺服器的數量如何影響透過 Web 服務同步開始工作流程的輸送量。執行此測試是使用 25 個同時連線使用者的使用者負載，在 Workflow.asmx 上持續呼叫 StartWorkflow 方法，且伺服器陣列上沒有其他負載。使用者負載是發生捨棄 Web 要求前的最佳負載。清單最多預先填入 8,000 個項目。
| 拓撲 | 核准工作流程最大 RPS |
|---|---|
1x1 |
14.35 |
2x1 |
24.08 |
3x1 |
29.7 |
4x1 |
30.77 |
下圖顯示輸送量的變更情形。增加前端伺服器的數量對於伺服器陣列輸送量的影響，並不一定會呈線性成長，而是在使用三到四個前端伺服器時顯示為尖峰狀態。簡而言之，手動開始工作流程的最大輸送量大約是每秒 30 個工作流程，而增加到四個以上的前端伺服器將不會有明顯的影響。
手動開始輸送量
.gif "手動啟動輸送量")
建立項目時自動開始工作流程的輸送量
下表中的測試顯示增加前端伺服器的數量如何影響項目建立時自動開始工作流程的輸送量。執行此測試是使用 150 個同時連線使用者的使用者負載，持續呼叫清單 Web 服務，在單一清單中建立新的清單項目，且伺服器上沒有其他作業。清單開始時是空白清單。
| 拓撲 | 核准工作流程最大 RPS |
|---|---|
1x1 |
13.0 |
2x1 |
25.11 |
3x1 |
32.11 |
4x1 |
32.18 |
下圖顯示輸送量的變更情形。輸送量非常接近手動開始作業。與手動開始測試類似，輸送量的尖峰在大約使用三或四個前端伺服器時，每秒最多可執行約 32 個工作流程。增加到三或四個以上的前端伺服器將不會有明顯的影響。
自動啟動工作流程輸送量
.gif "自動啟動工作流程輸送量")
工作完成輸送量
下表中的測試顯示增加前端伺服器的數量如何影響完成工作流程工作的輸送量。之前測試中自動開始工作流程所使用的工作清單，就是用來完成工作的清單。執行此測試是使用 25 個同時連線使用者的使用者負載，在 Workflow.asmx 上執行呼叫 AlterToDo 方法，且伺服器上沒有其他作業。清單開始時是空白清單。
| 拓撲 | 核准工作流程最大 RPS |
|---|---|
1x1 |
13.5 |
2x1 |
23.86 |
3x1 |
27.06 |
4x1 |
27.14 |
下圖顯示輸送量的變更情形。與手動開始測試類似，輸送量的尖峰在大約使用三或四個前端伺服器時，每秒最多可執行約 32 個工作流程。增加到三個以上的前端伺服器將不會有明顯的影響。
工作完成輸送量
.gif "工作完成輸送量")
清單大小與工作流程執行個體數對輸送量的影響
下表中的測試顯示清單大小與工作流程數增加時輸送量的變更情形。資料填入方式是持續執行自動開始工作流程測試，直到清單建立一百萬個項目，並在不同的輸送量檢查點暫停測試，以測量輸送量，這與核心輸送量測試的方法相同。測試於 4x1 拓撲上執行。
為了維護資料填入期間的可靠性，我們必須保持工作流程佇列開啟，以避免資料庫伺服器上的連線數達到上限。如果沒有可用的連線，且工作流程作業無法連線內容資料庫，作業將無法執行。如需工作流程佇列的詳細資訊，請參閱＜建議＞。
| 項目或工作流程的數量 | 基準解決方案最大值 (RPS) |
|---|---|
0 |
32.18 |
10 |
32 |
1,000 |
28.67 |
10,000 |
27.16 |
100,000 |
16.98 |
1,000,000 |
9.27 |
項目、工作流程數目增加時的自動啟動輸送量
.gif "項目、工作流程數目增加時的輸送量")
對於單一清單、單一工作及歷程清單，輸送量在 1,000 到 100,000 個項目之間會穩定降低；不過，之後下降率會減小。我們認為有許多因素造成輸送量下降。
其中一個因素是每個執行個體在內容資料庫的多個資料表中新增的列數。如前所述，除了每個工作流程執行個體登錄的事件接收器之外，工作流程還會建立數個清單項目。隨著資料表的大小以不同規模擴大，新增列的速度會變慢，而與僅建立清單項目相較，這些新增項目的整體速度呈現明顯下降。
工作清單大小會造成額外負荷。若比較工作流程在新清單與新工作清單上執行的輸送量，工作清單對效能的影響較大；這是因為工作清單登錄的事件接收器比上層清單項目多。下圖說明其中的差異。
| 不同清單設定的輸送量 (每秒開始的工作流程) | 百萬項目工作清單 | 空白工作清單 |
|---|---|---|
百萬項目清單 |
9.27 |
12 |
空白項目 |
9.3 |
13 |
如果您知道將要執行龐大清單的大量工作流程，且需要的輸送量大於測試所顯示可取得的輸送量，請考慮您的工作清單是否可以與工作流程關聯分離。
建議
本節提供一般的效能及產能建議。可使用這些建議判斷您建立的開始拓撲的容量與效能特性，決定需要在系統外或系統內升級開始拓撲。
如需最低需求及建議的系統需求的特定資訊，請參閱＜硬體及軟體需求 (SharePoint Server 2010)＞。
擴大調整的拓撲
最多升級到四個網頁伺服器即可提高工作流程輸送量。接下來，額外的增加效果將不會很明顯。工作流程輸送量可以用效能相關的工作流程設定加以限制。這些設定在＜工作流程佇列和效能相關設定＞中有詳細說明。
預估輸送量目標
許多因素都會影響輸送量，包括使用者數量以及使用者作業的類型、複雜度和頻率。在內容資料庫執行許多作業或登錄更多事件的較複雜工作流程與其他工作流程相較之下，執行速度較慢且耗用更多資源。
此測試中使用的工作流程，會在工作流程中內建的內容資料庫中建立數個項目。如果您預期工作流程包含少量工作，輸送量特性會相當類似。如果大部分的工作流程包含非常少量的作業，則可提高輸送量。如果工作流程包含大量工作或密集的後端作業或處理能力，則輸送量會降低。
除了了解工作流程的處理能力外，也請考慮執行工作流程的地方，以及工作流程是否要執行大量清單，在這種情形下，輸送量會隨著時間慢慢減少。
有許多方式可以部署與設定 SharePoint Server 2010；並沒有簡單的方法可以預估指定的伺服器數量能夠支援多少位使用者。因此，您在生產環境中部署 SharePoint Server 2010 前，請務必先在自己的環境中進行測試。
工作流程佇列和效能相關設定
工作流程使用佇列系統，以控制伺服器陣列資源與內容資料庫上與工作流程相關的壓力。如果使用這種系統，在資料庫上執行的工作流程數達到系統管理員設定的臨界值時，後續的工作流程作業會新增至佇列，由工作流程計時器服務執行。在預設情況下，此服務每分鐘都會透過計時器工作，接收一批工作流程工作項目。
有數個與佇列機制直接或間接相關的伺服器陣列管理員設定，會影響工作流程的效能與範圍。下列小節說明這些設定的功能，以及如何調整設定以符合效能需求。
了解基本佇列設定
伺服器陣列管理員可以調整下列設定，來設定佇列系統的基本特性：
工作流程延遲臨界值 (Set-SPFarmConfig –WorkflowPostponeThreshold <整數>)
佇列其他要求和作業前，可以對單一內容資料庫執行的最大工作流程數量。佇列的工作流程會顯示開始狀態。這是適合整個伺服器陣列的設定，預設值為 15。這代表一次可以處理的工作流程作業數量，而不是指可以進行的最大工作流程數量。在工作流程作業完成時，將能夠執行後續的作業。
工作流程事件傳送批次大小 (Set-SPWorkflow –BatchSize <整數>)
工作流程計時器服務是延遲臨界值限制的例外狀況，將會從佇列擷取項目批次，並一次執行一個項目批次。這些批次可以大於延遲臨界值。每次執行時服務接收的工作項目數量，是使用 BatchSize 屬性加以設定。每個服務執行個體可以設定一次 BatchSize 屬性；預設值為 100。在未設定成前端伺服器的應用程式伺服器上執行時，工作流程計時器服務需要在組態資料庫中設定 Web.config 的工作流程組態設定。這必須透過指令碼執行，在 SPWebApplication 物件上呼叫 UpdateWorkflowConfigurationSettings()，從前端伺服器複製 Web.config 設定。
工作流程計時器工作頻率 (Set-SPTimerJob job-workflow –schedule <整數>)
工作流程計時器服務執行的頻率可以透過計時器工作設定加以調整。在預設情況下，設定為每 5 分鐘執行一次服務。這表示在處理佇列最上層的工作項目時，會有 5 分鐘的延遲。
注意
排程的工作項目 (如工作到期日有效期限) 也由相同的計時器機制取得；因此，延遲的時間間隔也相同。
使用管理中心的共用服務管理，可以關閉每部伺服器上的工作流程計時器服務。在預設情況下，它將在伺服器陣列中的每個前端伺服器上執行。每個工作將逐一執行伺服器陣列中的所有 Web 應用程式和內容資料庫。
延遲臨界點、批次大小以及計時器頻率的組合，可以用來限制資料庫上的工作流程作業。最大輸送量取決於作業佇列的速度與從佇列處理的速度。
例如，使用單一計時器服務與單一內容資料庫的預設設定，如果佇列中有 1,000 個項目，將執行 10 個計時器工作來處理全部的項目，需時 50 分鐘。不過，如果將批次大小設定為 1,000 且計時器工作設定為每分鐘執行，作業將在 1 分鐘後全部開始執行。如果設定較高的延遲臨界值，可以同時執行較多作業，進而減少佇列的要求數量，並且縮短處理這些工作流程全部所需的時間。
注意
建議您不要將延遲臨界值設定為大於 200，因為並行的工作流程執行個體會在自己的執行緒中執行，而且每一個執行個體會開啟新的 SQL Server 連線，因此在一段時間後，可能會影響資料庫伺服器的最大連線數。
如果您不希望在前端伺服器執行工作流程，也知道作業不會立即發生，可以單獨在選取的應用程式伺服器執行工作流程計時器服務，並設定很低的延遲臨界值，強制工作流程在計時器服務中執行，以及設定夠大的批次大小，便於更快速更頻繁地接收項目。如果要加強跨系統工作流程的同步執行，需設定較高的延遲臨界值，讓工作流程不要經常延遲而且擁有更立即的效果。
修改這些設定可最佳化工作流程的操作過程。建議您體驗不同的設定並進行測試，針對您的環境與需求進行最佳設定。
調整佇列的設定
如果伺服器陣列需要維持長時間大量的工作流程負載，或者系統中工作流程會有很多佇列的延遲事件，則佇列的工作流程作業數量會增加。除了基本的佇列設定外，您可能需要微調下列設定，以保持良好的佇列狀況：
工作項目事件傳送批次大小
工作流程用於佇列事件的資料表是一般的工作項目資料表，與 SharePoint Server 2010 中的其他非工作流程功能共用。因此，還有另一個清除非工作流程項目佇列的計時器工作。工作項目事件傳送批次大小與工作流程事件傳送批次大小類似，可指定一次清除的非工作流程工作項目佇列數量。
工作流程容錯移轉計時器工作頻率
在極少數的情況下，如果工作流程事件無法傳送到工作流程執行個體，事件傳送將在佇列上排程，讓容錯移轉工作項目稍後重試 (先從 5 分鐘後開始，如果失敗，則 10 分鐘後開始，接著是 20 分鐘後等等)。工作流程容錯移轉計時器工作會清除容錯移轉工作項目的佇列，而此設定會調整容錯移轉計時器執行的頻率；預設每 15 分鐘執行一次。
工作流程容錯移轉批次大小
此設定與工作流程和工作項目批次大小設定類似，控制每個容錯移轉計時器工作將清除佇列的容錯移轉事件數量。
由於有許多計時器工作在相同的資料表上操作，因此大量的佇列項目會造成資料庫爭用，並降低輸送量和可靠性。若要減少爭用情形，建議您採用下列方法：
平衡延遲臨界值與工作流程批次大小，如此一來，批次大小會變小或計時器工作頻率變高，足以在下一個計時器工作開始前完成前一個計時器工作，避免堆積過多要執行的平行計時器工作而無法完成。
若要避免資料表鎖定，請不要將兩個批次大小設定為大於 5,000。
提示
位移工作流程、工作項目以及容錯移轉計時器工作，不要讓這些物件一直在相同時間執行。若要取得包含工作流程的龐大清單，將工作流程計時工作設定為 4 分鐘，容錯移轉設定為 6 分鐘，就能在我們的資料填入指令碼中順利運作。
增強工作與歷程清單的範圍
工作流程會產生每個執行個體的許多工作與歷程記錄項目。在預設情況下，會建立這些清單的索引以協助調整範圍，但是隨著這些清單的擴大，總是會降低效能。若要減少降低的速率，需為不同的工作流程關聯保持個別歷程記錄與工作清單，並在清單變大時，定期變更工作流程關聯中的這些清單。
工作流程也有每日計時器工作 (job-workflow-autoclean)，會自動刪除工作流程執行個體以及已完成 60 天以上的執行個體工作。保留此計時器工作，盡量保持簡潔的工作清單與事件。如果必須保留資料，請將資料寫入其他清單或封存位置。此計時器工作不會刪除工作流程歷程記錄項目。如果您必須清除這些項目，請使用指令碼或透過清單使用者介面手動執行。
其他考量
移除清單上的資料欄會使資料庫作業與清單中的項目數量成正比。移除工作流程關聯將會從清單移除工作流程狀態欄；這使得龐大清單上產生大量作業。如果您知道清單包含百萬個項目，請將工作流程設定為 [沒有新的例項] 而不是移除工作流程。
疑難排解
| 瓶頸 | 原因 | 解決方法 |
|---|---|---|
資料庫爭用 (鎖定) |
資料庫鎖定可防止多位使用者因為修改一組資料而產生衝突。當使用者或處理程序鎖定一組資料時，其他使用者或處理程序無法變更該組資料，直到第一位使用者或第一個處理程序完成變更資料並釋放鎖定為止。 |
若要協助減少資料庫鎖定的事件，請執行下列動作：
SQL Server 2005 中提供規避資料庫鎖定系統的方法，例如，NOLOCK 參數。不過，不建議或支援使用這種方法，因為可能毀損資料。 |
資料庫伺服器磁碟 I/O |
當硬碟的 I/O 要求數量超過磁碟的 I/O 容量時，將會佇列要求。因此，完成每個要求的時間就會增加。 |
將資料檔散佈至多個實體磁碟可允許平行 I/O。SharePoint 磁碟配置與磁碟 I/O(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x404)(可能為英文網頁) 部落格文章中包含解決磁碟 I/O 問題的實用資訊。 |
網頁伺服器 CPU 使用率 |
當網頁伺服器的使用者要求超過負荷時，平均 CPU 使用率將達到百分之百。如此會讓網頁伺服器無法快速回應要求，而且可能在用戶端電腦造成逾時現象和產生錯誤訊息。 |
這個問題有兩種方式可以解決。您可以在伺服器陣列中新增網頁伺服器來分配使用者負載，或者，加入更快的處理器來升級網頁伺服器。 |
網頁伺服器
下表顯示監看伺服器陣列中網頁伺服器的效能計數器和處理程序。
| 效能計數器 | 套用至物件 | 附註 |
|---|---|---|
處理器時間 |
總計 |
顯示此執行緒使用處理器執行指令的經過時間百分比。 |
記憶體使用量 |
應用程式集區 |
顯示應用程式集區的系統記憶體平均使用量。您必須決定要監看的正確應用程式集區。 基本原則是判斷指定的 Web 應用程式尖峰記憶體使用量，並將該數字加上 10，指派給關聯的應用程式集區。 |
資料庫伺服器
下表顯示監看伺服器陣列中資料庫伺服器的效能計數器和處理程序。
| 效能計數器 | 套用至物件 | 附註 |
|---|---|---|
磁碟平均佇列長度 |
包含 SharedServices.mdf 的硬碟 |
大於每轉速 1.5 的平均值表示該硬碟的寫入時間不足。 |
處理器時間 |
SQL Server 處理程序 |
平均值大於 80% 表示資料庫伺服器的處理器容量不足。 |
處理器時間 |
總計 |
顯示此執行緒使用處理器執行指令的經過時間百分比。 |
記憶體使用量 |
總計 |
顯示系統記憶體的平均使用量。 |