評估 Web Content Management 的容量和效能 (SharePoint Server 2013)Estimate capacity and performance for Web Content Management (SharePoint Server 2013)

摘要:了解如何決定數目及發佈內容和管理 SharePoint Server 2013 中的 web 內容所需電腦的類型。Summary: Learn how to determine the number and types of computers that you need to publish content and manage web content in SharePoint Server 2013.

企業通常會使用 SharePoint Server 2013 發佈於網際網路網站或匿名使用者存取內部網路網站上的使用者存取經過驗證的內容。本文包含可協助您規劃要使用的電腦數目和電腦所發佈的內容和管理 SharePoint Server 2013 中的網站內容類型的容量與效能資料。Enterprises often use SharePoint Server 2013 to publish content that anonymous users access on an Internet site or that authenticated users access on an intranet site. This article contains capacity and performance data to help plan the number of computers to use and the types of computers that are required to publish content and manage web content in SharePoint Server 2013.

SharePoint 發佈功能包括不同類型的發佈網站及可用的每個網站的相關的方法。SharePoint Server 2013 的發佈功能都是以協助您建立加上品牌的網際網路、 內部網路及外部網路網站。如需 SharePoint Server 2013 發佈功能的詳細資訊,請參閱Overview of 發佈至網際網路、 內部網路及 SharePoint Server 中的外部網路網站。SharePoint publishing includes different types of publishing sites and associated methods that are available for each site. The publishing features of SharePoint Server 2013 are intended to help create branded Internet, intranet, and extranet sites. For more information about SharePoint Server 2013 publishing, see Overview of publishing to Internet, intranet, and extranet sites in SharePoint Server.

簡介Introduction

本文討論下列案例:This article discusses the following scenarios:

  • 網際網路平台服務網站Internet presence site

    提供資訊給客戶、合作夥伴、投資人及潛在員工。這類型的網站可讓匿名網際網路使用者尋找公司的相關資訊。這些網站通常具有品牌風格,而且對內容的控制乃緊緊握在公司手中。Provides information to customers, partners, investors, and potential employees. This type of site lets anonymous Internet users find information about a corporation. Typically, these sites are branded and the company tightly controls the content.

  • 網際網路商業網站Internet business site

    推廣公司向客戶提供的產品與服務。這些網站可能會顯示公司所提供產品的目錄。Promotes products and services that a company offers to customers. These sites can show a catalog of products that the company offers.

  • 內部網路網站Intranet site

    公司對組織內部公開此網站。這些網站會分享資訊給經驗證使用者,而公司會嚴管網站來限制存取,或將網站開放給所有內部使用者。A company publishes this site internally inside an organization. These sites share information for authenticated users and companies either tightly manage the site to restrict access or open to all jnternal users.

  • 外部網路網站Extranet site

    讓遠端員工、合作夥伴及客戶存取相關內容。這些網站可用來存取知識庫,而知識庫會將已編寫的內容以中繼資料標記,以將文章分類。使用者可以搜尋或瀏覽特定資訊,例如疑難排解與支援文章。Provides access to targeted content to remote employees, partners, and customers. These sites can provide access to knowledge bases that use authored content tagged with metadata to categorize articles. Users can search or browse for specific information such as troubleshooting and support articles.

    跨網站集合發佈 」 和 「 內容搜尋網頁組件啟用內容重複使用跨網站集合在這些案例中。這些功能和功能會影響容量規劃的方式。如需詳細資訊,請參閱 < Overview of 跨網站發佈的 SharePoint 伺服器Cross-Site Collection Publishing and the Content Search Web Part enable content reuse across site collections in these scenarios. These features and functionality affect how you plan for capacity. For more information, see Overview of cross-site publishing in SharePoint Server.

注意

在本文中,「跨網站集合發佈」稱為「跨網站發佈」。Cross-Site Collection Publishing is known as cross-site publishing in this article.

SharePoint Server 2013 中的受管理的導覽提供分類驅動的導覽的發佈網站。如需詳細資訊,請參閱 < SharePoint Server 中的受管理導覽的概觀Managed navigation in SharePoint Server 2013 provides taxonomy-driven navigation for a publishing site. For more information, see Overview of managed navigation in SharePoint Server.

本文中的容量與效能資料包含兩個部分。第一個部分是新的跨網站發佈方法和受管理導覽。第二個部分則使用就地編寫模型。The capacity and performance data in this article contain two parts. The first part is the new cross-site publishing method and managed navigation. The second part uses the author-in-place model.

注意

本文所處理的案例,透過跨網站發佈和就地編寫網站皆可以達成。跨網站發佈和受管理導覽功能並不彼此依賴,可以單獨使用。The scenarios that are addressed in this article can be achieved by both cross-site publishing and author-in-place sites. The cross-site publishing and managed navigation features do not depend on one another and can be used independently.

本文所用的模型中會處理下列兩個重要度量:The following two key metrics are addressed in the models that are used in this article:

  • 輸送量Throughput

    網站可以維持的每秒網頁檢視數The number of page views per second that the site can sustain

  • 伺服器回應時間Server Response Time

    時間所需的伺服器處理的要求會影響使用者檢視] 頁面上所花費的時間。我們提供此文件中的伺服器回應時間是 95th 和第 50 個百分位數的值。這些值的意思是 95%到 50%的要求會比提供值,分別更快速。我們使用指定的要求的 SharePoint 流量資料庫中所記錄的"工期"度量這些值。The time that is required for the server to process a request, affecting the time it takes for a user to view the page. The server response times that we provide in this document are the 95th and 50th percentile values. These values mean that 95 percent and 50 percent of requests are faster than the value that is provided, respectively. We measure these values by using the "Duration" recorded in the SharePoint Usage database for a given request.

  • 內容新鮮度Content freshness

    在面對跨網站發佈案例時,更新的項目反映在搜尋結果中所需的時間,這是值得考慮的不錯度量。The time that is required for an updated item to be reflected in search results is a good metric to consider when you work with cross-site publishing scenarios.

本文中的案例使用下列兩種狀態:The scenarios in this article use the following two states:

  • 綠色區域Green Zone

    伺服器使用率低於 60%。這應該是伺服器執行時大多數時間的目標。The servers are under 60 percent utilization. This should be the target for most of the time that the servers are running.

  • 紅色區域Red Zone

    伺服器使用率快接近全滿。此狀態可以視為 SharePoint 網站正承受比平時還高的負載。在紅色區域,當伺服器嘗試滿足內送要求的需求,伺服器回應時間值會開始增加。The servers are close to full utilization. This can be considered a state where the SharePoint site is under more load than usual. In the Red Zone, the server response time values start to increase as the server tries to meet the demand of incoming requests.

必要資訊Prerequisite information

閱讀本文之前,請確定您了解 SharePoint Server 2013 容量管理的重要概念。下列文章可協助您了解容量管理的建議方法並提供可協助您了解如何有效利用資訊的本文中的內容。Before you read this article, make sure that you understand the key concepts behind SharePoint Server 2013 capacity management. The following articles help you learn about the recommended approach to capacity management and provide context to help you understand how to make effective use of the information in this article.

請注意一些其他的新功能會影響發佈案例具有相同的作用不會出現在本文中。這些案例包括裝置通道,SEO 最佳化、 顯示範本和查詢規則。此外,不會說明的功能和設定跨網站發佈網站的在本文中的詳細資料。如需詳細資訊,請參閱< Plan for SharePoint Server 中的跨網站發佈SharePoint Server 中的設定 web 內容管理解決方案Note that some other new features that affect publishing scenarios functionally do not appear in this article. These scenarios include device channels, SEO optimization, display templates and query rules. Additionally, the functionality and configuration of a cross-site publishing site is not described in detail in this article. For more information, see Plan for cross-site publishing in SharePoint Server and Configure web content management solutions in SharePoint Server.

如需容量和效能瞭解本文中的資料的詳細資訊,請參閱規劃 SharePoint Server 2013 中的效能For more information about capacity and performance to help understand the data in this article, see Performance planning in SharePoint Server 2013.

