SharePoint Server 2013 的效能測試
適用于：
2013 
2019 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 型電腦上。 您使用的 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 (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、ID 等。將這些硬式編碼值取代為 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 快取時，改為網頁伺服器為它們提供服務，因此它們不會產生 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 (Team Test Load Agent) 的一種特性，可讓您模擬使用者在按一下頁面之間暫停的時間。 例如，一般使用者可能會載入頁面、花費三分鐘進行閱讀，然後按一下 頁面上的連結，以造訪另一個網站。 嘗試在測試環境中建立此情況的模型幾乎不可能正確完成，並且實際上不會為測試結果增加價值。 建立模型很因難，因為大多數組織沒有方法來監視不同的使用者，以及他們在按一下不同類型 SharePoint 網站 (例如發佈與搜尋與共同作業等) 之間所花費的時間。 它也不會真正增加價值，因為即使使用者可以在網頁要求之間暫停，但 SharePoint Server 2013 伺服器做不到。 他們只是獲得了源源不斷的要求，而這些要求隨著時間推移可能會有峰值和谷值，但是當每個使用者在按一下頁面上的連結之間暫停時，它們不會閒置等待。
了解使用者與要求之間的差異。 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