SharePoint Server 2013 的效能測試Performance testing for SharePoint Server 2013

摘要:了解如何規劃及執行 SharePoint Server 2013 環境的效能測試。Summary: Learn about how to plan and execute performance testing of a SharePoint Server 2013 environment.

本文說明如何測試 SharePoint Server 2013 的效能。測試和最佳化階段是有效的容量管理的重要元件。您應測試新架構再將其部署至實際執行環境與您應該進行接受度測試搭配下列監控的最佳作法以確保您設計的架構達到效能與容量目標。這可讓您識別和最佳化的潛在瓶頸之前所影響的實際部署中的使用者。如果您要從 Office SharePoint Server 2007 環境及計劃進行結構變更升級或所評估的 SharePoint Server 2013 新功能,然後測試以確定您新 SharePoint Server 2013-特別重要的使用者負載根據的環境將符合效能和容量目標。This article describes how to test the performance of SharePoint Server 2013. The testing and optimization stage is a critical component of effective capacity management. You should test new architectures before you deploy them to production and you should conduct acceptance testing in conjunction with following monitoring best practices in order to ensure the architectures you design achieve the performance and capacity targets. This allows you to identify and optimize potential bottlenecks before they impact users in a live deployment. If you are upgrading from an Office SharePoint Server 2007 environment and plan to make architectural changes, or are estimating user load of the new SharePoint Server 2013 features, then testing particularly important to make sure your new SharePoint Server 2013-based environment will meet performance and capacity targets.

一旦測試您的環境、 您可以分析測試結果,以決定變更需要進行以達到效能與容量所談的是您在建立步驟 1: 模型容量規劃 SharePoint Server 2013.Once you have tested your environment, you can analyze the test results to determine what changes need to be made in order to achieve the performance and capacity targets you established in Step 1: Model of Capacity planning for SharePoint Server 2013.

這些是您針對實際執行前應該遵循的子步驟:These are the recommended sub steps you should follow for pre-production:

  • 建立測試環境,模擬您在設計的初始架構步驟 2: 設計Create the test environment that mimics the initial architecture you designed in Step 2: Design.

  • 填入存放區的資料集或您已識別中的資料集的一部分步驟 1: 模型Populate the storage with the dataset or part of the dataset that you've identified in Step 1: Model.

  • 對系統施加代表已中所識別之工作量的綜合負載電腦步驟 1: 模型Stress the system with synthetic load that represents the workload you've identified in Step 1: Model.

  • 執行測試、分析、結果,並最佳化您的架構。Run tests, analyze results, and optimize your architecture.

  • 在資料中心中部署您的最佳化架構,並將較小的一組使用者導入試驗。Deploy your optimized architecture in your data center, and roll out a pilot with a smaller set of users.

  • 分析試驗結果,找出瓶頸,並最佳化架構。如果需要的話,可以重新測試。Analyze the pilot results, identify potential bottlenecks, and optimize the architecture. Retest if needed.

  • 部署實際執行環境。Deploy to the production environment.

閱讀本文之前,您應閱讀容量管理與調整大小概觀 (英文) SharePoint Server 2013Before you read this article, you should read Capacity management and sizing overview for SharePoint Server 2013.

建立測試規劃Create a Test Plan

確認您的規劃包含:Verify that your plan includes:

  • 設計用於在預期實際執行效能目標上操作的硬體。始終謹慎地評估測試系統的效能。Hardware that is designed to operate at expected production performance targets. Always measure the performance of test systems conservatively.

  • 如果您有自訂程式碼或自訂元件,先測試這些隔離元件的效能以驗證其效能與穩定性,是相當重要的。測試其穩定之後,您應該測試包含這些已安裝元件的系統,並針對不含這些已安裝元件的伺服器陣列比較效能。自訂元件通常是實際執行系統中效能與可靠性問題的主要肇因。If you have custom code or custom component, it is important that you test the performance of those components in isolation first to validate their performance and stability. After they are stable, you should test the system with those components installed and compare performance to the farm without them installed. Custom components are often a major culprit of performance and reliability problems in production systems.

  • 認識您的測試目標。提前了解您的測試目標為何。其是否可驗證對伺服器陣列所開發之某些新自訂元件的效能?其是否可看出編目及索引一套內容所需花費的時間?其是否可判斷您的伺服器陣列每秒可支援多少要求?測試期間可以有許多不同目標,而發展一個優秀測試計劃的第一步即為決定您的目標為何。Know the goal of your testing. Understand ahead of time what your testing objectives are. Is it to validate the performance of some new custom components that were developed for the farm? Is it to see how long it will take to crawl and index a set of content? Is it to determine how many requests per second your farm can support? There can be many different objectives during a test, and the first step in developing a good test plan is deciding what your objectives are.

  • 了解如何評估您的測試目標。例如,如果您對評估伺服器陣列的輸送量感興趣,您會想要評估 RPS 和頁面延遲。如果您要評估搜尋效能,則會想要評估編目時間與文件索引效率。如果能充分了解測試目標,將有助於清楚定義您需要驗證的關鍵效能指標以完成測試。Understand how to measure for your testing goal. If you are interested in measuring the throughput capacity of your farm for example, you will want to measure the RPS and page latency. If you are measuring for search performance then you will want to measure crawl time and document indexing rates. If your testing objective is well understood, that will help you clearly define what key performance indicators you need to validate in order to complete your tests.

建立測試環境Create the Test Environment

決定測試目標之後,即已定義您的測量,並且已決定伺服器陣列的容量需求 (從處理程序的步驟 1 和步驟 2 得知),下一個目標將會是設定與建立測試環境。建立測試環境所耗費的心力常被低估。該環境應該儘可能複製成接近實際執行的環境。設計測試環境時,您應該考慮的部分功能包含:Once your test objectives have been decided, your measurements have been defined, and you have determined what the capacity requirements are for your farm (from steps 1 and 2 of this process), the next objective will be to design and create the test environment. The effort to create a test environment is often underestimated. It should duplicate the production environment as closely as possible. Some of the features and functionality you should consider when designing your test environment include:

  • 驗證: 決定是否在伺服器陣列會使用 Active Directory 網域服務 (AD DS)、 表單型驗證 (以及如果要使用何種目錄的話)、 等宣告式驗證。無論您使用的目錄,您需要在測試環境中多少使用者與您要如何建立其?多少群組或角色是您將需要與您要如何建立及填入他們?您也需要確定您擁有足夠配置給他們不在測試期間成為瓶頸驗證服務的資源。Authentication: Decide whether the farm will use Active Directory Domain Services (AD DS), forms-based authentication (and if so with what directory), claims-based authentication, etc. Regardless of which directory you are using, how many users do you need in your test environment and how are you going to create them? How many groups or roles are you going to need and how will you create and populate them? You also need to ensure that you have enough resources allocated to your authentication services that they don't become a bottleneck during testing.

  • DNS: 了解命名空間是您將需要在測試期間。找出哪些伺服器會回應這些要求並確定您已包含有何種 IP 的計劃地址會使用哪一部伺服器,並建立將需要何種 DNS 項目。DNS: Know what the namespaces are that you will need during your testing. Identify which servers will be responding to those requests and make sure you've included a plan that has what IP addresses will be used by which servers, and what DNS entries you will need to create.

  • 負載平衡: 假設您使用多部伺服器 (這通常會或可能不會有足夠的負載,保證負載測試) 需要某種負載平衡器解決方案。這可能會硬體負載平衡裝置,或您可以使用軟體負載平衡類似 Windows NLB。了解您將會使用以及寫下所有需要取得該快速且有效地設定的組態資訊。容易記住的另一項重點是負載測試代理程式通常是嘗試與位址解析 URL 只有一次每 30 分鐘。也就是說您應該不使用本機主機檔案或循環配置資源 DNS 負載平衡測試代理程式可能會因為結束向上移至每一個單一的要求,而不是平衡繞所有可用的伺服器相同的伺服器。Load balancing: Assuming you are using more than one server (which you normally would or you likely wouldn't have enough load to warrant load testing), you will need some kind of load balancer solution. That could be a hardware load balancing device, or you could use software load balancing like Windows NLB. Figure out what you will use and write down all of the configuration information you will need to get it set up quickly and efficiently. Another thing to remember is that load test agents typically try and resolve the address to a URL only once every 30 minutes. That means that you should not use a local hosts file or round robin DNS for load balancing because the test agents will likely end up going to the same server for every single request, instead of balancing around all available servers.

  • 測試伺服器: 當您規劃您的測試環境時,不只需要規劃 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 伺服器陣列中的伺服器或網域控制站,以確定等的測試結果是您要設定伺服器陣列的人。有時負載代理程式或控制站可會成為瓶頸本身。如果發生這種情況然後您在測試中看見的輸送量通常是不在伺服器陣列所能支援的最大值。Test servers: When you plan your test environment, you not only need to plan for the servers for the SharePoint Server 2013 farm, you also need to plan for the machines needed to execute the tests. Typically that will include 3 servers at a minimum; more may be necessary. If you are using Visual Studio Team System (Team Test Load Agent) to do the testing, one machine will be used as the load test controller. There are generally 2 or more machines that are used as load test agents. The agents are the machines that take the instructions from the test controller about what to test and issue the requests to the SharePoint Server 2013 farm. The test results themselves are stored on a SQL Server-based computer. You should not use the same SQL Server-based computer that is used for the SharePoint Server 2016 farm, because writing the test data will skew the available SQL Server resources for the SharePoint Server 2013 farm. You also need to monitor your test servers when running your tests, the same way as you would monitor the servers in the SharePoint Server 2013 farm, or domain controllers, etc. to make sure that the test results are representative of the farm you're setting up. Sometimes the load agents or controller can become the bottleneck themselves. If that happens then the throughput you see in your test is typically not the maximum the farm can support.

  • SQL Server: 在測試環境中,請遵循 「 設定 SQL Server"和"驗證並監視儲存空間及 SQL Server 效能"一節的指引文章儲存及 SQL Server capacity planning and configuration (SharePoint 中伺服器)SQL Server: In your test environment, follow the guidance in the sections "Configure SQL Server" and "Validate and monitor storage and SQL Server performance" in the article Storage and SQL Server capacity planning and configuration (SharePoint Server).

  • 資料集驗證: 當您決定要執行測試針對內容,請記得最佳狀態的案例中您要使用現有的實際執行系統的資料。例如,您可以從實際執行伺服器陣列備份內容資料庫並將它們還原至測試環境中,然後將內容移入的伺服器陣列資料庫附加。只要您執行測試針對所組成或範例資料,則會執行具有偏斜因為內容主體中的差異而結果的風險。Dataset validation: As you decide what content you are going to run tests against, remember that in the best case scenario you will use data from an existing production system. For example, you can back up your content databases from a production farm and restore them into your test environment, then attach the databases to bring the content into the farm. Anytime you run tests against made up or sample data, you run the risk of having your results skewed because of differences in your content corpus.

如果您必須建立範例資料,當您建立內容時,必須記住一些注意事項:If you do have to create sample data, there are a few considerations to keep in mind as you build out that content:

  • 應發佈所有頁面,不應該取出任何頁面All pages should be published; nothing should be checked out

  • 導覽應該切合實際,不要超出您在實際執行中使用的合理預期。Navigation should be realistic; don't build beyond what you would reasonably expect to use in production.

  • 您應該知道實際執行網站將使用的自訂項目。例如,主版頁面、樣式表、JavaScript 等等,全部在測試環境中實作的情況應該儘可能接近實際執行環境中實作的情況。You should have an idea of the customizations the production site will be using. For example, master pages, style sheets, JavaScript, etc. should all be implemented in the test environment as closely as possible to the production environment.

  • 決定您將需要多少 SharePoint 群組及/或權限層級,以及您要如何將使用者與其建立關聯。Determine how many SharePoint groups and/or permission levels you are going to need, and how you are going to associate users with them.

  • 了解您是否需要執行設定檔匯入,以及將花費的時間。Figure out whether you'll need to do profile imports, and how long that will take.

  • 決定您是否需要「對象」,以及您將如何建立並填入對象。Determine whether you'll need Audiences, and how you'll create and populate them.

  • 決定您是否需要其他搜尋內容來源,以及建立時所需要的項目。如果不需要建立,請判斷您是否具備網路存取權以對其進行編目。Determine whether you need additional search content sources, and what you will need to create them. If you won't need to create them, determine whether you'll have network access to be able to crawl them.

  • 決定您是否有足夠的範例資料集的文件、 清單、 清單項目等等。如果不是,建立的計劃建立此內容的方式。Determine whether you have enough sample data - documents, lists, list items, etc. If not, create a plan for how you will create this content.

  • 有充分測試搜尋足夠唯一內容的計劃。若要將相同的文件-也許數百或偶數數千的次數-上傳至不同的文件庫以不同的名稱是常見的錯誤。因為查詢處理器會花費的時間執行其有用否則必須與實際內容實際執行環境中的重複資料偵測座標量,可能會影響搜尋效能。Have a plan for enough unique content to adequately test search. A common mistake is to upload the same document - maybe hundreds or even thousands of times - to different document libraries with different names. That can impact search performance because the query processor will spend an ordinate amount of time doing duplicate detection that it wouldn't otherwise have to in a production environment with real content.

建立測試與工具Create Tests and Tools

測試環境可正常運作之後,該是時候來建立及微調會用來測量的伺服器陣列的效能容量測試。本節將有些時候進行特別 Visual Studio Team System (小組測試負載代理程式) 的參照,但有許多概念是適用不論您使用負載測試工具為何。如需 Visual Studio Team System 的詳細資訊,請參閱Visual Studio Team System在 MSDN (https://msdn.microsoft.com/en-us/library/fda2bad5.aspx")。After the test environment is functional, it is time to create and fine-tune the tests that will be used to measure the performance capacity of the farm. This section will at times make references specifically to Visual Studio Team System (Team Test Load Agent), but many of the concepts are applicable irrespective of which load test tool you use. For more information about Visual Studio Team System, see Visual Studio Team System at 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 產生綜合負載,作為容量計劃練習或升級前負載測試。You can also use the SharePoint Load Test Kit (LTK) in conjunction with VSTS for load testing of SharePoint 2010 farms. The Load Test Kit generates a Visual Studio Team System 2008 load test based on Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 IIS logs. The VSTS load test can be used to generate synthetic load against SharePoint Foundation 2010 or SharePoint Server 2010 as part of a capacity planning exercise or a pre-upgrade stress test.

Load Test Kit 包含在 Microsoft SharePoint 2010 Administration Toolkit v1.0,可從Microsoft 下載中心(http://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e&英文 http://www.microsoft.com/downloads/details.aspx?familyid=718447d8-0814-427a-81c3-c9c3d84c456e&displaylang=en)。The Load Test Kit is included in the Microsoft SharePoint 2010 Administration Toolkit v1.0, available from the Microsoft Download Center (http://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e&displaylang=en).

測試成功的重要準則是內容的要能夠有效率地模擬真實感化的工作負載測試網站資料、 各種不同產生要求就如同使用者會存取各種實際執行 SharePoint Server 2013 伺服器陣列中。若要這樣做,您通常需要建構等的資料進行測試。而不是建立百的個別測試的硬式編碼存取特定頁面,您應該使用少數測試,以動態方式存取的一組頁面使用包含這些項目的 Url 的資料來源。A key criterion to the success of the tests is to be able to effectively simulate a realistic workload by generating requests across a wide range of the test site data, just as users would access a wide range of content in a production SharePoint Server 2013 farm. In order to do that, you will typically need to construct your tests such that they are data driven. Rather than creating hundreds of individual tests that are hard-coded to access a specific page, you should use just a few tests that use data sources containing the URLs for those items to dynamically access that set of pages.

在 Visual Studio Team System (小組測試負載代理程式)、 資料來源可以在各種格式,甚至但 CSV 檔案格式通常是錄製到管理和開發及測試環境之間傳輸。請記住使用該內容建立 CSV 檔案可能會需要建立的自訂工具來列舉的 SharePoint Server 2013 為基礎的環境並記錄所使用的各種 Url。In Visual Studio Team System (Team Test Load Agent), a data source can come in a variety of formats, but a CSV file format is often easiest to manage and transport between development and test environments. Keep in mind that creating CSV files with that content might require the creation of custom tools to enumerate the SharePoint Server 2013-based environment and record the various URLs being used.

您可能需要針對工作使用以下工具:You may need to use tools for tasks like:

  • 如果您使用表單型驗證,請建立 Active Directory 中的使用者和群組,或其他驗證存放區Creating users and groups in Active Directory or other authentication store if you're using forms based authentication

  • 列舉網站 URL、清單與程式庫、清單項目、文件等等,並將其置於 CSV 檔案以供負載測試使用Enumerating URLs for sites, lists and libraries, list items, documents, etc. and putting them into CSV files for load tests

  • 在眾多文件庫與網站之間上傳範例文件Uploading sample documents across a range of document libraries and sites

  • 建立網站集合、Web、清單、程式庫、資料夾與清單項目Creating site collections, webs, lists, libraries, folders and list items

  • 建立「我的網站」Creating My Sites

  • 建立包含使用者名稱與密碼的 CSV 檔案以供測試使用者,這些是負載測試將執行的使用者帳戶。應該有多個檔案,例如,一些僅包含管理員使用者,一些包含具備較高權限的其他使用者 (例如作者/參與者、階層管理員等等),其他僅限讀取者之類。Creating CSV files with usernames and passwords for test users; these are the user accounts that the load tests will execute as. There should be multiple files so that, for example, some contain only administrator users, some contain other users with elevated privileges (like author / contributor, hierarchy manager, etc.), and others are only readers, etc.

  • 建立範例搜尋關鍵字與片語的清單Creating a list of sample search keywords and phrases

  • 透過使用者和 Active Directory 群組填入 SharePoint 群組與權限層級 (或者是如果您使用表單型驗證,請填入角色Populating SharePoint groups and permission levels with users and Active Directory groups (or roles if you are using forms based authentication)

建立 Web 測試時,有其他您應該遵守並執行的最佳作法。包含:When creating the web tests, there are other best practices that you should observe and implement. They include:

  • 從記錄簡單的 Web 測試開始。這些測試將具備參數的硬式編碼值,例如 URL、ID 等等。利用 CSV 檔案中的連結取代這些硬式編碼值。在 Visual Studio Team System (Team Test Load Agent) 中繫結這些值的資料相當簡單。Record simple web tests as a starting point. Those tests will have hard-coded values in them for parameters like URL, ID's, etc. Replace those hard-coded values with links from your CSV files. Data binding those values in Visual Studio Team System (Team Test Load Agent) is extremely easy.

  • 一律已測試的驗證規則。例如時要求] 頁面上,如果發生錯誤您會經常取得 error.aspx 頁面回應。從 web 測試觀點顯示成當成另一個正數回應,因為您取得 200 HTTP 狀態碼 (成功) 的負載測試結果。做了明顯改善錯誤發生上述使應該以不同方式追蹤。建立一或多個驗證規則可讓您設陷特定文字傳送成回應,則驗證會失敗並且要求標示為失敗時。例如,在 Visual Studio Team System (小組測試負載代理程式) 的簡單的驗證規則可能會 ResponseUrl 驗證-其記錄失敗如果呈現後重新導向頁面不是在測試中所記錄的相同回應頁面。您也可以新增如果發現 word 「 拒絕存取 」,例如以回應將記錄失敗的 FindText 規則。Always have validation rules for your test. For example, when requesting a page, if an error occurs you will often get the error.aspx page in response. From a web test perspective it appears as just another positive response, because you get an HTTP status code of 200 (successful) in the load test results. Obviously an error has occurred though so that should be tracked differently. Creating one or more validation rules allows you to trap when certain text is sent as a response so that the validation fails and the request is marked as a failure. For example, in Visual Studio Team System (Team Test Load Agent) a simple validation rule might be a ResponseUrl validation - it records a failure if the page that is rendered after redirects is not the same response page that was recorded in the test. You could also add a FindText rule that will record a failure if it finds the word "access denied", for example, in the response.

  • 使用不同角色中的多個使用者以供測試。某些行為 (例如輸出快取工作) 會根據目前使用者的權限而有所不同。例如,具備核准或撰寫權限的網站集合管理員或經過驗證的使用者將不會取得快取的結果,因為我們通常希望看見最新版本的內容。不過,匿名使用者將取得快取的內容。您必須確定您的測試使用者是這些角色的混合,其大致符合實際執行環境中的使用者混合。例如,在實際執行中可能只有兩個或三個網站管理員,因此,您不應該針對測試內容之網站集合管理員的使用者帳戶所進行的 10% 頁面要求建立測試。Use multiple users in different roles for tests. Certain behaviors such as output caching work differently depending on the rights of the current user. For example, a site collection administrator or an authenticated user with approval or authoring rights will not get cached results because we always want them to see the most current version of content. Anonymous users, however, will get the cached content. You need to make sure that your test users are in a mix of these roles that approximately matches the mix of users in the production environment. For example, in production there are probably only two or three site collection administrators, so you should not create tests where 10% of the page requests are made by user accounts that are site collection administrators over the test content.

  • 剖析相依要求是 Visual Studio Team System (Team Test Load Agent) 的一種屬性,可決定測試代理程式應該嘗試僅擷取頁面,或擷取頁面及屬於該頁面的所有相關要求,例如圖像、樣式表、指令碼等等。載入設定時,基於以下原因,通常會忽略這些項目:Parsing dependent requests is an attribute of a Visual Studio Team System (Team Test Load Agent) that determines whether the test agent should attempt to retrieve just the page, or the page and all associated requests that are part of the page, such as images, style sheets, scripts, etc. When load testing, we usually ignore these items for a few reasons:

    • 當使用者第一次瀏覽網站之後,通常會由本機瀏覽器快取這些項目After a user hits a site the first time these items are often cached by the local browser

    • 這些項目不通常是來自於 SQL Server 在 SharePoint Server 2013 環境中。使用 BLOB 快取開啟,他們會改用回應 Web 伺服器讓他們不產生 SQL Server 負載。These items don't typically come from SQL Server in a SharePoint Server 2013-based environment. With BLOB caching turned on, they are instead served by the Web servers so they don't generate SQL Server load.

如果您經常有高百分比的初次瀏覽網站的使用者,或者已停用瀏覽器快取,或基於某些原因,您不打算使用 BLOB 快取,則其對於在測試中啟用剖析相依要求應該是合理的。不過,這的確是例外情況,而且不是大多數實作的經驗法則。請注意,如果您確定要啟用,它會明顯地擴大由測試控制台回報的 RPS 數字。這些要求的處理速度非常快,可能會誤導您認為伺服器陣列中比實際擁有更多的可用容量。If you regularly have a high percentage of first time users to your site, or you have disabled browser caching, or for some reason you don't intend to use the blob cache, then it may make sense to enable parsing dependent requests in your tests. However this is really the exception and not the rule of thumb for most implementations. Be aware that if you do turn this on it can significantly inflate the RPS numbers reported by the test controller. These requests are served so quickly it may mislead you into thinking that there is more capacity available in the farm than there actually is.

  • 請記得模型用戶端應用程式活動,以及。用戶端應用程式,例如 Microsoft Word、 PowerPoint、 Excel 及 Outlook 產生要求送至 SharePoint Server 2013 伺服器陣列。他們藉由傳送伺服器要求如擷取 RSS 摘要、 取得社交資訊、 要求網站和清單結構的詳細資訊、 同步處理資料等加入環境的負載。應該包含並設定模型中如有這些用戶端實作這些類型的要求。Remember to model client application activity as well. Client applications, such as Microsoft Word, PowerPoint, Excel and Outlook generate requests to SharePoint Server 2013 farms as well. They add load to the environment by sending the server requests such as retrieving RSS feeds, acquiring social information, requesting details on site and list structure, synchronizing data, etc. These types of requests should be included and modeled if you have those clients in your implementation.

  • 在大多數情況下 web 測試應該只包含單一要求。很容易微調及疑難排解您的測試控管和個別的要求如果測試只包含單一要求。Web 測試通常必須包含多個要求如果它模擬的作業組成多個要求。例如,測試動作這組需要多個步驟的測試: 取出文件、 加以編輯、 存回並將其發佈。它也需要保留各步驟之間的狀態-例如相同的使用者帳戶應該用來取出、 進行編輯,並核取其備份中。這些多個步驟作業需要狀態向前執行每個步驟之間的最佳會回應由單一 web 測試中的多個要求。In most cases a web test should only contain a single request. It's easier to fine-tune and troubleshoot your testing harness and individual requests if the test only contains a single request. Web tests will typically need to contain multiple requests if the operation it is simulating is composed of multiple requests. For example, to test this set of actions you will need a test with multiple step: checking out a document, editing it, checking it in and publishing it. It also requires reserving state between the steps - for example, the same user account should be used to check it out, make the edits, and check it back in. Those multi-step operations that require state to be carried forward between each step are best served by multiple requests in a single web test.

  • 個別測試每一個 Web 測試。先確定可成功完成每一個測試,然後才可在較大的負載測試中執行。確認 Web 應用程式解析的所有名稱,而且測試中所使用的使用者帳戶具備足夠權限以執行測試。Test each web test individually. Make sure that each test is able to complete successfully before running it in a larger load test. Confirm that all of the names for web applications resolve, and that the user accounts used in the test have sufficient rights to execute the test.

Web 測試組成個別頁面、 上傳文件、 檢視清單項目等的要求。全部都已取出的一起負載測試。負載測試是您將插入用在所有要執行的不同的 web 測試。如果您發現 10%的要求在實際執行伺服器陣列中的搜尋查詢],然後負載測試中您想設定查詢 web 測試執行 10%的時間,每個 web 測試可以指定它將會執行-例如的時間百分比。在 Visual Studio Team System (小組測試負載代理程式),負載測試同時設定之類的瀏覽器混合、 網路混合、 負載模式及執行的設定的方式。Web tests comprise the requests for individual pages, uploading documents, view list items, etc. All of these are pulled together in load tests. A load test is where you plug in all of the different web tests that are going to be executed. Each web test can be given a percentage of time that it will execute - for example, if you find that 10% of requests in a production farm are search queries, then in the load test you would configure a query web test to run 10% of the time. In Visual Studio Team System (Team Test Load Agent), load tests are also how you configure things like the browser mix, network mix, load patterns, and run settings.

對於負載測試有某些其他的最佳作法應遵守並執行:There are some additional best practices that should be observed and implemented for load tests:

  • 在測試中使用合理的讀/寫比例。當測試中的寫入數目超載時,會明顯影響測試的整體輸送量。即使在共同作業伺服器陣列中,讀/寫比例往往傾向於讀取而非寫入。Use a reasonable read/write ratio in your tests. Overloading the number of writes in a test can significantly impact the overall throughput of a test. Even on collaboration farms, the read/write ratios tend to have many more reads than writes.

  • 請考慮的其他資源的影響密集的作業並決定是否時應發生負載測試期間。例如,類似備份與還原作業會不通常負載測試期間。完整的搜尋編目可能不是通常執行負載測試期間而累加編目可正常。您必須考慮這些工作排程在生產環境中的方式-他們執行在尖峰負載時間?如果不是,然後他們可能排除負載在測試期間,當您嘗試要判斷您可以支援的尖峰流量的最大穩定負載。Consider the impact of other resource intensive operations and decide whether they should be occurring during the load test. For example, operations like backup and restore are not generally done during a load test. A full search crawl may not be usually run during a load test, whereas an incremental crawl may be normal. You need to consider how those tasks will be scheduled in production - will they be running at peak load times? If not, then they should probably be excluded during load testing, when you are trying to determine the maximum steady state load you can support for peak traffic.

  • 請勿使用思考時間。思考時間是一種功能的 Visual Studio Team System (小組測試負載代理程式) 可讓您以模擬使用者暫停頁面上的點閱之間的時間。例如一般使用者可能會載入頁面,花費 3 分鐘讀取它,然後按一下以造訪另一個網站] 頁面上的連結。嘗試重新建立此模型的測試環境中執行正確,幾乎不可能而實際上不會將值新增至測試結果。很難模型因為大多數組織沒有一種方式來監視不同的使用者與在不同類型的 SharePoint 網站 (例如發佈與搜尋與共同作業、 等。) 按一下它們之間所花費的時間。它也不會真的加入值因為即使使用者可能會暫停頁面要求之間的 SharePoint Server 2013 為基礎的伺服器未執行。他們只是要取得穩定的資料流的要求可能會有尖峰量及谷地一段時間,但它們未等待這為每個使用者將游標暫停之間按一下頁面上的連結。Don't use think times. Think times are a feature of Visual Studio Team System (Team Test Load Agent) that allow you to simulate the time that users pause between clicks on a page. For example a typical user might load a page, spend three minutes reading it, then click a link on the page to visit another site. Trying to model this in a test environment is nearly impossible to do correctly, and effectively doesn't add value to the test results. It's difficult to model because most organizations don't have a way to monitor different users and the time they spend between clicks on different types of SharePoint sites (like publishing versus search versus collaboration, etc.). It also doesn't really add value because even though a user may pause between page requests, the SharePoint Server 2013-based servers do not. They just get a steady stream of requests that may have peaks and valleys over time, but they are not waiting idly as each user pauses between clicking links on a page.

  • 了解使用者及要求之間的差異。Visual Studio Team System (小組測試負載代理程式) 有其要求您輸入要模擬的使用者人數負載圖樣。這不會有任何執行的應用程式的使用者動作,它是真正只是多少執行緒會移至要在負載測試代理程式用來產生要求。常見的錯誤想法,如果部署例如擁有 5000 個使用者則 5000 應用於 Visual Studio Team System (小組測試負載代理程式) 的號碼--不 !這是其中一個許多原因為何時評估容量規劃需求、 使用需求應根據每秒要求數目和使用者不數目。在 Visual Studio Team System (小組測試負載代理程式) 負載測試,您會找到您可以通常產生上百個每秒使用要求僅 50 到 75 負載測試"users"。Understand the difference between users and requests. Visual Studio Team System (Team Test Load Agent) has load pattern where it asks you to enter the number of users to simulate. This doesn't have anything to do with application users, it's really just how many threads are going to be used on the load test agents to generate requests. A common mistake is thinking that if the deployment will have 5,000 users for example, then 5,000 is the number that should be used in Visual Studio Team System (Team Test Load Agent) - it is not! That's one of the many reasons why when estimating capacity planning requirements, the usage requirements should be based on number of requests per second and not number of users. In a Visual Studio Team System (Team Test Load Agent) load test, you will find that you can often generate hundreds of requests per second using only 50 to 75 load test "users".

  • 使用常數負載模式最可靠且可重現當測試結果。在 Visual Studio Team System (小組測試負載代理程式) 您有選擇審查負載的使用者 (執行緒,如先前點中所述),常數目而定逐步設定的使用者,負載模式或目標基礎使用狀況測試。開始使用較低的使用者數目,然後"步驟"新增其他使用者每隔幾分鐘時逐步的負載圖樣。建立計數器臨界值某些診斷、 like CPU 使用率和測試會嘗試將磁碟機之後要保留您定義的最小和最大閾值之間的計數器負載時的目標架構使用狀況測試。不過,如果您只嘗試判斷您的 SharePoint Server 2013 伺服器陣列可維持在尖峰負載期間的最大輸送量,最好是更具效率且正確只挑選常數負載模式。可讓您更輕鬆地識別系統能夠充分啟動定期超過臨界值應保留在狀況良好的伺服器陣列中的前多少負載。Use a constant load pattern for the most reliable and reproducible test results. In Visual Studio Team System (Team Test Load Agent) you have the option of basing load on a constant number of users (threads, as explained in the previous point), a stepped up load pattern of users, or a goal based usage test. A stepped load pattern is when you start with a lower number of users and then "step up" adding additional users every few minutes. A goal based usage test is when you establish a threshold for a certain diagnostic counter, like CPU utilization, and test attempts to drive the load to keep that counter between a minimum and maximum threshold that you define for it. However, if you are just trying to determine the maximum throughput your SharePoint Server 2013 farm can sustain during peak load, it is more effective and accurate to just pick a constant load pattern. That allows you to more easily identify how much load the system can take before starting to regularly exceed the thresholds that should be maintained in a healthy farm.

每次執行負載測試時,請記住它會在資料庫中變更資料。無論是上傳文件、編輯清單項目,或只是在使用狀況資料庫中記錄活動,皆會有資料寫入 SQL Server。若要確保每一個負載測試之測試結果集合的一致與合法,您應該先有一個可用的備份,才可執行第一個負載測試。完成每一個負載測試之後,備份應該將內容還原回測試開始之前的樣子。Each time you run a load test remember that it is changing data in the database. Whether that's uploading documents, editing list items, or just recording activity in the usage database, there will be data that is written to SQL Server. To ensure a consistent and legitimate set of test results from each load test, you should have a backup available before you run the first load test. After each load test is complete the backup should be used to restore the content back to the way it was before the test was started.

另請參閱See also

概念Concepts

SharePoint Server 2013 的容量規劃Capacity planning for SharePoint Server 2013

監視和維護 SharePoint Server 2013Monitoring and maintaining SharePoint Server 2013

SharePoint Server 2016 的軟體界限及限制Software boundaries and limits for SharePoint Server 2016

其他資源Other Resources

Capacity management and sizing overview for SharePoint Server 2013Capacity management and sizing overview for SharePoint Server 2013