使用受管理導覽進行跨網站發佈Cross-site publishing using managed navigation

本節提供兩個方面的測試資料:對匿名使用者的跨網站發佈與就地編寫型發佈。This section provides our test data for two areas: cross-site publishing with anonymous users and author-in-place publishing.

對匿名使用者的跨網站發佈Cross-site publishing with Anonymous users

本節中的測試結果是以基本的跨網站發佈網站模型為根據,藉以提供容量規劃指引。規劃 SharePoint 部署以讓匿名使用者存取網站時,請使用本指引,並據以調整您的部署規格。Test results in this section are based on a basic cross-site publishing site model to provide capacity planning guidance. When you plan a SharePoint deployment for anonymous users to access a web site, use this guidance and adjust your deployment specifications accordingly.

測試案例中測試中使用跨網站發佈功能。此案例中提供多個網站集合標示為 「 型錄,並再 SharePoint Search Service 應用程式所編目的內容。使用搜尋技術,例如 「 內容搜尋網頁組件和目錄項目重複使用網頁組件] 網頁組件顯示在另一個網站頁面上的內容。如需詳細資訊,請參閱 < Overview of 跨網站發佈的 SharePoint 伺服器The test case in our tests uses the cross-site publishing feature. This scenario provides content in multiple site collections that are marked as catalogs, and then crawled by the SharePoint Search Service application. Web Parts that use search technology, for example the Content Search Web Part, and the Catalog-Item Reuse Web Part, display content on pages in another site. For more information, see Overview of cross-site publishing in SharePoint Server.

我們為了測試跨網站發佈而建置的模型站台具有下列特性:We used the following characteristics in the model site, which we built to test cross-site publishing:

  • 發佈網站,大約有 5 百萬個頁面或項目。Publishing web site that has approximately 5 million pages or items.

  • 項目大約有 1,000 個相關聯的類別。The items are associated with about 1,000 categories.

  • 內容位於其他網站集合中,一或多個目錄裡。The content is located in other site collections in one or more catalogs.

  • 網站使用受管理導覽,提供與項目相關聯之類別的連結。The web site uses managed navigation that is linked to the categories that the items are associated with.

  • 在本清單稍後描述的基準部署拓撲中,網站平均每秒最多接收 80 個網頁檢視。尖峰期間則每秒最高可達 100 個網頁檢視。若要增加此輸送量數字,請新增電腦至拓撲。若要減少此輸送量數字,請從拓撲中移除電腦。For the baseline deployment topology described later in this list, the web site receives up to 80 page views per second on average. Peak periods reach up to 100 page views per second. To scale this throughput number up, add computes to the topology. To scale this throughput number down, remove computers from the topology.

  • 搜尋編目程式會以連續 1 分鐘的間隔 (每秒對目錄更新五次) 執行連續編目。The Search crawler runs with continuous crawls for a 1-minute interval with five updates per second to the catalog.

  • 網站具有下列頁面和流量模式:The web site has the following page and traffic patterns:

    • 首頁,具有三個內容搜尋網頁組件和一個精簡搜尋面板網頁組件,共接收 15% 的流量。Home page that has three Content Search Web Parts and a Refinement Panel Web Part (receives 15 percent of the traffic).

    • 各類別頁面,具有三個內容搜尋網頁組件、一個分類精簡搜尋面板網頁組件,以及一個精簡搜尋面板網頁組件,共接收 45% 的流量。Category pages that have three Content Search Web Parts, one Taxonomy Refinement Panel Web Part, and one Refinement Panel Web Part receive 45 percent of the traffic.

    • 各目錄項目頁面,具有一個目錄項目重複使用網頁組件和兩個內容搜尋網頁組件,共接收 40% 的流量。Catalog Item pages that have Catalog-Item Reuse Web Part and two Content Search Web Parts receive 40 percent of the traffic.

  • 每個內容搜尋與目錄項目重複使用網頁組件都會發出一個同步查詢。Each Content Search and Catalog-Item Reuse Web Part issues a synchronous query.

  • 目錄項目頁面因為接收的流量不多,所以未使用匿名搜尋結果快取。The catalog item pages do not use the Anonymous Search Results Cache because they receive a small amount of traffic.

  • 伺服器陣列對當成前端網頁伺服器來執行的電腦,開啟二進位大型物件 (BLOB) 快取。The farm has the binary large object (BLOB) cache turned on for the computers that are run as the front-end web servers.

下圖是用來測試此案例的伺服器拓撲:The server topology that we used to test this scenario is in the following diagram:

圖 1: 測試實驗室伺服器拓撲Figure 1: Test lab server topology

測試伺服器拓撲的圖表,2 部裝載 SQL Server 和 SharePoint Server 的電腦;1 部電腦裝載搜尋編目程式和內容處理 (CPC) 角色;3 部電腦裝載搜尋索引以及處理為前端網頁伺服器的查詢。

  • 一部電腦負責裝載 SQL Server 的所有 SharePoint 所使用的資料庫one computer that hosts SQL Server with all of the databases that SharePoint uses

  • 一部電腦負責裝載 SharePoint 服務應用程式、分散式快取服務、搜尋分析資料處理與搜尋管理角色one computer that hosts SharePoint service applications, distributed cache service, search analytics processing, and search administration roles

  • 一部電腦負責裝載搜尋編目程式與內容處理 (CPC) 角色one computer that hosts the search crawler and content processing (CPC) roles

  • 三部電腦負責裝載含有查詢處理機制的搜尋索引節點,並作為前端網頁伺服器three computers that host search index nodes with query processing and serve as front-end web servers

注意

在此測試中的電腦是執行 Windows Server 2008 R2 的實體電腦。如需如何使用虛擬機器和 Windows Server 2012 的建議,請參閱 Search 容量規劃及SharePoint Server 2013 的容量計劃The computers in this test are physical computers that run Windows Server 2008 R2. Refer to the Search capacity planning and Capacity planning for SharePoint Server 2013 for recommendations about how to use virtual machines and Windows Server 2012.

重要

我們的測試實驗室拓撲的設定是最適合搜尋導向發佈案例。此設定是不同的共同作業類型的 SharePoint 部署。例如,我們設定使用的前端網頁伺服器做為搜尋索引伺服器以取得最佳效能。> 在我們的測試實驗室拓撲我們學會主控應用程式伺服器的電腦已未得到充分利用。因此,我們將分散式快取服務而不是這個應用程式伺服器上的專用伺服器。您可能會決定主機上的分散式快取服務專用伺服器環境中。為了達到最佳效能不建議您主機上的分散式快取服務的搜尋索引伺服器角色的前端網頁伺服器。The configuration for our test lab topology is optimized for search-driven publishing scenarios. This configuration is different from collaboration types of SharePoint deployments. For example, our configuration uses the front-end web servers as search index servers to get the best performance. > In our test lab topology we learned that the computer that hosts the application server was underutilized. As a result, we put the Distributed Cache Service on this application server instead of on a dedicated server. You may decide to host the Distributed Cache Service on a dedicated server in your environment. For best performance we do not recommend that you host the Distributed Cache Service on a front-end web server that has the search index server role.

測試實驗室報告Test lab reports

我們的測試實驗室與實體電腦和 Visual Studio Team System (VSTS) 負載測試使用圖 1 中的拓撲。如需詳細資訊,請參閱Visual Studio Team System。適用於測試電腦的技術規格是如下表所示。We used the topology in figure 1 for our test lab with physical computers and a Visual Studio Team System (VSTS) load test. For more information, see Visual Studio Team System. Technical specifications for the test computers are in the following tables.

注意

我們沒有使用瀏覽器快取或影像或 VSTS 測試的 JavaScript 檔案相依要求。根據如何您自訂您的發佈網站、 相依發生的要求數量可以許多不同。> 我們用於測試進行幾乎 50 頁面載入時間 1 (PLT1) 要求類型 (空白瀏覽器快取) 和 PLT2 要求類型 (從瀏覽器快取結果後續要求) 的約 3 要求頁面。通常,SharePoint BLOB 快取做要求這些項目並將不會改變我們效能號碼大幅。We did not use browser caching or dependent requests, such as images or JavaScript files in our VSTS tests. Depending on how you customize your publishing site, the amount of dependent requests that occur can vary considerably. > The pages that we used in our tests made almost 50 page load time 1 (PLT1) request types (empty browser cache) and about 3 requests for PLT2 request types (subsequent requests with results from the browser cache). Usually, SharePoint BLOB Cache serves requests for these items and will not alter our performance numbers significantly.

伺服器元件Server Components 執行 SharePoint Server 的伺服器Servers running SharePoint Server
處理器Processors
Intel Xeon CPUs @2.27GHz (2 個處理器、 8 個核心總計、 16 的執行緒總數)Intel Xeon CPUs @2.27GHz (2 processors, 8 cores total, 16 threads total)
RAMRAM
24 GB24 GB
作業系統Operating system
Windows Server 2008 R2 Enterprise SP1 64 位元Windows Server 2008 R2 Enterprise SP1, 64-bit
SharePoint 磁碟機的大小Size of the SharePoint drive
內部磁碟 200 GB200 GB on internal disk
儲存用於搜尋索引Storage used for Search Index
外部磁碟陣列 78 GB (2 個 Dell PERC H700 SCSI)78 GB on an external disk array (2 x Dell PERC H700 SCSI)
網路介面卡數目Number of network adapters
22
網路介面卡速度Network adapter speed
1 GB1 gigabit
驗證Authentication
無 - 匿名None ─ Anonymous
軟體版本Software version
SharePoint Server 2013SharePoint Server 2013
伺服器元件Server Components 資料庫伺服器Database servers
處理器Processors
Intel Xeon CPU L5520 @2.27GHz (2 個處理器,共 8 個核心與 16 個執行緒)Intel Xeon CPUs L5520 @2.27GHz (2 processors, 8 cores total, 16 threads total
RAMRAM
24 GB24 GB
作業系統Operating system
Windows Server 2008 R2 Enterprise SP1 64 位元Windows Server 2008 R2 Enterprise SP1, 64-bit
磁碟陣列Disk Array
2 個 Dell H700 SCSI2 x Dell H700 SCSI
網路介面卡數目Number of network adapters
22
網路介面卡速度Network adapter speed
1 GB1 gigabit
驗證Authentication
NTLMNTLM
軟體版本Software version
Microsoft SQL Server 2008 R2 SP1Microsoft SQL Server 2008 R2 SP1

執行 10 分鐘的結果如下:Results from a 10 minute run are as follows:

測試功能Test Features 綠色區域Green Zone 紅色區域Red Zone
VSTS 使用者數目 (模擬並行使用者):Number of VSTS users (simulating concurrent users):
6060
100100
伺服器回應時間第 50 個百分位數*:Server Response Time 50th percentile*:
219 毫秒219 ms.
302 毫秒302 ms.
伺服器回應時間 95th 百分位數*:Server Response Time 95th percentile*:
412 毫秒412 ms.
635 毫秒635 ms.
每秒網頁檢視:Page views per second:
7878
9898

這是個會顯示搜尋索引中之內容的跨網站發佈案例。不妨來看看搜尋查詢所在之伺服器所服務的查詢數目,以及匿名結果快取所服務的查詢數目。在此模型中,匿名結果快取服務大約 60% 的查詢。本文稍後會討論匿名結果快取。This is a cross-site publishing scenario that displays content from the search index. It may be interesting to examine the number of queries that the servers that host search queries serve, and the number of queries that the Anonymous Results Cache serves. In this model, the Anonymous Results Cache serves about 60 percent of the queries. The Anonymous Results Cache is discussed later in this article.

測試功能Test Features 綠色區域Green Zone 紅色區域Red Zone
每秒總查詢:Total queries per second:
235235
294294
匿名結果快取所服務的查詢:Queries served from Anonymous Results Cache:
145145
182182
搜尋所服務的查詢:Queries served from Search:
9090
112112

執行測試時這些電腦的平均 CPU 與尖峰記憶體使用量值如下:The values for the average CPU and peak memory usage for these computers while the tests were running are as follows:

測試功能Test Features 綠色區域Green Zone 紅色區域Red Zone
平均 CPU (搜尋索引節點每部前端網頁伺服器)Average CPU (Search index nodes per front-end web server)
59%59%
80%80%
平均 CPU (應用程式伺服器,含分散式快取)Average CPU (application server including Distributed Cache)
8%8%
9%9%
平均 CPU (搜尋 CPC 節點)Average CPU (Search CPC nodes)
5%5%
5%5%
平均 CPU (SQL Server)Average CPU (SQL Server)
未測量Not measured
未測量Not measured
尖峰記憶體使用量 (搜尋索引節點每部前端網頁伺服器)Peak Memory usage (Search index nodes per front-end web server)
7.5 GB7.5 GB
7.5 GB7.5 GB
尖峰記憶體使用量 (應用程式伺服器,含分散式快取)Peak memory usage (application server including Distributed Cache)
10.1 GB10.1 GB
10 GB10 GB
尖峰記憶體使用量 (搜尋 CPC 節點)Peak memory usage (Search CPC nodes)
6.5 GB6.5 GB
6.5 GB6.5 GB

請注意,因為正常流量期間伺服器上執行的計時器工作各有不同,所以記憶體使用量可能會有一些不同。在能夠維持負載的情況下執行測試兩週之後,我們發現索引/前端網頁伺服器節點使用多達 12 GB 的記憶體。Note that the memory usage may differ somewhat because various timer jobs run on the server during normal usage. We found that the index/front-end web server nodes were using as much as 12 GB of memory after a two week test run with a sustained load.

搜尋網頁組件如何在跨網站發佈頁面上顯示內容How Search Web Parts display content on cross-site publishing pages

如果發佈頁面包含搜尋網頁組件 (例如內容搜尋網頁組件),瀏覽器會在搜尋查詢還沒完成時就開始處理頁面。如此可以改善使用者感受到的頁面延遲。搜尋查詢完成後,就會傳送完整的查詢結果給瀏覽器,並關閉與瀏覽器的連線。使用者可能會覺得搜尋結果的載入並不同步。不過,查詢仍然是在還在接收索取頁面的要求時,就由伺服器發出。If a publishing page contains a Search Web Part, such as the Content Search Web Part, the browser starts to process the page before the search query is complete. This improves the perceived latency of the page. After the search query finishes, the complete results of the query are sent to the browser, and the connection to the browser is closed. Users might think that the search results are loaded asynchronously. However, the queries are still issued from the server while the page is being requested.

請注意,內容搜尋網頁組件乃另採非同步模式,亦即等到頁面載入完畢後,才從瀏覽器發出查詢。Note that there is a separate asynchronous mode for the Content Search Web Part, where the queries are issued from the browser after a page is loaded.

跨網站發佈網站上的負載變更所造成的影響Effect of load changes on your cross-site publishing site

負載測試中採用了各種 VSTS 使用者數目 (類似同時存取網站的並行使用者數目)。下圖顯示,隨著負載增加,伺服器回應時間也跟著增加,且每秒服務的頁面數也呈現某種幅度的遞增。建議將伺服器回應時間保持在 750 毫秒以下,以確保使用者在使用 SharePoint 部署時不會覺得回應速度太慢。We varied the number of VSTS users (similar to the number of concurrent users who access the site) who were used in the load test. The following graph shows that the server response time increases as load increases, and there is some incremental increase in number of pages served per second. We recommend that the server response times are kept under 750 ms. to make sure that users have a responsive experience with the SharePoint deployment.

圖 2: 圖表顯示不同負載輸送量與伺服器回應時間Figure 2: Chart showing throughput and server response times with different loads

這個 Excel 圖表顯示當負載增加時伺服器回應時間會增加,而且在每秒提供的頁面數上會有一些累加式增加。

向外擴充跨網站發佈網站Scaling out your cross-site publishing site

如果您預期 SharePoint 部署接收的流量會比稍早所述的基準案例更多或更少,可以變更伺服器陣列上以索引與前端網頁伺服器角色執行的電腦數目,以配合該流量。下圖顯示在不同的負載模式下,和不同數目的前端網頁伺服器 (含有索引節點) 電腦下,向外擴充同一個跨網站發佈網站的結果;測試是先從只有一部前端網頁伺服器角色 (含有索引節點) 電腦的情況下開始進行,然後逐漸增加到六部電腦:If the SharePoint deployment is expected to receive more or less traffic compared to the baseline case described earlier, you may want to change the number of computers that are running with the Index and front-end web server role on the farm to accommodate that traffic. The following graph shows the results for scaling out the same cross-site publishing site that has different load patterns and varying number of computers that are used as front-end web servers with Index nodes, starting with a single computer in the front-end web server role with Index nodes, and going up to six computers:

圖 3: 擴充您的部署Figure 3: Scaling out your deployment

這個 Excel 圖表顯示使用不同負載模式來擴充跨網站發佈網站,以及使用索引節點來變換用來作為前端網頁伺服器的電腦數目,並以單一電腦為開頭且以 6 部電腦為結束的結果。

在這每個組態中,我們已調整負載,讓伺服器回應時間的值與上節中的基準值差不多。In each of the configurations, we adjusted the load to have server response times at similar values compared to the baseline in the previous section.

請注意,隨著電腦數目增加,拓撲複雜性升高所帶來的負面效應開始超越正面效應。相較於已在環境中的電腦,每部多加的電腦所獲得的輸送量都變得更少。提供這些數字,是為了顯示向外擴充時的模式。實際效能會依 SharePoint 部署的建置方式而異。Note that as number of computers increased, the complexity of the topology starts to overtake the gains. Each additional computer has less throughput compared to computers that are already in the environment. These numbers are provided to show the pattern for scaling out. Actual performance will change depending on how the SharePoint deployment is built.

規劃網站時的指導方針Guidelines to plan your site

我們的效能測試多半使用稍早各節所述的部署。若您的部署與測試實驗室中所用的不同,下列清單提出的指導方針,可協助您進行正確的容量規劃決策。The majority of our performance testing used the deployment that was described in the earlier sections. The guidelines in the following list are meant to help you make correct capacity planning decisions when your deployments differ from the ones we used in our test lab.

  • 搜尋索引中的多個項目通常的意思是較高的延遲。每個索引分割區可以包含最多 10 萬個項目。一般網站少有超過 10 萬個項目顯示。讓他們只需要一個分割區我們先前所述的拓撲相同。您可以使用其中一個主機超過 10 萬個項目或有更多、 較小,與較快的索引分割區的多個索引分割區。如果您打算使用多個索引分割區,請參閱擴充 SharePoint Server 中的網際網路網站的搜尋以正常大小為搜尋拓撲。More items in the search index generally mean higher latency. Each index partition can contain up to 10 million items. Typical websites rarely have more than 10 million items to show. So they only need one partition as in the topology we described earlier. You can use more index partitions to either host more than 10 million items or to have more, smaller, and faster index partitions. If you plan to use multiple index partitions, refer to Scale search for Internet sites in SharePoint Server to correctly size your search topology.

  • 您每新增一個控制項或網頁組件到頁面 (或頁面版面配置),都會對頁面的伺服器回應時間增加一些影響。Each control or Web Part that you add to a page (or page layout) will add some overhead to the server response time for the page.

  • 避免使用五個以上同步內容搜尋網頁組件或目錄項目重複使用網頁組件頁面上。同時處理的要求] 頁面上、 SharePoint Server 2013 中同時執行多達五個查詢並將結果傳回。如果五個以上的查詢] 頁面上,開始執行下一組的五個查詢之前 SharePoint Server 2013 會執行前五個查詢。如果頁面需要五個以上的內容搜尋網頁組件或目錄項目重複使用網頁組件,您可能會在非同步模式下執行額外的內容搜尋網頁組件或使用查詢規則和結果區塊。Avoid using more than five synchronous Content Search Web Parts or Catalog-Item Reuse Web Parts on a page. While processing a request for a page, SharePoint Server 2013 executes as many as five queries in parallel and returns the results. If more than five queries are on a page, SharePoint Server 2013 executes the first five queries before it starts to execute the next set of five queries. If pages require more than five Content Search Web Parts or Catalog-Item Reuse Web Parts, you might run the additional Content Search Web Parts in asynchronous mode or use query rules and result blocks.

  • 內容搜尋網頁組件和目錄項目重複使用網頁組件具有非同步模式。瀏覽器載入頁面後,就會執行與網頁組件相關聯的查詢。如果查詢速度會很慢,請使用此模式,讓使用者更快看到頁面的其餘部分。否則,建議您使用同步查詢來達到最佳頁面載入時間。Content Search Web Parts and Catalog-Item Reuse Web Parts have an asynchronous mode. The query that is associated with the Web Part is executed after the browser loads the page. Use this mode for slow queries so that the rest of the page appears faster for users. Otherwise, we recommend that you use synchronous queries for best page load times.

  • 有許多精簡器精簡搜尋面板網頁組件會增加處理查詢的時間。您可以變更要顯示 managed 屬性的精簡器的數目。如需詳細資訊,請參閱Configure refiners 和 SharePoint Server 中的多面向導覽A Refinement Panel Web Part that has many refiners increases the time to process a query. You can change the number of refiners to show for a managed property. For more information, see Configure refiners and faceted navigation in SharePoint Server

  • 如果導覽節點階層有很多層,而您使用分類精簡搜尋面板網頁組件,則查詢處理時間會增加。不建議在底下有多於 200 個導覽節點的頁面上使用分類精簡搜尋面板網頁組件。導覽節點太多可能會導致伺服器回應時間緩慢,並使輸送量降低。If you use the Taxonomy Refinement Panel Web Part when you have a deep hierarchy of navigation nodes, the time to process a query increases. We do not recommend the use of the Taxonomy Refinement Panel Web Part on a page that has more than 200 navigation nodes under it. The large number of navigation nodes may cause slow server response times and decrease throughput.

  • 如果您必須設計高度可用的 SharePoint 部署,則必須新增下列項目:If you must design a SharePoint deployment for high availability, you must add the following:

    • 額外一部電腦,負責在現有電腦無法使用時,與分散式快取角色的服務應用程式一起執行An additional computer that runs with the service applications in distributed cache roles in case the existing computer is not available

    • 額外一些電腦,負責在有一或多部含有索引節點的前端網頁伺服器電腦無法使用時,維持負載Additional computers to sustain the load if one or more of the front-end web server computers with Index nodes are not available

    • 額外一部 CPC 角色的電腦,以確保當具有 CPC 角色的電腦無法使用時,網站中仍然會反映更新An additional computer in the CPC roles to make sure updates are still reflected in your site when the computer that has the CPC role is not available

    • 繼續服務資料庫查詢如果其中一部資料庫伺服器無法使用 SQL Server 拓撲A SQL Server topology that continues to serve database queries if one of the database servers is not available

