本文為機器翻譯文章。如需檢視英文版,請選取 [原文] 核取方塊。您也可以將滑鼠指標移到文字上,即可在快顯視窗顯示英文原文。
譯文
原文

SharePoint Server 2013 的效能測試

 

適用版本:SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard

上次修改主題的時間:2013-12-18

摘要:了解如何規劃及執行 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 (Team Test Load Agent) 進行測試,其中一部機器會作為負載測試控制站。通常會有 2 部以上的機器作為負載測試代理程式。代理程式是從測試控制站取得測試相關說明的機器,並將要求發送至 SharePoint Server 2013 伺服器陣列。測試結果本身會儲存於以 SQL Server 為基礎的電腦。您不應該使用與用於 SharePoint Server 2013 伺服器陣列相同之以 SQL Server 為基礎的電腦,因為寫入測試資料扭曲 SharePoint Server 2013 伺服器陣列的可用 SQL Server 資源。執行測試時,您也需要利用與監視 SharePoint Server 2013 伺服器陣列之伺服器的相同方式,來監視測試伺服器或網域控制台等等,以確定測試結果代表您設定的伺服器陣列。負載代理程式或控制台有時候會變成本身的瓶頸。如果發生此情況,則您在測試中看見的輸送量通常不會是伺服器陣列可支援的上限。

  • SQL Server:在您的測試環境中,遵循本文<規劃及設定儲存設備與 SQL Server 容量 (SharePoint Server 2013)>中的<設定 SQL Server>和<驗證並監視儲存以及 SQL Server 效能>。

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

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

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

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

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

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

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

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

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

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

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

在測試環境可正常運作之後,即可建立並微調用來評估伺服器陣列之效能的測試。本章節將不時地特別參照至 Visual Studio Team System (Team Test Load Agent),但是無論您使用何種負載測試工具,許多概念皆適用。如需 Visual Studio Team System 的詳細資訊,請參閱 MSDN 的 Visual Studio Team System (http://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 下載中心 (http://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e&displaylang=en) 取得。

測試成功的關鍵準則是藉由在廣泛的測試網站資料中產生要求,(正如使用者在實際執行 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 測試而言,它只會以正面回應顯示,因為您會在負載測試結果中取得 HTTP 狀態碼 200 (成功)。顯然地,雖然發生錯誤,但應該以不同的方式追蹤。以回應發送某些文字時,建立一個或多個規則,以便在驗證失敗以及要求標記為失敗時,供您截獲。例如,在 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 個使用者,則 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 2013 伺服器陣列在尖峰負載期間可承受的輸送量上限,僅選用常數負載模式會更有效更準確。這麼做可讓您在經常超出正常運作之伺服器陣列中應維持的臨界值之前,輕鬆了解系統可承擔的負載量。

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

https://technet.microsoft.com/zh-tw/library/cc262787.aspx
顯示: