共用方式為

SharePoint Server 2010 效能測試

  • 發行項

 

適用版本： SharePoint Server 2010

上次修改主題的時間： 2016-11-30

本文說明如何測試 Microsoft SharePoint Server 2010 的效能。測試及最佳化階段在有效的容量管理中是很重要的一環。在將新架構部署至實際作業前，您應該先測試並搭配下列監視最佳作法以執行接受度測試，以確保所設定的架構能達到效能與容量目標。如此才能於潛在的瓶頸影響到實際部署的使用者前，讓您將其識別出來並最佳化。若您是從 Microsoft Office SharePoint Server 2007 環境升級，並打算要變更架構，或正在評估 SharePoint Server 2010 新功能的使用者負載，則測試對於採用 SharePoint Server 2010 的新環境能否達到預定的效能與容量目標來說即格外重要。

一旦測試過環境，即可分析測試結果並判定為了達到您在＜SharePoint Server 2010 的容量規劃＞的步驟 1：模型中建立的效能與容量目標，還需要做哪些變更。

這些是建議您在實際執行前應執行的子步驟：

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

  • 以您在＜步驟 1：模型＞中識別的資料集或資料集部分填入存放區。

  • 以代表您在＜步驟 1：模型＞中識別之工作量的綜合負載對系統施壓。

  • 執行測試、分析結果，然後最佳化架構。

  • 在資料中心部署經過最佳化的架構，然後導入少量使用者進行試驗。

  • 分析試驗結果、識別潛在瓶頸，然後最佳化架構。請在必要時重新測試。

  • 部署至實際執行環境。

閱讀本文之前，您應該先閱讀＜SharePoint Server 2010 的容量管理與縮放概觀＞。

本文內容：

  • 建立測試計畫

  • 建立測試環境

  • 建立測試及工具

建立測試計畫

確定您的規劃包括：

  • 設計用來操作預期生產效能目標的硬體。您應總是保守地測量測試系統效能。

  • 若您有自訂程式碼或自訂元件，則應先在隔離環境中測試這些元件的效能與穩定性。確定其穩定後，再測試安裝了這些元件的系統，並與未安裝這些元件的伺服器陣列效能做比較。因為，自訂元件通常是實際作業系統中效能與可靠性問題的罪魁禍首。

  • 了解您的測試目標。事先了解您的測試目標為何：是要驗證為伺服器陣列開發的一些新自訂元件效能？還是要查看編目與索引一組內容要花多長時間？還是要判定您的伺服器陣列每秒可支援多少要求？測試可以有多種目標，而良好測試規劃的第一個步驟就是要決定目標為何。

  • 了解如何測量測試目標。舉例來說，若您想要測量伺服器陣列的輸送量，則會想要測量 RPS 及頁面延遲。若您要測量搜尋效能，則會想要測量編目時間與文件索引比例。若您測試的目標很明確，您就能清楚定義出要完成測試需要驗證哪些關鍵的效能指標。

建立測試環境