搜尋編目速度與內容新鮮度Search crawl speed and content freshness

在測試過程中,我們也測試了所發佈目錄內容的更新程序。接著,我們觀察更新的項目出現在發佈網站中之前經過的時間量。在實驗中,我們每秒對目錄進行更新五次,並將目錄上的連續編目設為一分鐘間隔。我們觀察到這些變更出現在發佈網站中所需的時間平均約為兩分鐘。最短時間為快滿一分鐘,最長時間則為三分鐘。增加以 CPC 角色執行的電腦數目時,這些數字並未出現重大變更。In our testing, we also conducted tests for the process that updates the catalog content that was being published. We then observed the amount of time that elapsed before an updated item appeared in the publishing site. In our experiments, we made five updates per second to the catalog and set the continuous crawls on the catalog to a one minute interval. We observed that the average time for the changes to appear in the publishing site were about two minutes. The minimum time was just under a minute and the maximum time was three minutes. We did not see a significant change from these numbers when we increased the number of computers that were running with the CPC role.

不過,就目錄的完整編目而言,增加以 CPC 角色執行的電腦數目,也會增加每秒處理的項目數。下圖顯示每秒處理的項目數目與伺服器陣列中具有 CPC 角色之電腦數目的關係。請注意,此測試資料取自的 SharePoint 部署,並非基準測試中所使用的部署。這些結果應套用於 SharePoint 部署,因為新增更多 CPC 節點,將可改善完整編目時間。For the full crawl of the catalog, however, an increase in the number of computers that are running with the CPC role increased the number of items processed per second. The following graph shows the relationship of items processed per second and the number of computers in the farm with the CPC role. Note that this test data was obtained from a SharePoint deployment other than the one used in the baseline tests. The findings should apply to the SharePoint deployments because the addition of more CPC nodes results in improved full crawl times.

圖 4: 之影響的內容處理 (CPC) 電腦對完整編目Figure 4: Effect of content processing (CPC) computers on a full crawl

這個 Excel 圖表顯示每秒處理的項目數與內容處理角色 (CPC) 中電腦數目的關係。增加含 CPC 角色的電腦數目,即會增加每秒處理的項目數,並可提高完整編目的次數。

因此,如果您需要更快地完整編目目錄,可以在部署中增加使用 CPC 角色的電腦數目。Therefore, if you require faster full crawls for your catalogs, you can increase the number of computers that use the CPC role in your deployment.

Managed Metadata Service 應用程式上的負載Load on Managed Metadata Service application

我們的測試顯示,在有網站使用受管理導覽的發佈案例中,Managed Metadata Service 應用程式上沒有重大的記憶體或 CPU 需求。對於如稍早所述的部署,Managed Metadata Service 應用程式可能是在執行其他 SharePoint 服務應用程式的電腦上執行。受管理導覽功能會在接收到第一個索取網站的要求時,對該服務應用程式建立一個連線。後續要求則會使用前端網頁伺服器所快取的值。因此,當要求是由前端網頁伺服器滿足時,Managed Metadata Service 應用程式上就沒有負載。Our testing shows that publishing scenarios that involve sites that use managed navigation do not have significant memory or CPU requirements on the Managed Metadata service application. For a deployment such as the one we have described earlier, the Managed Metadata service application can be run on a computer that is running other SharePoint service applications. The Managed Navigation feature makes one connection to the service application when it receives the first request for a site. Subsequent requests use values that front-end web servers cache. Therefore there is no load on the Managed Metadata service application while front-end web servers fulfill requests.

匿名搜尋結果快取Anonymous Search Results Cache

匿名搜尋結果快取儲存的查詢、 精簡資料查詢伺服器及其他結果資料表從 SharePoint 分散式快取服務所傳回的結果。每個快取項目而定的查詢,例如結果、 要求的精簡器,並重新排列任何動態規則的排序順序參數。快取會影響 web 應用程式會處理搜尋網頁組件的查詢包含的所有查詢及 CSOM 用戶端的查詢。如需詳細資訊,請參閱SharePoint Server 中的搜尋架構的概觀擴充 SharePoint Server 中的網際網路網站的搜尋The Anonymous Search Results Cache stores results of a query, refinement data for the query, and additional result tables that are returned from the SharePoint Distributed Cache Service. Each cache entry depends on the parameters of a query, such as the sort order of the results, the requested refiners, and any dynamic reordering rules. The cache affects all queries that a web application handles including queries from Search Web Parts and the queries from CSOM clients. For more information, see Overview of search architecture in SharePoint Server and Scale search for Internet sites in SharePoint Server.

此快取不會用於因安全性考量而受到驗證的查詢。This cache is not used for queries that are authenticated because of security concerns.

建議您設定只在執行 SharePoint 服務應用程式的電腦上執行分散式快取服務,以取得最佳結果。分散式快取服務不應該執行於擔任前端網頁伺服器角色的電腦上。We recommend that you configure the Distributed Cache Service to run only on the computer that runs the SharePoint service applications for best results. The Distributed Cache Service should not run on the computers that are in the front-end web server roles.

根據預設,匿名搜尋結果快取重新整理每隔 15 分鐘項目。您可以使用 Microsoft PowerShell 在 web 應用程式上設定快取持續時間已快取:By default, the Anonymous Search Results Cache refreshes items every 15 minutes. You can use Microsoft PowerShell to configure the cache duration on the web application where the cache is configured:

$webapp.Properties["SearchResultsCacheTTL"] = <number of seconds to keep in cache> 
$webapp.Update()

如果您希望搜尋結果的新鮮度比預設值所提供的高,請降低此值。請注意,這會增加搜尋服務所須服務的查詢數目。If you want search results to be fresher than the default value, you lower the value. Note that this increases the number of queries that the Search service will need to serve.

建議您在接收高流量的發佈頁面上一律使用此快取。這類頁面的一些範例包括網站首頁,以及使用搜尋網頁組件的類別頁面。不建議針對目錄項目頁面進行快取,這是因為個別目錄項目頁面受到存取的機率遠少於首頁,而將這類項目儲存在快取中可能並不值得。We recommend that you always use the cache on publishing pages that receive heavy traffic. Some examples for these types of pages are the site home page and category pages that use Search Web Parts. We do not recommend caching for catalog item pages. Because an individual catalog item page would be accessed much less frequently than a home page, and it may not be worthwhile to store the item in cache.

當我們具有相同的負載模式我們測試環境中關閉匿名搜尋結果快取大幅增加伺服器回應時間與輸送量中的每秒網頁檢視數拒絕。以下是顯示此關係圖:When we turned off the Anonymous Search Results Cache in our test environment that has the same load patterns, server response times increased significantly and throughput in number of page views per second declined. Here's a graph that shows this relationship:

圖 5: 之影響的匿名搜尋結果快取Figure 5: Effect of Anonymous Search Results Cache

這個 Excel 圖表顯示關閉前端網頁伺服器中的「匿名搜尋結果快取」會增加伺服器回應時間,並減少每秒頁面檢視數目的輸送量。

根據預設,內容搜尋網頁組件會設定成使用匿名搜尋結果快取。目錄項目頁面則因為通常只展現稀疏的存取模式,所以未被設定成使用它。By default, Content Search Web Parts are configured to use the Anonymous Search Results Cache. Catalog-Item Reuse Web Parts, which are used on catalog item pages, are not configured to use it due to the sparse access patterns these pages generally exhibit.

若要設定個別的網頁組件以使用 (或不使用) 匿名搜尋結果快取的快取行為,請將子屬性的值"TryCache"DataProviderJSON網頁組件的屬性。如果值為"true",查詢使用快取。如果值為"false",查詢匿名搜尋查詢時不會不會使用快取。To configure the caching behavior for an individual Web Part to use (or not use) the Anonymous Search Results Cache, set the value of the sub-property "TryCache" in the DataProviderJSON property of the Web Part. If the value is "true", the query uses the cache. If the value is "false", the query does not use the cache for Anonymous search queries.

輸出快取所造成的影響Effect of output cache

輸出快取是有效的方式來減少在 SharePoint Server 2013 中發佈案例的負載。如需詳細資訊輸出快取本文中的運作方式,請參閱輸出快取與快取設定檔Output caching is an effective way to reduce the load on SharePoint Server 2013 in publishing scenarios. For more details about how Output Cache works in this article, see Output Caching and Cache Profiles.

SharePoint 部署可以利用輸出快取,減少 SharePoint 內容資料庫與搜尋服務應用程式所承受的負載。以下是一些範例情況:A SharePoint deployment may benefit from Output Caching to reduce the load on SharePoint content databases and the search service application. Here are some example situations:

  • 您有些頁面會一直接收到大量流量。You are receiving lots of traffic on some of your pages.

  • 您的 SharePoint 內容資料庫會一直接收到大量流量。You are receiving lots of traffic on SharePoint content databases,

  • 用來服務搜尋查詢的電腦具有很高的 CPU 使用率。Computers that serve search queries are running with high CPU utilization.

