共用方式為

SharePoint Server 2013 的效能測試

  • 發行項

 

**適用版本：**SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard

**上次修改主題的時間：**2017-08-25

**摘要：**了解如何規劃及執行 SharePoint Server 2013 環境的效能測試。

本文說明如何測試SharePoint Server 2013的效能。測試和最佳化階段是有效的容量管理的重要元件。您應測試新架構再將其部署至實際執行環境與您應該進行接受度測試搭配下列監控的最佳作法以確保您設計的架構達到效能與容量目標。這可讓您識別和最佳化的潛在瓶頸之前所影響的實際部署中的使用者。如果您要升級Office SharePoint Server 2007環境及計劃進行結構變更，或要估計使用者負載的新SharePoint Server 2013功能，然後測試以確定您的新SharePoint Server 2013特別重要-根據的環境將符合效能和容量目標。

測試環境之後，您可以分析測試結果，決定需要進行何種變更，以達成您在＜SharePoint Server 2013 的容量規劃＞的＜步驟 1：模型＞中所建立的效能與容量目標。

這些是您針對實際執行前應該遵循的子步驟：

  • 模擬您在＜步驟 2：設計＞中設計的架構，建立測試環境。

  • 利用您在＜步驟 1：模型＞中指出的資料集或部分資料集填入儲存。

  • 對系統施加代表＜步驟 1：模型＞中指出之工作量的綜合負載。

  • 執行測試、分析、結果，並最佳化您的架構。

  • 在資料中心中部署您的最佳化架構，並將較小的一組使用者導入試驗。

  • 分析試驗結果，找出瓶頸，並最佳化架構。如果需要的話，可以重新測試。

  • 部署實際執行環境。

在您閱讀本文之前，必須先閱讀＜SharePoint Server 2013 的容量管理及調整大小概觀＞。

本文內容：

  • 建立測試規劃

  • 建立測試環境

  • 建立測試與工具

建立測試規劃

確認您的規劃包含：

  • 設計用於在預期實際執行效能目標上操作的硬體。始終謹慎地評估測試系統的效能。

  • 如果您有自訂程式碼或自訂元件，先測試這些隔離元件的效能以驗證其效能與穩定性，是相當重要的。測試其穩定之後，您應該測試包含這些已安裝元件的系統，並針對不含這些已安裝元件的伺服器陣列比較效能。自訂元件通常是實際執行系統中效能與可靠性問題的主要肇因。

  • 認識您的測試目標。提前了解您的測試目標為何。其是否可驗證對伺服器陣列所開發之某些新自訂元件的效能？其是否可看出編目及索引一套內容所需花費的時間？其是否可判斷您的伺服器陣列每秒可支援多少要求？測試期間可以有許多不同目標，而發展一個優秀測試計劃的第一步即為決定您的目標為何。

  • 了解如何評估您的測試目標。例如，如果您對評估伺服器陣列的輸送量感興趣，您會想要評估 RPS 和頁面延遲。如果您要評估搜尋效能，則會想要評估編目時間與文件索引效率。如果能充分了解測試目標，將有助於清楚定義您需要驗證的關鍵效能指標以完成測試。

建立測試環境