一旦您已決定測試目標也定義出測量值，且針對伺服器陣列在本程序步驟 1 和 2 的容量需求也已定義出來後，下一個目標就是設計與建立測試環境。建立測試環境所需的投入通常被低估了，其實應儘可能複製到愈貼近實際執行環境愈好。在設計測試環境時，您應考慮的一些功能包括：

  • 驗證 – 決定伺服器陣列是要使用 Active Directory 網域服務 (AD DS)、表單型驗證 (若是，要搭配哪個目錄)、宣告式驗證等。不論要使用哪個目錄，您的測試環境中需要多少使用者？以及要如何建立這些使用者？您將需要多少群組或角色？以及要怎麼建立與填入他們？您也需要確認驗證服務配置的資源充足，以免成為測試期間的瓶頸。

  • DNS – 了解測試期間所需的命名空間為何。識別出哪些伺服器負責回應這些要求，並確定您已包括一份規劃，其中訂出哪部伺服器使用哪些 IP 位址，以及該建立哪些 DNS 項目。

  • 負載平衡 – 假設您使用一部以上的伺服器 (其中負載應該可以也可能無法支撐負載測試)，即需要負載平衡解決方案。這可以是硬體負載平衡裝置，或如 Windows NLB 之類的軟體負載平衡。考慮好您要使用哪一種，然後寫下所有需要的設定資訊，以利快速及有效率地設定。另外要記住的一點是負載測試代理程式通常只會每 30 分鐘將位址解析為 URL 一次，也就是說，您應避免使用本機主機檔案或循環配置 DNS 來負載平衡，否則測試代理程式可能會將每個要求送至同一部伺服器，而不是平衡在所有可用伺服器之間。

  • 測試伺服器 – 在規劃測試環境時，您不只要為 SharePoint Server 2010 伺服器陣列的伺服器做規劃，您還需要為執行測試所需的機器做好規劃。一般來說最少應包括三部伺服器，也可能需要更多。若您使用 Visual Studio Team System (Team Test Load Agent) 來做測試，則會需要一部機器來當負載測試控制站。因此，若使用負載測試代理程式，一般會需要兩部以上的機器。代理程式是從測試控制站接收指令的機器，其會接收要測試的項目並將要求發送至 SharePoint Server 2010 伺服器陣列。測試結果則會自行儲存在 SQL Server 型電腦上。您不應與 SharePoint Server 2010 伺服器陣列共用相同的一部 SQL Server 型電腦，因為寫入測試資料會導致 SharePoint Server 2010 伺服器陣列沒有可用的 SQL Server 資源。執行測試時，您也需要用監視 SharePoint Server 2010 伺服器陣列的伺服器或網域控制站等之相同方式，來監視測試伺服器，確保測試結果能完全代表您所設定的伺服器陣列。有時候，負載代理程式或控制站本身會變成瓶頸。當這種情況發生時，測試中所見的輸送量通常就不是伺服器陣列可支援的最大上限。

  • SQL Server – 在測試環境中，請遵循＜規劃及設定儲存空間及 SQL Server 容量 (SharePoint Server 2010)＞文章中＜設定 SQL Server＞及＜驗證並監視儲存空間及 SQL Server 效能＞一節的指示。

  • 資料集驗證 – 在決定要針對哪些內容執行測試後，請記得，最好的情況是使用現有實際作業系統中的資料。例如，您可以備份實際作業伺服器陣列的內容資料庫，並將其還原在測試環境中，之後再附加資料庫以將資料引進伺服器陣列。若用捏造的或資料範例來執行測試，則會因為內容主體不同而有結果不可取的風險。

若您非要建立資料範例不可，在您建立內容時要謹記幾點考量：

  • 所有頁面都應發佈，且不應取出任何項目

  • 導覽應是實際可行的，建置不應超出實際作業中預期的合理範圍。

  • 您應了解實際執行的網站所要使用的自訂。例如測試環境中實作的主版頁面、樣式表、JavaScript 等等，皆應儘可能地貼近實際執行環境。

  • 判斷需要多少 SharePoint 群組及/或權限等級，以及要如何將使用者與其相關聯。

  • 考慮是否需要做設定檔匯入以及要花多長時間。

  • 判斷是否需要「對象」，以及如何建立及填入他們。

  • 判斷是否需要其他搜尋內容來源，以及需要什麼才能建立它們。若不需要建立，則判斷是否需要網路存取才能將其編目。

  • 判斷是否有足夠的資料範例 – 文件、清單、清單項目等等。若否，則規劃該如何建立這些內容。

  • 擁有足夠獨特的內容以充分測試搜尋。常見的錯誤是將相同文件以不同文件名重複上傳至不同文件庫 (多達上百次或上千次)。這會影響搜尋效能，因為查詢處理器會花大量時間來做重複偵測，而這在實際執行環境中的實際內容搜尋上是不會有這種情形的。

建立測試及工具