我們建議您使用輸出快取非常常用的頁面的網站,例如網站的首頁上或最上層類別頁面和收到大量流量的特定項目頁面上。We recommend that you use Output Caching for very popular pages on your site, such as the site's home page or top level category pages and certain item pages that receive large amounts of traffic.

重要

當啟用輸出快取的頁面也包含內容搜尋網頁組件在 SharePoint Server 2013 中沒有已知的問題。若要避免此問題部署中的,安裝SharePoint Server 2013 更新: 2013 年 3 月 12 日There is a known issue in SharePoint Server 2013 when pages that have Output Caching enabled also contain Content Search Web Parts. To avoid this issue in your deployment, install SharePoint Server 2013 update: March 12, 2013.

下圖顯示我們在測試環境中的首頁與接收 60% 網站流量的類別頁面上使用輸出快取時,所得到的一些結果。The following graph shows some results from our test environment where we use Output Caching on the homepage and category pages that receive 60 percent of the site traffic.

圖 6: 的首頁與類別頁面輸出快取的影響Figure 6: Effect of output caching for home page and category pages

這個 Excel 圖表顯示在測試環境的綠色與紅色區域中關閉首頁和類別頁面上之「輸出快取」的影響。

注意

內容搜尋網頁組件有項以非同步模式執行的設定。輸出快取並不適用於來自非同步內容搜尋網頁組件的負載。Content Search Web Parts have a setting to run in asynchronous mode. Output Caching does not apply to the load from asynchronous Content Search Web Parts.

流量分析處理Usage analytics processing

若要讓即可立即使用的流量分析的相關資訊,SharePoint Server 2013 處理使用狀況資料庫中的資訊。在我們的拓撲中分析處理發生在包含 [搜尋管理] 節點、 分散式快取服務和其他服務應用程式的節點。如需詳細資訊,請參閱Overview of analytics processing in SharePoint ServerTo have information about usage analytics ready to use, SharePoint Server 2013 processes information that's in the usage database. In our topology Analytics Processing occurs on the node that contains the Search Admin node, Distributed Cache service and other service applications. For more information, see Overview of analytics processing in SharePoint Server

我們所需某些分析處理使用舊版測試中所用的跨網站發佈網站的時間單位。我們為單位來處理大量的 SharePoint Server 2013 取得按一下 [在網站頁面上的活動的時間。雖然這些結果是從跨網站發佈網站,但是他們也適用於使用-就地製作的發佈方法的網站。We took some analytics processing time measurements by using the cross-site publishing site that we used in our earlier tests. We measured the time that SharePoint Server 2013 takes to process a large amount of click events on the pages in the site. While these results are from a cross-site publishing site, they also apply to sites that use the author-in-place publishing method.

為了測試流量分析處理,我們有整整一週每天都產生下列模擬事件:For our tests around usage analytics processing, we generated the following mock events, every day for a week:

  • 400,000 位使用者對 3 百萬個清單項目的 27,500,000 個 click 事件。27.5 million click events spread across 3 million list items and 400,000 users.

    我們採用 Zipf 分佈,讓一些項目和使用者具有許多事件,而讓其他項目和使用者具有較少的事件。Zipf distribution was used so that some items and users have many events, but others have less.

如此共產生了每天 7,500,000 個事件,以模擬不同使用者對網站產生的不同流量模式。This generated a total of 7.5 million events per day, simulating different users generating different traffic patterns for the site.

我們會觸發分析執行七個時間來模擬一週的流量。我們已執行流量分析工作每天我們累積六天的資料。然後我們測量時間的第七天的執行。第七天會隨著完整週的項目處理和更新關係圖採用程序最長的一天。執行階段與磁碟使用情況天 8 會類似 Day 1。We triggered the analysis runs seven times to simulate one week of traffic. We ran the Usage Analytics job every day for the data that we accumulated over six days. Then we measured the time, the seventh day took. The seventh day will be the day that takes longest to process as the complete week's items are processed and the relationship graph is updated. The runtime and disk usage for Day 8 will resemble Day 1.

分析處理並未對執行它的電腦造成重大影響,因此我們得以繼續成功地服務查詢,並使搜尋驅動式網站上保持新鮮的內容。The analytics processing did not have a significant impact on the computer that it ran on, and we continued to successfully serve queries and keep content fresh on the search-driven site.

結果彙總於下表:The results are summarized in the following table:

測試排程Test Schedule 更新關係圖Update Relationship Graph 執行階段 (小時)Runtime (hours) 總尖峰磁碟使用量Total Peak Disk Usage 流量分析尖峰磁碟使用量Usage Analytics Peak Disk Usage
第 1 天Day 1
No
02:3502:35
2.65 GB2.65 GB
Day 2Day 2
No
02:4302:43
一天 3Day 3
No
03:2303:23
一天 4Day 4
No
04:3904:39
一天 5Day 5
No
06:0806:08
一天 6Day 6
No
07:3507:35
一天 7Day 7
Yes
08:2908:29
82.4 GB82.4 GB
4 GB4 GB

下圖顯示各天的執行時間:The following graph displays the runtimes for the different days:

圖 7: 每天的執行階段時數Figure 7: Runtime hours per day

這個 Excel 長條圖顯示 7 個不同的測試日期,以及每天測試的時間量。第 1 天,我們測試了 2 小時 35 分鐘,而在第 7 天結束時,測試了 8 小時 29 分鐘。

對經驗證使用者的跨網站發佈Cross-site publishing with authenticated users

內部網路網站一般用於 SharePoint 發佈功能。使用 SharePoint Server 2013,這些網站可開機的跨網站發佈。下列各節說明一些重要差異考慮當您規劃使用驗證使用者的跨網站發佈的網站。以外的下列各節中提及的例外,套用至可匿名存取網站的規則仍適用於驗證的使用者存取的網站。SharePoint publishing is used commonly on intranet sites. By using SharePoint Server 2013, these sites can also be powered by cross-site publishing. The following sections show some important distinctions to consider when you plan for a cross-site publishing site that uses authenticated users. Other than the exceptions mentioned in the following sections, the rules that apply to anonymously accessed sites still apply to sites that authenticated users access.

缺乏匿名搜尋結果快取Lack of Anonymous Search Results Cache

如先前所述的匿名搜尋結果快取] 區段中,此快取僅會生效的匿名存取 SharePoint 網站的使用者。相較於使用匿名搜尋結果快取的匿名存取網站,由已驗證的使用者存取的網站的輸送量容量會大幅降低。內部網路網站通常很少接收高達過前一節中提及的負載 (最多 100 個網頁檢視 / 秒)。但是,這是要考量的重要差別。As mentioned in the Anonymous Search Results Cache section earlier, this cache only takes effect for users who are accessing the SharePoint site anonymously. Compared to anonymously accessed sites that use the Anonymous Search Results Cache, the throughput capacity of sites that are accessed by authenticated users will be significantly lower. Typically intranet sites rarely receive loads as high as the ones mentioned in the previous section (up to 100 page views / second). However, this is an important distinction to consider.

在這些案例中,使用輸出快取可以將缺乏匿名搜尋結果快取所造成的影響減輕一些。如果預期跨網站發佈網站每秒會有多個頁面檢視,則應該考慮對其網站啟用輸出快取。Use of the output cache can ease the lack of Anonymous Search Results Cache to a degree for these scenarios. Cross-site publishing sites that expect multiple page views per second should consider enabling output cache for their sites.

重要

內容搜尋網頁組件有項設定會使自己以非同步模式執行 (如果啟用的話)。輸出快取並不適用於來自非同步內容搜尋網頁組件的負載。Content Search Web Parts have a setting that, if it is enabled, causes them to run in asynchronous mode. The output cache does not apply to the load from asynchronous Content Search Web Parts.

