SharePoint Server 2013 的效能測試
適用於：
Subscription Edition SharePoint in Microsoft 365
本文說明如何測試 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 伺服器陣列的伺服器，還需要規劃執行測試所需的機器。 通常至少會包含三部伺服器;可能需要更多專案。 如果您使用 Visual Studio Team System (Team Test Load Agent) 執行測試，則會使用一部機器作為負載測試控制器。 通常有兩部或多部機器用來作為負載測試代理程式。 代理程式是從測試控制器取得指示 (有關測試內容)，並對 SharePoint Server 2013 伺服器陣列發出要求的機器。 測試結果會自行儲存在 SQL Server 型電腦上。 您不應該使用用於 SharePoint Server 2016 伺服器陣列的相同 SQL Server 計算機，因為撰寫測試數據會扭曲 SharePoint Server 2013 伺服器陣列的可用 SQL Server 資源。 您也需要在執行測試時監視您的測試伺服器，如同您監視 SharePoint Server 2013 伺服器陣列或網域控制站等中的伺服器一般，以確定測試結果正是您所設定伺服器陣列的典型。 有時候負載代理程式或控制器本身可能成為瓶頸。 如果發生這種情況，則您在測試中看到的輸送量通常不是伺服器數位所能支援的最大值。
SQL Server：在測試環境中，請遵循規劃及設定儲存體與 SQL Server 容量 (SharePoint Server)一文中的「設定 SQL Server」和「驗證及監視儲存體與 SQL Server 的效能」。
數據集驗證：當您決定要針對哪些內容執行測試時，請記住，在最佳案例中，您將使用現有生產系統中的數據。 例如，您可以從生產伺服器陣列備份您的內容資料庫，並將它們還原至您的測試環境，然後附加資料庫，以將內容帶入伺服器陣列中。 只要您針對組成或範例資料執行測試時，就會冒著讓您結果扭曲的風險，這是由於內容主體中的差異所造成。
如果您必須建立範例資料，則在建置該內容時，有幾個考量要牢記在心：
應該發佈所有頁面；不應該簽出任何頁面
瀏覽應該是實際可行的；建置的內容不應超出預期可在生產環境中使用的合理內容。
您應該了解生產網站將使用的自訂。 例如，主版頁面、樣式表、JavaScript 等全都應該在十分接近生產環境的測試環境中進行實作。
判斷您需要多少 SharePoint 群組和/或許可權等級，以及您要如何將使用者與其建立關聯。
了解您是否將需要執行設定檔匯入，以及需要多少時間。
判定您是否需要對象，以及將如何建立和填入他們。
判斷您是否需要更多搜尋內容來源，以及建立它們所需的內容。 如果您不需要建立它們，請判定您是否需要擁有網路存取權，才能對其進行編目。
判斷您是否有足夠的範例數據 - 檔案、清單、清單專案等。如果沒有，請為您建立此內容的方式建立計劃。
規劃足夠的獨特內容以充分測試搜尋。 常見的錯誤是將相同的文件 (可能數百甚至數千次) 上傳至具有不同名稱的不同文件庫。 這可能會影響搜尋效能，因為查詢處理器會花費一定的時間執行重複偵測，否則它將無法在具有實際內容的生產環境中進行。
建立測試和工具
測試環境正常運作之後，就可以建立並微調將用來測量伺服器數位效能容量的測試。 本節有時會特別提到 Visual Studio Team System (Team Test Load Agent)，但許多觀念適用，不論您使用哪個負載測試工具。 如需適用於 Azure DevOps (先前稱為 VSTS) 的測試工具詳細資訊，請參閱 Azure DevOps 的 DevOps 工具概觀。
您也可以搭配 VSTS 使用 SharePoint 負載測試套件 (LTK) ，以進行 SharePoint 2010 伺服器數位的負載測試。 負載測試套件會根據 Windows SharePoint Services 3.0 和 Microsoft Office SharePoint Server 2007 IIS 記錄，產生 Visual Studio Team System 2008 負載測試。 VSTS 負載測試可用來針對 SharePoint Foundation 2010 或 SharePoint Server 2010 產生綜合負載，作為容量規劃練習或預先升級壓力測試的一部分。
負載測試套件隨附於可從 Microsoft 下載中心取得的 Microsoft SharePoint 2010 Administration Toolkit v2.0。
測試成功的關鍵準則就是能夠透過廣泛的測試網站資料產生要求，來有效地模擬實際的工作負載，正如同使用者在生產 SharePoint Server 2013 伺服器陣列中存取廣泛內容一般。 若要這樣做，您通常需要建構測試，使其成為數據驅動。 不是建立數百個硬式編碼以存取特定頁面的個別測試，而是您應該只使用少數使用資料來源 (其中包含這些項目的 URL) 的測試，以動態存取該組頁面。
在 Visual Studio Team System (Team Test Load Agent) 中，數據源可以有各種格式，但 CSV 檔案格式通常最容易在開發和測試環境之間管理和傳輸。 請記住，利用該內容建立 CSV 檔案可能需要建立自訂工具，以列舉 SharePoint Server 2013 型環境，並記錄所使用的各種不 URL。
您可能需要針對如下工作使用這些工具：
在 Active Directory 或其他驗證存放區中建立使用者和群組，如果您使用表單型驗證的話
列舉網站、清單和文件庫、清單項目、文件等的 URL，並將它們放入 CSV 檔案中，以進行負載測試
上傳廣泛文件庫和網站中的範例文件
建立網站集合、Web、清單、文件庫、資料夾和清單項目
建立我的網站
使用測試使用者的使用者名稱和密碼建立 CSV 檔案；這些是負載測試將以其身分執行的使用者帳戶。 應該要有多個檔案，例如，以便有些檔案只包含系統管理員使用者、有些檔案包含其他已提高權限的使用者 (例如作者/投稿者、階層經理等)，以及有些檔案只包含讀者。
建立範例搜尋關鍵字或片語的清單
如果您使用表單型驗證，請將使用者和 Active Directory 群組 (或角色填入 SharePoint 群組和許可權等級)
建立 Web 測試時，有其他您應該遵守並實作的最佳做法。 其中包含：
將簡易 Web 測試記錄為起點。 這些測試中會有適用於 URL、識別碼等參數的硬式編碼值。將這些硬式編碼值取代為 CSV 檔案中的連結。 在 Visual Studio Team System (Team Test Load Agent) 中系結這些值的數據很容易。
一律具有適用於測試的驗證規則。 例如，在要求頁面時，如果發生錯誤，您通常會收到error.aspx頁面的回應。 從 Web 測試的觀點來看，它看起來只是另一個正面響應，因為您會在負載測試結果中取得 200 (成功) 的 HTTP 狀態代碼。 雖然明顯地發生錯誤，但應該以不同的方式進行追蹤。 建立一或多個驗證規則，可讓您在傳送特定文字做為回應時設陷，以便驗證失敗，並將要求標示為錯誤。 例如，在 Visual Studio Team System (Team Test Load Agent 中) 簡單的驗證規則可能是 ResponseUrl 驗證 - 如果重新導向之後轉譯的頁面與測試中記錄的回應頁面不同，則會記錄失敗。 您也可以新增 FindText 規則，如果在回應中找到「拒絕存取」一詞，則會記錄失敗。
在不同角色中使用多個使用者，以進行測試。 特定行為 (例如輸出快取) 會以不同方式運作，取決於目前使用者的權限。 例如，網站集合管理員或具有核准或撰寫許可權的已驗證使用者將不會取得快取的結果，因為我們一律希望他們查看最新版本的內容。 不過，匿名使用者將會得到快取內容。 您需要確定您的測試使用者混合使用這些角色，而它們大致符合生產環境中混合的使用者。 例如，在生產環境中，可能只有兩個或三個網站集合管理員，因此您不應該建立測試，其中 10% 的頁面要求是由網站集合系統管理員的使用者帳戶對測試內容發出。
剖析相依要求是 Visual Studio Team System (Team Test Load Agent) 的屬性，其會判定測試代理程式是否應該嘗試只擷取頁面，或擷取頁面和屬於頁面的所有相關聯要求，例如影像、樣式屬性表、指令碼等等。進行負載測試時，通常會基於幾個原因而忽略這些項目：
在使用者第一次點擊網站之後，本機瀏覽器通常會快取這些項目
在 SharePoint Server 2013 環境中，這些項目通常不是來自 SQL Server。 開啟 BLOB 快取後，Web 伺服器會改為提供它們，使其不會產生 SQL Server 負載。
如果首次使用者經常有很高百分比造訪您的網站，或您已停用瀏覽器快取，或者基於某種原因而不打算使用 Blob 快取，則在您的測試中啟用剖析相依要求可能就有意義。 不過，對於大部分的實作，這是例外狀況，也不是經驗法則。 請注意，如果您真的開啟此功能，則它可能使測試控制器所報告的 RPS 數目明顯上漲。 這些要求的提供速度如此之快，可能會讓您誤以為伺服器數位中可用的容量比實際的容量還多。
請記住，也要為客戶端應用程式活動建立模型。 Microsoft Word、PowerPoint、Excel 和 Outlook 等用戶端應用程式也會產生對 SharePoint Server 2013 伺服器陣列的要求。 它們會透過傳送伺服器要求 (例如擷取 RSS 摘要、取得社交資訊、要求網站和清單結構的詳細資訊、同步處理資料等等)，將負載新增至環境。如果您的實作中具有這些用戶端，則應該包含這些類型的要求，以及建立其模型。
在大多數情況下，Web 測試應該只包含單一要求。 如果測試只包含單一要求，則可以更輕鬆地對測試載入器和個別要求進行微調和疑難排除。 如果模擬 Web 測試的作業是由多個要求所組成，則 Web 測試通常需要包含多個要求。 例如，若要測試這組動作，您需要有多個步驟的測試：簽出檔、編輯檔、簽入併發佈檔。 它也需要保留步驟之間的狀態 - -例如，相同的使用者帳戶應該用來簽出文件、進行編輯，然後重新簽入文件。 需要狀態在每個步驟之間推進的這些多步驟作業，最好由單一 Web 測試中的多個要求提供服務。
個別測試每一個 Web 測試。 確定每一個測試都能夠順利完成，然後在更大的負載測試中執行它。 確認，Web 應用程式的所有名稱均可解析，並確認測試中使用的使用者帳戶有足夠權限來執行測試。
Web 測試包含要求個別頁面、上傳文件、檢視清單項目等等。在負載測試中，會將這些項目拉在一起。 您可以在負載測試中插入即將執行的所有不同 Web 測試。 每一個 Web 測試都有特定百分比的執行時間 - 例如，如果您發現生產伺服器陣列中的 10% 要求是搜尋查詢，則在負載測試中，您將設定查詢 Web 測試，以執行 10% 的時間。 在 Visual Studio Team System (Team Test Load Agent) 中，負載測試也是您配置瀏覽器混合、網路混合、負載模式和執行設定等內容的方式。
有一些應該針對負載測試遵守並實作的額外最佳做法：
在測試中使用合理的讀取/寫入速率。 測試中的寫入次數若超載，可能會嚴重影響測試的整體輸送量。 即使在共同作業伺服器陣列上，讀取/寫入比例往往是讀取比寫入還要多。
考慮對其他使用大量資源的作業所造成的影響，並判定它們是否應該在負載測試期間發生。 例如，備份和還原這類作業通常不會在負載測試期間完成。 完整搜尋編目可能通常不會在負載測試期間執行，而增量編目可能正常執行。 您需要考慮如何在生產中排定這些工作 - 它們將在尖峰負載時間執行嗎？ 如果沒有，則可能會在負載測試期間排除這些負載，當您嘗試判斷可支援尖峰流量的最大穩定狀態負載時。
請不要使用思考時間。 思考時間是 Visual Studio Team System (Team Test Load Agent) 的一種特性，可讓您模擬使用者在按一下頁面之間暫停的時間。 例如，一般使用者可能會載入頁面、花費三分鐘進行閱讀，然後按一下 頁面上的連結，以造訪另一個網站。 嘗試在測試環境中建立此情況的模型幾乎不可能正確完成，並且實際上不會為測試結果增加價值。 建立模型很因難，因為大多數組織沒有方法來監視不同的使用者，以及他們在按一下不同類型 SharePoint 網站 (例如發佈與搜尋與共同作業等) 之間所花費的時間。 它也不會真正增加值，因為即使使用者可能會在頁面要求之間暫停，SharePoint Server 2013 伺服器也不會這麼做。 它們只會取得一連串穩定的要求，而這些要求可能會隨著時間而有尖峰和矽谷，但不會因為每個使用者在單擊頁面上的連結之間暫停而Idly等候。
了解使用者與要求之間的差異。 Visual Studio Team System (Team Test Load Agent) 具有負載模式，在這裡它會要求您輸入要模擬的使用者數目。 這與應用程式使用者沒有任何關聯，只是負載測試代理程式上將使用多少個線程來產生要求。 例如，一個常見的錯誤是，假設部署將會有 5,000 個使用者，則 5,000 是應該在 Visual Studio Team System (Team Test Load Agent) 中使用的數位，但並非如此！ 這是為什麼在估計容量規劃需求時，用量需求應該基於每秒要求數而不是使用者數目的眾多原因之一。 在 Visual Studio Team System (Team Test Load Agent) 負載測試中，您會發現您通常每秒只能使用 50 到 75 個負載測試「使用者」來產生數百個要求。
使用固定的負載模式，以取得最可靠且可以重現的測試結果。 在 Visual Studio Team System (Team Test Load Agent) 中，您可以選擇將負載以常數的使用者 (線程為基礎，如上一點) 中所述，使用者的負載增加模式或以目標為基礎的使用量測試中所述。 逐步負載模型指的是從較低數目的使用者開始，然後每隔幾分鐘「逐步」增加額外使用者。 目標型用量測試指的是建立特定診斷計數器 (例如 CPU 使用率) 的臨界值，而且測試會嘗試推動負載，使計數器保持在您為它定義的最小臨界值和最大臨界值之間。 不過，如果您只是嘗試判斷 SharePoint Server 2013 伺服器陣列在尖峰負載期間可以維持的最大輸送量，則只挑選常數負載模式會更有效率且更精確。 這可讓您更輕鬆找出系統在開始定期超出應在良好伺服器陣列中維護的臨界值之前可以承擔多少負載。
每次執行負載測試時，請記住它會變更資料庫中的數據。 無論上傳文件、編輯清單項目，或只是記錄用量資料庫中的活動，都會有資料寫入至 SQL Server。 若要確保來自每個負載測試的一組測試結果一致且合法，您應該在執行第一個負載測試之前具有可用的備份。 完成每個負載測試之後，應該使用備份將內容還原回原方式，也就是在測試開始之前。
另請參閱
概念
SharePoint Server 2016 的軟體界限及限制
其他資源
Capacity management and sizing overview for SharePoint Server 2013