在測試環境可運作後，就可以建立並微調用來測量伺服器陣列的效能容量之測試。本節內容有時會針對 Visual Studio Team System (Team Test Load Agent) 來提供參考，但不論您使用何種負載測試工具，大多數的概念都仍適用。如需 Visual Studio Team System 的詳細資訊，請參閱 MSDN 上的 Visual Studio Team System(可能為英文網頁)(https://msdn.microsoft.com/zh-tw/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)(可能為英文網頁) (英文) 取得。

另一個測試成功的關鍵準則就是能有效模擬實際工作量，這需要產生廣泛的測試網站資料要求，就像使用者能在實際作業 SharePoint Server 2010 伺服器陣列中存取廣泛內容一樣。要做到這一點，您必須進行資料驅動的測試。與其建立上百種硬式編碼來存取特定頁面的測試，您不如使用含有這些項目之 URL 的資料來源，動態存取該組頁面，這樣就只要做少量測試即可達到效果。

Visual Studio Team System (Team Test Load Agent) 中，資料來源可以有各種不同格式，但通常在開發與測試環境中最容易管理及傳送的是 CSV 檔案格式。請謹記建立搭配內容的 CSV 檔可能需要自訂工具，以列舉 SharePoint Server 2010 環境並記錄使用的各種 URL。

針對下列工作，您可能會需要使用工具：

  • 在 Active Directory 或其他驗證存放區建立使用者及群組 (若使用表單型驗證)

  • 列舉網站、清單和程式庫、清單項目、文件等的 URL，並將其放進 CSV 檔以利負載測試

  • 將範例文件上傳至一個範圍的文件庫和網站

  • 建立網站集合、網站、清單、文件庫、資料夾及清單項目

  • 建立我的網站

  • 用測試使用者 (負載測試會以這些使用者帳戶來執行) 的使用者名稱與密碼建立 CSV 檔。這些應該是分開的多個檔案，例如，有些僅包含管理員使用者，有些包含特殊權限 (如作者 / 參與者、階層管理者等) 使用者，而其他可能包含讀者，諸如此類。

  • 建立範例搜尋關鍵字及詞組的清單

  • 填入使用者的 SharePoint 群組與權限等級，以及 Active Directory 群組 (若使用表單型驗證，則為角色)

建立 Web 測試時，還有其他應該觀察與實作的最佳作法，包括：

  • 將簡單的 Web 測試記錄為起點。這些測試當中會具備參數之硬式編碼的值，如 URL、識別碼等，請將這些硬式編碼的值取代為您 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) 的一個屬性，其會判斷測試代理程式是否應該單純擷取頁面，還是要連頁面的所有相關要求 (如圖片、樣式表、指令碼等等) 都擷取。這些項目在測試負載時，通常會基於下列原因而忽略：

    • 使用者初次點閱網站後，通常本機瀏覽器會將這些項目快取

    • 這些項目通常不是來自 SharePoint Server 2010 環境的 SQL Server。在開啟 BLOB 快取時，這些項目就會改由網頁伺服器提供，因此不會造成 SQL Server 負載。

若您的網站按時會有高比例的初次使用者造訪，或您停用瀏覽器快取，或基於某些原因您不想使用 BLOB 快取，則在測試中啟用剖析依存要求是可以理解的。不過，這其實算是例外，且在多數實作中都不屬於上策。請注意若您開啟這個屬性，其會大幅抬升測試控制站報告的 RPS 數目。這些要求會很快地提供，而讓您誤以為伺服器陣列有更多可用的容量，但實際上卻不是。

  • 記得也要為用戶端應用程式活動建立模型。用戶端應用程式，如 Microsoft Word、PowerPoint、Excel 及 Outlook 也會對 SharePoint Server 2010 伺服器陣列產生要求，其會藉由傳送要求 (如擷取 RSS 摘要、取得社交資訊、要求網站及清單結構的詳細資料、同步處理資料等) 至伺服器，來增加環境的負載。若您的實作中有這些用戶端，則應包括這類型的要求並製作模型。

  • 在大多數情況中，Web 測試應只包含單一要求，因為若測試只包含單一要求，要微調與疑難排解測試問題與個別要求就更加容易。一般來說，若模擬的作業是由多個要求所組成，Web 測試就需要包含多個要求。例如，若您的測試需要：取出文件、將之編輯、存回文件並將之發佈，這多個步驟來測試此組動作，且在步驟間也需要保留狀態 – 如，應使用相同使用者帳戶將文件取出、編輯並存回。這些多步驟作業 (其狀態需要在每個步驟間進展)，最好由單一 Web 測試的多項要求來提供。

  • 個別測試每個 Web 測試。請先確定每個測試都能順利完成，再將測試執行至較大型的負載測試。確認所有 Web 應用程式的名稱都已解析，且用於測試的使用者帳戶都具備了執行測試的足夠權限。