搜尋索引較大Larger Search index

根據部署 SharePoint Server 2013 的企業的大小、 SharePoint Server 2013 的內部網路部署通常會索引更大的數字的文件。這表示這些文件編製索引所需的搜尋拓撲也不同相較於前一節所述的拓撲。請參閱 < Plan search in SharePoint Server適當地調整您的 SharePoint 部署的大小。Depending on the size of the enterprise that deploys SharePoint Server 2013, intranet deployments for SharePoint Server 2013 will typically index larger numbers of documents. This means that the required Search topology to index those documents will be different compared to the topology described in the previous section. Refer to Plan search in SharePoint Server to size your SharePoint deployment appropriately.

就地編寫型發佈Author-in-place publishing

本節提供指引與使用 SharePoint Server 2013 的結果,但它不會不將詳細說明會影響容量規劃的不同功能。如需在此區域的詳細資訊,請參閱SharePoint Server 中的 Web 內容管理This section provides guidance and results that use SharePoint Server 2013, but it does not detail the different features that affect capacity planning. For details in this area, see Web content management in SharePoint Server.

有匿名使用者時的就地編寫型發佈Author-in-place publishing with anonymous users

在測試中,我們使用具有下列特性的網站:For our tests we worked with a website that has the following characteristics:

  • 網站,有最多 20,000 個文章頁面分成 20 個資料夾 (每個資料各 1,000 個頁面),散布在單一網站集合中的 50 個網站。Website with up to 20,000 article pages divided into 20 folders of 1,000 pages each across 50 sites in a single site collection.

  • 網站使用結構化導覽。The site uses structured navigation.

  • 網站一般每秒至少會接收 50 到 100 個網頁檢視。The site generally receives a minimum of 50 to 100 page views per second.

  • 流量模式符合下列頁面組合:Traffic patterns hit the following mix of pages:

    • 20 個頁面,包含單一內容查詢網頁組件,會發出不同範圍的內容資料庫查詢 (20% 的流量)20 pages that contain a single Content Query Web Part that issues content database queries of varying scopes (20 percent of the traffic)

    • 30 個頁面,包括多個內容查詢網頁組件,會發出不同範圍的內容資料庫查詢 (30% 的流量)30 pages that include multiple Content Query Web Parts that issue content database queries of varying scopes (30 percent of the traffic)

    • 1,600 篇文章,含有 40k 的文字和兩個影像 (接收 50% 的流量)1,600 articles with 40k of text and two images (receives 50 percent of the traffic)

下圖是建議的伺服器拓撲:The recommended server topology is in the following diagram:

圖 8: 就地作者發佈測試拓撲Figure 8: Author-in-place publishing test topology

這個 Visio 圖表適用於就地製作測試的測試伺服器拓撲。這個測試拓撲包含 1 部裝載 SQL Server 的電腦,以及 1 部裝載 SharePoint Service 應用程式且當成前端網頁伺服器執行的電腦。

  • 1 部電腦裝載 SQL Server1 computer hosting SQL Server

  • 1 部電腦裝載 SharePoint 服務應用程式,以作為前端網頁伺服器1 computer hosting SharePoint service applications as the front-end web server

測試實驗室結果Test lab results

我們運用上圖所示的拓撲,在測試實驗室中使用實體電腦與一項 Visual Studio Team System 負載測試。We used the topology shown in the previous diagram in our test lab by using physical computers and a Visual Studio Team System load test.

下表顯示我們在測試的電腦中使用的技術規格:The following table shows the technical specifications that we used in the computers that we tested:

伺服器元件Server Components SharePoint 伺服器SharePoint Servers
處理器Processors
Intel Xeon CPU @2.33GHz (2 個處理器、 8 個核心總計、 8 的執行緒總數)Intel Xeon CPUs @2.33GHz (2 processors, 8 cores total, 8 threads total)
RAMRAM
24 GB24 GB
作業系統Operating system
Windows Server 2008 R2 Enterprise 64 位元Windows Server 2008 R2 Enterprise, 64-bit
網路介面卡數目Number of network adapters
22
網路介面卡速度Network adapter speed
1 Gbps1 Gbps
驗證Authentication
無 - 匿名None ─ Anonymous
負載平衡器類型Load balancer type
Windows 軟體負載平衡器Windows software load balancer
軟體版本Software version
SharePoint Server 2013SharePoint Server 2013
伺服器元件Server Components 資料庫伺服器Database server
處理器Processors
Intel Xeon CPU MP7130M @2.79GHz (2 個處理器,共 8 個核心與 16 個執行緒)Intel Xeon CPUs MP7130M @2.79GHz (2 processors, 8 cores total, 16 threads total
RAMRAM
16 GB16 GB
作業系統Operating system
Windows Server 2008 R2 Enterprise 64 位元Windows Server 2008 R2 Enterprise, 64-bit
磁碟陣列Disk array
2 x Dell PERC 5/E2 x Dell PERC 5/E
網路介面卡數目Number of network adapters
11
網路介面卡速度Network adapter speed
1 GB 或 Gbps1 gigabit or Gbps
驗證Authentication
NTLMNTLM
軟體版本Software version
Microsoft SQL Server 2008 R2 SP1Microsoft SQL Server 2008 R2 SP1

下表顯示執行 10 分鐘的結果:The following table shows our results for a 10-minute run:

測試功能Test Features 綠色區域Green Zone 紅色區域Red Zone
VSTS 使用者數目:Number of VSTS users:
55
1515
伺服器回應時間第 50 個百分位數:Server Response Time 50th percentile:
69 毫秒69 ms.
112 毫秒112 ms.
伺服器回應時間 95th 百分位數:Server Response Time 95th percentile:
92 毫秒92 ms.
221 毫秒221 ms.
每秒網頁檢視:Page views per second:
5757
9393
平均 CPU (應用程式伺服器和前端網頁伺服器)Average CPU (application server and front-end web server)
5555
9797
平均 CPU (SQL Server)Average CPU (SQL Server)
77
99
尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器)Peak memory usage (application server and front-end web server)
8.9 GB8.9 GB
8.9 GB8.9 GB

輸出快取所造成的影響Effect of output cache

輸出快取是有效的方式來減少在 SharePoint Server 2013 中發佈案例的負載。如需詳細資訊,請參閱規劃快取及 SharePoint Server 中的效能Output caching is an effective way to reduce the load on SharePoint Server 2013 in publishing scenarios. For more information, see Plan for caching and performance in SharePoint Server.

下表顯示在已啟用輸出快取且點擊比率達 90% 的情況下,執行 10 分鐘的結果:The following table shows our results for a 10-minute run with output cache enabled and a 90 percent hit ratio:

測試功能Test Features 綠色區域Green Zone 紅色區域Red Zone
VSTS 使用者數目:Number of VSTS users:
55
1515
伺服器回應時間第 50 個百分位數:Server Response Time 50th percentile:
2 毫秒2 ms.
2 毫秒2 ms.
伺服器回應時間 95th 百分位數:Server Response Time 95th percentile:
74 毫秒74 ms.
88 毫秒88 ms.
每秒網頁檢視:Page views per second:
190190
418418
平均 CPU (應用程式伺服器和前端網頁伺服器)Average CPU (application server and front-end web server)
5858
8585
平均 CPU (SQL Server)Average CPU (SQL Server)
55
77
尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器)Peak memory usage (application server and front-end web server)
9.2 GB9.2 GB
9.4 GB9.4 GB

測試結果顯示,使用輸出快取可以大幅增加 SharePoint 發佈網站的輸送量,並且減少伺服器回應時間。對於由輸出快取服務的要求,回應時間幾乎為馬上。The test results show that using output caching can significantly increase the throughput of a SharePoint publishing site and reduce server response times. For requests served from the output cache, the response times are almost instant.

下圖顯示測試結果的摘要:The following graph shows a summary of our testing results:

圖 9: 之影響的輸出快取與 90%快取點擊比率Figure 9: Effect of output caching with 90% cache hit ratio