決定測試目標之後，即已定義您的測量，並且已決定伺服器陣列的容量需求 (從處理程序的步驟 1 和步驟 2 得知)，下一個目標將會是設定與建立測試環境。建立測試環境所耗費的心力常被低估。該環境應該儘可能複製成接近實際執行的環境。設計測試環境時，您應該考慮的部分功能包含：

  • **驗證：**決定伺服器陣列是否將使用 Active Directory 網域服務 (AD DS)、表單型驗證 (如果是的話，具備何種目錄)、宣告式驗證等等。無論您使用哪一種目錄，無論在測試環境中需要多少使用者，以及無論您想要如何建立這些環境？您需要多少群組或角色，以及您將如何建立並填入這些群組或角色？您也需要確定具備足夠的資源可分配至您的驗證服務，使其不會在驗證期間造成瓶頸。

  • **DNS：**了解測試期間所需要的命名空間。識別何種伺服器將對應至這些要求，並確定已包含於何種 IP 位址將用於何種伺服器，以及您必須建立何種 DNS 項目的計劃中。

  • **負載平衡：**假定您使用多部伺服器 (您通常會或可能不會有足夠的負載以保證負載測試)，您將需要某種負載平衡器解決方案。其可能是硬體負載平衡裝置，或可能使用如 Windows NLB 的軟體負載平衡。請指出您將使用何種解決方案，並記下您需要用來快速及有效設定所需要的所有設定資訊。另一點要記住的是負載測試代理程式通常每 30 秒會嘗試並解析 URL 位址一次。這表示您不應該針對負載平衡使用本機主機檔案或循環配置 DNS，因為測試代理程式最終可能會針對每一個單一要求前往相同的伺服器，而非在所有可用的伺服器之間取得平衡。

  • 測試伺服器： 當您規劃您的測試環境時，不只需要規劃SharePoint Server 2013伺服器陣列的伺服器，您也需要規劃所需執行測試的機器。通常，將會包含在最低限度下 ； 3 部伺服器更多可能需要。如果您使用 Visual Studio Team System （小組測試負載代理程式） 執行測試，一部機器將用作負載測試控制站。通常有 2 或更多負載測試代理程式所做的機器。代理程式所採取的指示從測試控制站相關功能測試及議題要求給SharePoint Server 2013伺服器陣列的機器。其本身的測試結果會儲存在 SQL Server 電腦上。您不應該使用 SQL Server 為基礎的電腦使用SharePoint Server 2016伺服器陣列的因為撰寫測試資料會扭曲SharePoint Server 2013伺服器陣列的可用的 SQL Server 資源。您也需要時就監視SharePoint Server 2013伺服器陣列或網域控制站，以確定的測試結果是您要設定伺服器陣列的人等中的伺服器相同的方式執行測試、 監視測試伺服器。有時負載代理程式或控制站可會成為瓶頸本身。如果發生這種情況然後您在測試中看見的輸送量通常是不在伺服器陣列所能支援的最大值。

  • **SQL Server：**在您的測試環境中，遵循本文＜規劃及設定儲存設備與 SQL Server 容量 (SharePoint Server)＞中的＜設定 SQL Server＞和＜驗證並監視儲存以及 SQL Server 效能＞。

  • **資料集驗證：**當您決定執行測試要對應何種內容時，請記住您從現有的實際執行系統使用資料的最佳情況。例如，您可以從實際執行伺服器陣列備份內容資料庫，並將其還原至您的測試環境，然後附加資料庫以將內容帶入伺服器陣列。每當您對應製作的資料或範例資料來進行測試時，由於內容主體中的差異，您會承擔結果扭曲的風險。

如果您必須建立範例資料，當您建立內容時，必須記住一些注意事項：

  • 應發佈所有頁面，不應該取出任何頁面

  • 導覽應該切合實際，不要超出您在實際執行中使用的合理預期。

  • 您應該知道實際執行網站將使用的自訂項目。例如，主版頁面、樣式表、JavaScript 等等，全部在測試環境中實作的情況應該儘可能接近實際執行環境中實作的情況。

  • 決定您將需要多少 SharePoint 群組及/或權限層級，以及您要如何將使用者與其建立關聯。

  • 了解您是否需要執行設定檔匯入，以及將花費的時間。

  • 決定您是否需要「對象」，以及您將如何建立並填入對象。

  • 決定您是否需要其他搜尋內容來源，以及建立時所需要的項目。如果不需要建立，請判斷您是否具備網路存取權以對其進行編目。

  • 決定您是否具備足夠的範例資料 - 文件、清單、清單項目等等。如果沒有，請針對建立內容的方法，建立一個計劃。

  • 建立一個具有足夠獨特內容的計劃以充分測試搜尋。常見的錯誤是將相同的文件 - 可能數百或數千次 - 上傳至具有不同名稱的不同文件庫。這會影響搜尋效能，因為查詢處理器將會花費很多時間進行重複的偵測，相對於在具有真實內容之實際執行的環境中則不會如此耗時。