Web 測試組成個別頁面、上傳文件、檢視清單項目等的要求，而這些所有要求都會擷取至負載測試中。您會將所有要執行之不同 Web 測試插入負載測試中。每個 Web 測試都可限定一個執行時間的百分比 – 例如，若您發現實際作業伺服器陣列中有 10% 的要求是搜尋查詢，您可在負載測試中將查詢 Web 測試設定為執行 10% 的時間。在 Visual Studio Team System (Team Test Load Agent) 中，負載測試也可以是您設定 (瀏覽器混合、網路混合、負載模式) 與執行設定的方式。

針對負載測試，您還應該觀察與實作一些其他最佳作法：

  • 在測試中使用合理的讀寫比例。在測試中寫入數量超載會大幅影響測試的整體輸送量。即使在共同作業伺服器陣列上，讀寫比例也是讀取高於寫入。如需詳細資訊，請參閱＜Performance and capacity technical case studies (SharePoint Server 2010)＞。

  • 考量其他耗資源之作業的影響，並決定在負載測試期間是否要出現這些作業。例如，備份及還原之類的作業通常不會在負載測試期間執行。而且，在負載期間通常不會執行完整的搜尋編目，不過累加式編目就比較尋常。您需要考慮實際作業中，這些工作是如何排程，是否會在尖峰負載時間執行？若否，在您要判斷尖峰流量可支援的穩定負載上限時，就應該在負載測試期間排除這些工作。

  • 請不要使用考慮時間。考慮時間是 Visual Studio Team System (Team Test Load Agent) 的一項功能，可模擬使用者在頁面點擊之間的暫停時間。例如，一般的使用者可能會載入頁面、花三分鐘來閱讀，然後按一下頁面的連結造訪其他網站。要在測試環境中正確模型化這種動作幾乎是不可能的，且對測試結果不會增加什麼有效的價值。其不可行主要是因為組織沒有辦法監視不同使用者，以及其在不同種類的 SharePoint 網站 (如發佈、搜尋與共同作業等等) 之間點擊所花的時間。就算使用者可能在頁面要求間暫停，SharePoint Server 2010 型伺服器也不會因此暫停，因此這樣做沒有任何附加價值。這些伺服器只會收到穩定的要求資料流，雖然一段時間內會有尖峰與低點，但卻不會因為每個使用者在點擊頁面連結間的暫停就閒置等待。

  • 了解使用者與要求的差異。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 (Team Test Load Agent) 中，您可以選擇要基於持續的使用者數量 (執行緒，如前一點所述)、漸增的使用者負載模式或目標型使用量測試。漸增的負載模式是指您一開始用較少的使用者數，之後再每幾分鐘「漸增」其他使用者。目標型使用量測試是指您為特定診斷計數器 (如 CPU 使用率) 建立一個臨界值，然後測試會盡量驅動負載，以保持計數器維持在您所定義的臨界值之上限與下限之間。不過，若您只是想判定 SharePoint Server 2010 伺服器陣列在尖峰負載期間可維持的最大輸送量，單純使用持續負載模式會更有效率及精準。這樣可讓您更輕易地識別出系統可承受的負載後，再開始按時超出狀況良好之伺服器陣列可維持的臨界值。

每當您執行負載測試時，請記得這會變更資料庫中的資料。不論是上傳文件、編輯清單項目或只是記錄使用狀況資料庫中的活動，都會產生要寫入至 SQL Server 的資料。若要確保每個負載測試的測試結果組都一致且合法，您應該在執行首次的負載測試前先將備份準備好。在每個負載測試都完成後，即可用備份來將內容還原回測試開始前的狀態。

See Also

Concepts

SharePoint Server 2010 的容量管理與縮放概觀
SharePoint Server 2010 的容量規劃
監視及維護 SharePoint Server 2010
狀況監視 (SharePoint Server 2010)
規劃及設定儲存空間及 SQL Server 容量 (SharePoint Server 2010)