這個 Excel 長條圖顯示在綠色與紅色區域中使用輸出快取的影響。輸出快取會減少伺服器回應時間並增加 SharePoint 發佈網站輸送量,如果未使用,就能減少輸送量,但會增加伺服器回應時間。

受管理導覽所造成的影響Effect of managed navigation

在 SharePoint Server 2013 中發佈網站也可以使用受管理的導覽。如需如何設定此的詳細資訊,請參閱 < SharePoint Server 中的受管理導覽的概觀In SharePoint Server 2013, publishing sites can also use managed navigation. For details on how to set this up, see Overview of managed navigation in SharePoint Server.

我們對使用受管理導覽的測試網站,進行了一組我們在結構化導覽測試中所進行的相同測試。測試結果顯示,網站不論使用受管理導覽還是結構化導覽,在效能上都沒有重大差異。We ran the same set of tests for our test site using managed navigation as we used for the structured navigation tests. Our tests show that there is no significant difference in performance when sites use managed navigation or structured navigation.

測試功能Test Features 綠色區域Green Zone 紅色區域Red Zone
VSTS 使用者數目:Number of VSTS users:
55
1515
伺服器回應時間第 50 個百分位數:Server Response Time 50th percentile:
70 毫秒70 ms.
111 毫秒111 ms.
伺服器回應時間 95th 百分位數:Server Response Time 95th percentile:
95 毫秒95 ms.
215 毫秒215 ms.
每秒網頁檢視:Page views per second:
5656
9494
平均 CPU (應用程式伺服器和前端網頁伺服器)Average CPU (application server and front-end web server)
5454
9797
平均 CPU (SQL Server)Average CPU (SQL Server)
77
99
尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器)Peak memory usage (application server and front-end web server)
8 GB8 GB
8 GB8 GB

下圖顯示相同的網站使用不同類型之導覽時的結果:The following graph shows the different types of navigation for the same site:

圖 10: 受管理的導覽與結構化導覽的比較Figure 10: Managed Navigation versus Structured Navigation

這個 Excel 長條圖顯示在綠色與紅色區域中使用受管理導覽與結構化導覽的影響。比較結果顯示使用受管理導覽或結構化導覽都一樣。

新增電腦 (向外擴展) 所造成的影響Effect of adding computers (scaling out)

如果您找出您必須從 SharePoint 部署多個輸送量、 向外延展 (增加主控 SharePoint Server 2013 的電腦數目) 是要考慮的選項。下圖顯示當我們將更多電腦新增至伺服器陣列輸送量會增加的方式:If you find that you need more throughput from a SharePoint deployment, scaling out (increasing the number of computers that host SharePoint Server 2013) is an option to consider. The following graph shows how throughput increases as we add more computers to the farm:

圖 11: 新增前端網頁伺服器對輸送量造成的影響Figure 11: Effect on throughput by adding front-end web servers

這個 Excel 圖表顯示新增前端網頁伺服器以及在紅色與綠色區域中於這些伺服器上增加負載的影響。從某一部前端網頁伺服器開始並到 3 結束,輸送量幾乎會在同一時間增加 (以毫秒計算)。

在我們的測試我們會增加執行 SharePoint Server 2013 已新增使伺服器回應時間已大約相同 (筆 11 毫秒的綠色區域的紅色區域的筆 250 毫秒) 每部電腦的伺服器上的負載。In our tests we increased the load on the server running SharePoint Server 2013 for each computer that was added so that the server response times were approximately the same (around 11 milliseconds for the green zone, around 250 milliseconds for the red zone).

有經驗證使用者時的就地編寫型發佈網站Author-in-place publishing sites with authenticated users

SharePoint 發佈功能通常用於內部網路,而在內部網路中,存取網站的使用者都經過驗證。本節說明我們使用經驗證使用者進行的測試,以及所造成的影響。The SharePoint publishing feature is used commonly in the intranet where users who access a site are authenticated. This section shows our tests that used authenticated users and the effects.

下表針對經驗證使用者透過搭配使用宣告式驗證與 NTLM 來存取的就地編寫型發佈網站,顯示測試結果。請注意,這些測試中所使用的硬體與上節中的測試完全相同。The following table shows the test results of author-in-place publishing sites that authenticated users accessed by using claims-based authentication with NTLM. Note that these tests use identical hardware as the tests in the previous section.

測試功能Test Features 綠色區域Green Zone 紅色區域Red Zone
VSTS 使用者數目:Number of VSTS users:
55
1515
伺服器回應時間第 50 個百分位數:Server Response Time 50th percentile:
76 毫秒76 ms.
107 毫秒107 ms.
伺服器回應時間 95th 百分位數:Server Response Time 95th percentile:
103 毫秒103 ms.
194 毫秒194 ms.
每秒網頁檢視:Page views per second:
5454
100100
平均 CPU (應用程式伺服器和前端網頁伺服器)Average CPU (application server and front-end web server)
5050
9797
平均 CPU (SQL Server)Average CPU (SQL Server)
66
99
尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器)Peak Memory Usage (application server and front-end web server)
9.5 GB9.5 GB
9.5 GB9.5 GB

這些數字顯示,無論是使用匿名要求還是經驗證要求,伺服器回應時間與輸送量並無太大不同。The numbers show that there is no significant difference between anonymous versus authenticated requests according to the server response times and throughput.

下圖顯示相同網站使用不同類型之要求時的結果:The following graph shows the different types of requests for the same site:

圖 12: 匿名要求與經驗證要求的比較Figure 12: Anonymous requests versus authenticated requests

這個 Excel 圖表顯示在綠色與紅色區域中使用匿名要求與通過驗證之要求的等比例效能。

輸出快取在經驗證案例中所造成的影響Effect of Output Cache in authenticated scenarios

向伺服器提出的經驗證要求,需要往返內容資料庫一趟,以確保存取內容的帳戶具有檢視內容的權限。這表示輸出快取的效能特性在經驗證網站上與在匿名網站上並不同。Authenticated requests to the server require a roundtrip to the content database to make sure that the account that is accessing the content has permissions to view the content. This means that the output caching performance characteristics of authenticated sites are different compared to anonymous sites.

下表顯示在已啟用輸出快取且快取點擊比率達 90% 的情況下,執行 10 分鐘所得到的結果:The following table shows the results we received for a 10 minute run with output cache enabled and a 90 percent cache hit ratio:

測試功能Test Features 綠色區域Green Zone 紅色區域Red Zone
VSTS 使用者數目:Number of VSTS users:
66
1818
伺服器回應時間第 50 個百分位數:Server Response Time 50th percentile:
17 毫秒17 ms.
29 毫秒29 ms.
伺服器回應時間 95th 百分位數:Server Response Time 95th percentile:
87 毫秒87 ms.
118 毫秒118 ms.
每秒網頁檢視:Page views per second:
114114
236236
平均 CPU (應用程式伺服器和前端網頁伺服器)Average CPU (application server and front-end web server)
5050
9797
平均 CPU (SQL Server)Average CPU (SQL Server)
77
1010
尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器)Peak Memory Usage (application server and front-end web server)
9.9 GB9.9 GB
10 GB10 GB

下圖顯示這些結果的摘要:The following graph shows the summary of these results:

圖 13: 經驗證的輸出快取的影響Figure 13: Effect of authenticated output caching

這個 Excel 長條圖顯示在綠色與紅色區域中使用驗證輸出快取的影響。相較於匿名要求,使用通過驗證的要求時,往返時間 (以毫秒為單位) 會增加。

另請參閱See also

概念Concepts

在 SharePoint Server 中規劃 Web 內容管理Web content management in SharePoint Server

在 SharePoint Server 中設定 web 內容管理解決方案Configure web content management solutions in SharePoint Server

在 SharePoint Server 中設定 web 應用程式的快取設定Configure cache settings for a web application in SharePoint Server

在 SharePoint Server 中規劃快取及效能Plan for caching and performance in SharePoint Server