建立測試與工具

測試環境可正常運作之後，該是時候來建立及微調會用來測量的伺服器陣列的效能容量測試。本節將有些時候進行特別 Visual Studio Team System （小組測試負載代理程式） 的參照，但有許多概念是適用不論您使用負載測試工具為何。如需 Visual Studio Team System 的詳細資訊，請參閱Visual Studio Team System在 MSDN (https://msdn.microsoft.com/en-us/library/fda2bad5.aspx")。

您也可以將 SharePoint Load Test Kit (LTK) 與 VSTS 搭配使用，以供 SharePoint 2010 伺服器陣列的負載測試使用。Load Test Kit 會根據 Windows SharePoint Services 3.0 和 Microsoft Office SharePoint Server 2007 IIS 記錄檔，產生 Visual Studio Team System 2008 負載測試。VSTS 負載測試可用於對應 SharePoint Foundation 2010 或 SharePoint Server 2010 產生綜合負載，作為容量計劃練習或升級前負載測試。

Load Test Kit 包含在 Microsoft SharePoint 2010 Administration Toolkit v1.0 中，可從 Microsoft 下載中心 (https://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=en) 取得。

測試成功的重要準則是內容的要能夠有效率地模擬真實感化的工作負載測試網站資料、 各種不同產生要求就如同使用者會存取各種實際執行SharePoint Server 2013伺服器陣列中。若要這樣做，您通常需要建構等的資料進行測試。而不是建立百的個別測試的硬式編碼存取特定頁面，您應該使用少數測試，以動態方式存取的一組頁面使用包含這些項目的 Url 的資料來源。

在 Visual Studio Team System （小組測試負載代理程式）、 資料來源可以在各種格式，甚至但 CSV 檔案格式通常是錄製到管理和開發及測試環境之間傳輸。請記住使用該內容建立 CSV 檔案可能會需要建立的自訂工具來列舉SharePoint Server 2013-根據環境及記錄所使用的各種 Url。

您可能需要針對工作使用以下工具：

  • 如果您使用表單型驗證，請建立 Active Directory 中的使用者和群組，或其他驗證存放區

  • 列舉網站 URL、清單與程式庫、清單項目、文件等等，並將其置於 CSV 檔案以供負載測試使用

  • 在眾多文件庫與網站之間上傳範例文件

  • 建立網站集合、Web、清單、程式庫、資料夾與清單項目

  • 建立「我的網站」

  • 建立包含使用者名稱與密碼的 CSV 檔案以供測試使用者，這些是負載測試將執行的使用者帳戶。應該有多個檔案，例如，一些僅包含管理員使用者，一些包含具備較高權限的其他使用者 (例如作者/參與者、階層管理員等等)，其他僅限讀取者之類。

  • 建立範例搜尋關鍵字與片語的清單

  • 透過使用者和 Active Directory 群組填入 SharePoint 群組與權限層級 (或者是如果您使用表單型驗證，請填入角色

建立 Web 測試時，有其他您應該遵守並執行的最佳作法。包含：

  • 從記錄簡單的 Web 測試開始。這些測試將具備參數的硬式編碼值，例如 URL、ID 等等。利用 CSV 檔案中的連結取代這些硬式編碼值。在 Visual Studio Team System (Team Test Load Agent) 中繫結這些值的資料相當簡單。

  • 一律為您的測試驗證規則。例如，要求頁面時，如果發生錯誤，您通常會在回應中取得 error.aspx 頁面。對 Web 測試而言，它只會以正面回應顯示，因為您會在負載測試結果中取得 HTTP 狀態碼 200 (成功)。顯然地，雖然發生錯誤，但應該以不同的方式追蹤。以回應發送某些文字時，建立一個或多個規則，以便在驗證失敗以及要求標記為失敗時，供您截獲。例如，在 Visual Studio Team System (Team Test Load Agent) 中，一個簡單的驗證規則可能是 ResponseUrl 驗證 – 如果重新導向之後所呈現的頁面與測試中所記錄的回應頁面不同，則會記錄失敗。如果找到「已拒絕存取」的文字，您也可以新增可記錄失敗的 FindText 規則，例如，在回應中。

  • 使用不同角色中的多個使用者以供測試。某些行為 (例如輸出快取工作) 會根據目前使用者的權限而有所不同。例如，具備核准或撰寫權限的網站集合管理員或經過驗證的使用者將不會取得快取的結果，因為我們通常希望看見最新版本的內容。不過，匿名使用者將取得快取的內容。您必須確定您的測試使用者是這些角色的混合，其大致符合實際執行環境中的使用者混合。例如，在實際執行中可能只有兩個或三個網站管理員，因此，您不應該針對測試內容之網站集合管理員的使用者帳戶所進行的 10% 頁面要求建立測試。

  • 剖析相依要求是 Visual Studio Team System (Team Test Load Agent) 的一種屬性，可決定測試代理程式應該嘗試僅擷取頁面，或擷取頁面及屬於該頁面的所有相關要求，例如圖像、樣式表、指令碼等等。載入設定時，基於以下原因，通常會忽略這些項目：

    • 當使用者第一次瀏覽網站之後，通常會由本機瀏覽器快取這些項目

    • 這些項目不通常是來自 SQL Server 中SharePoint Server 2013-為主的環境。使用 BLOB 快取開啟，他們會改用回應 Web 伺服器讓他們不產生 SQL Server 負載。

如果您經常有高百分比的初次瀏覽網站的使用者，或者已停用瀏覽器快取，或基於某些原因，您不打算使用 BLOB 快取，則其對於在測試中啟用剖析相依要求應該是合理的。不過，這的確是例外情況，而且不是大多數實作的經驗法則。請注意，如果您確定要啟用，它會明顯地擴大由測試控制台回報的 RPS 數字。這些要求的處理速度非常快，可能會誤導您認為伺服器陣列中比實際擁有更多的可用容量。

  • 請記得模型用戶端應用程式活動，以及。用戶端應用程式，例如 Microsoft Word、 PowerPoint、 Excel 及 Outlook 產生SharePoint Server 2013伺服器陣列的要求。他們藉由傳送伺服器要求如擷取 RSS 摘要、 取得社交資訊、 要求網站和清單結構的詳細資訊、 同步處理資料等加入環境的負載。應該包含並設定模型中如有這些用戶端實作這些類型的要求。

  • 在大多數情況下，Web 測試應該僅包含單一要求。如果測試僅包含單一要求，會比較容易進行微調和疑難排解您的測試控管及個別要求。如果操作是模擬包含多個要求，則 Web 測試通常需要包含多個要求。例如，若要測試這組動作，您需要透過多個步驟進行測試：取出文件、編輯該文件、存回文件，然後發佈文件。測試也要求在步驟之間重複執行 – 例如，應該使用相同的使用者帳戶進行取出、編輯，以及存回。這些需要在每一個步驟之間移轉的多步驟操作，透過單一 Web 測試中的多個要求來處理的效果最佳。

  • 個別測試每一個 Web 測試。先確定可成功完成每一個測試，然後才可在較大的負載測試中執行。確認 Web 應用程式解析的所有名稱，而且測試中所使用的使用者帳戶具備足夠權限以執行測試。

Web 測試包含個別頁面的要求、上傳文件、檢視清單項目等等。這些全部會提取至負載測試中。負載測試是您要外掛所有要執行之不同 Web 測試的所在之處。每一個 Web 測試可指定將執行的時間百分比 - 例如，如果您發現實際執行的伺服器陣列中 10% 的要求為搜尋查詢，則在負載測試中，您會設定查詢 Web 測試以執行 10% 的時間。在 Visual Studio Team System (Team Test Load Agent) 中，負載測試也是您設定項目 (例如瀏覽器混合、網路混合、負載模式，以及執行設定) 的方法。

對於負載測試有某些其他的最佳作法應遵守並執行：

  • 在測試中使用合理的讀/寫比例。當測試中的寫入數目超載時，會明顯影響測試的整體輸送量。即使在共同作業伺服器陣列中，讀/寫比例往往傾向於讀取而非寫入。

  • 考慮到大量資源操作的影響，決定是否應該在負載測試中執行這些操作。例如，通常不會在負載測試中完成像是備份與還原的操作。有鑑於一般可能會執行累加編目，所以通常不會在負載測試中執行完整的搜尋編目。您必須考慮這些工作如何排程至實際執行 - 它們是否會在尖峰負載時間中執行？如果不會，當您嘗試決定尖峰流量可支援的穩定狀態上限時，則應該在負載測試期間排除這些工作。

  • 請勿使用思考時間。思考時間是一種功能的 Visual Studio Team System （小組測試負載代理程式） 可讓您以模擬使用者暫停頁面上的點閱之間的時間。例如一般使用者可能會載入頁面，花費 3 分鐘讀取它，然後按一下以造訪另一個網站] 頁面上的連結。嘗試重新建立此模型的測試環境中執行正確，幾乎不可能而實際上不會將值新增至測試結果。很難模型因為大多數組織沒有一種方式來監視不同的使用者與在不同類型的 SharePoint 網站 （例如發佈與搜尋與共同作業、 等。） 按一下它們之間所花費的時間。它也不會真的將值新增因為即使使用者可能會暫停之間的要求] 頁面上， SharePoint Server 2013-根據的伺服器未執行。他們只是要取得穩定的資料流的要求可能會有尖峰量及谷地一段時間，但它們未等待這為每個使用者將游標暫停之間按一下頁面上的連結。

  • 了解使用者與要求之間的差異。Visual Studio Team System (Team Test Load Agent) 具備負載模式，會要求您輸入要模擬的使用者數目。無須透過應用程式使用者執行任何動作，實際上只是負載測試代理程式上要使用多少執行緒來產生要求。最常見的誤解是假設部署有 5,000 個使用者，則 Visual Studio Team System (Team Test Load Agent) 中應該使用的數目即為 5,000 - 這是錯誤的！這就是為什麼評估容量計劃需求時，使用需求應該根據每秒的要求數目而非使用者數目的眾多原因之一。在 Visual Studio Team System (Team Test Load Agent) 負載測試中，您會發現通常僅利用 50 到 75 個負載測試「使用者」，每秒即可產生數以百計的要求。

  • 使用常數負載模式最可靠且可重現當測試結果。在 Visual Studio Team System （小組測試負載代理程式） 您有選擇審查負載的使用者 （執行緒，如先前點中所述），常數目而定逐步設定的使用者，負載模式或目標基礎使用狀況測試。開始使用較低的使用者數目，然後"步驟"新增其他使用者每隔幾分鐘時逐步的負載圖樣。建立計數器臨界值某些診斷、 like CPU 使用率和測試會嘗試將磁碟機之後要保留您定義的最小和最大閾值之間的計數器負載時的目標架構使用狀況測試。不過，如果您只嘗試判斷SharePoint Server 2013伺服器陣列可維持在尖峰負載期間的最大輸送量，最好是更具效率且正確只挑選常數負載模式。可讓您更輕鬆地識別系統能夠充分啟動定期超過臨界值應保留在狀況良好的伺服器陣列中的前多少負載。

每次執行負載測試時，請記住它會在資料庫中變更資料。無論是上傳文件、編輯清單項目，或只是在使用狀況資料庫中記錄活動，皆會有資料寫入 SQL Server。若要確保每一個負載測試之測試結果集合的一致與合法，您應該先有一個可用的備份，才可執行第一個負載測試。完成每一個負載測試之後，備份應該將內容還原回測試開始之前的樣子。

See also

SharePoint Server 2013 的容量規劃
監視和維護 SharePoint Server 2013
SharePoint Server 2016 中的監視與報告
SharePoint Server 2016 的軟體界限及限制

SharePoint Server 2013 的容量管理及調整大小概觀