評估 Web Content Management 的容量和效能 (SharePoint Server 2013)

  • 發行項

 

**適用版本：**SharePoint Server 2013

**上次修改主題的時間：**2017-08-25

**摘要：**了解如何確定在 SharePoint Server 2013 中發佈內容和管理 Web 內容所需的電腦數量與類型。

企業通常會使用SharePoint Server 2013發佈於網際網路網站或匿名使用者存取內部網路網站上的使用者存取經過驗證的內容。本文包含可協助您規劃要使用的電腦數目和電腦所發佈的內容和管理SharePoint Server 2013中的網站內容類型的容量與效能資料。

本文內容：

  • 簡介

  • 先決條件資訊

  • 使用受管理導覽進行跨網站發佈

  • 就地編寫型發佈

SharePoint 發佈功能包括不同類型的發佈網站及可用的每個網站的相關的方法。SharePoint Server 2013的發佈功能都是以協助您建立加上品牌的網際網路、 內部網路及外部網路網站。如需SharePoint Server 2013發佈功能的詳細資訊，請參閱在 SharePoint Server 中發佈至網際網路、內部網路及外部網路網站的功能概觀。

簡介

本文討論下列案例：

  • 網際網路形象網站

    提供資訊給客戶、合作夥伴、投資人及潛在員工。這類型的網站可讓匿名網際網路使用者尋找公司的相關資訊。這些網站通常具有品牌風格，而且對內容的控制乃緊緊握在公司手中。

  • 網際網路商業網站

    推廣公司向客戶提供的產品與服務。這些網站可能會顯示公司所提供產品的目錄。

  • 內部網路網站

    公司對組織內部公開此網站。這些網站會分享資訊給經驗證使用者，而公司會嚴管網站來限制存取，或將網站開放給所有內部使用者。

  • 外部網路網站

    讓遠端員工、合作夥伴及客戶存取相關內容。這些網站可用來存取知識庫，而知識庫會將已編寫的內容以中繼資料標記，以將文章分類。使用者可以搜尋或瀏覽特定資訊，例如疑難排解與支援文章。

在這些案例中，跨網站集合發佈和內容搜尋網頁組件使得內容可以跨網站集合中來重複使用。這些功能會影響您的容量規劃。如需詳細資訊，請參閱＜SharePoint Server 的跨網站發佈概觀＞。

注意

在本文中，「跨網站集合發佈」稱為「跨網站發佈」。

SharePoint Server 2013中的受管理的導覽提供分類驅動的導覽的發佈網站。如需詳細資訊，請參閱SharePoint Server 中受管理導覽的概觀。

本文中的容量與效能資料包含兩個部分。第一個部分是新的跨網站發佈方法和受管理導覽。第二個部分則使用就地編寫模型。

注意

本文所處理的案例，透過跨網站發佈和就地編寫網站皆可以達成。跨網站發佈和受管理導覽功能並不彼此依賴，可以單獨使用。

本文所用的模型中會處理下列兩個重要度量：

  • 輸送量

    網站可以維持的每秒網頁檢視數

  • 伺服器回應時間

    伺服器處理要求所需的時間，這會影響使用者檢視頁面所需的時間。本文件中提供的伺服器回應時間是第 95 個和第 50 個百分位數值。這些值分別表示有 95% 和 50% 的要求會比所提供的值還要快。我們測量這些值的方式，是使用 SharePoint 流量資料庫中針對某個要求所記錄的 "Duration"。

  • 內容新鮮度

    在面對跨網站發佈案例時，更新的項目反映在搜尋結果中所需的時間，這是值得考慮的不錯度量。

本文中的案例使用下列兩種狀態：

  • 綠色區域

    伺服器使用率低於 60%。這應該是伺服器執行時大多數時間的目標。

  • 紅色區域

    伺服器使用率快接近全滿。此狀態可以視為 SharePoint 網站正承受比平時還高的負載。在紅色區域，當伺服器嘗試滿足內送要求的需求，伺服器回應時間值會開始增加。

必要資訊

閱讀本文之前，請確定您了解SharePoint Server 2013容量管理的重要概念。下列文章可協助您了解容量管理的建議方法並提供可協助您了解如何有效利用資訊的本文中的內容。

請注意，本文中並不會出現其他一些會影響發佈案例效用的新功能。這些案例包括裝置通道、SEO 最佳化、顯示範本和查詢規則。此外，本文也未詳述跨網站發佈網站的功能和設定。如需詳細資訊，請參閱＜規劃 SharePoint Server 的跨網站發佈＞和＜在 SharePoint Server 中設定 web 內容管理解決方案＞。

如需容量和效能的詳細資訊以瞭解本文中的資料，請參閱＜規劃 SharePoint Server 2013 中規劃效能＞。

使用受管理導覽進行跨網站發佈

本節提供兩個方面的測試資料：對匿名使用者的跨網站發佈與就地編寫型發佈。

對匿名使用者的跨網站發佈

本節中的測試結果是以基本的跨網站發佈網站模型為根據，藉以提供容量規劃指引。規劃 SharePoint 部署以讓匿名使用者存取網站時，請使用本指引，並據以調整您的部署規格。

測試中採用的測試案例使用跨網站發佈功能。此案例以多個網站集合提供內容，這些網站集合先是被標示為目錄，然後由 SharePoint Search Service 應用程式編目。內容會透過使用搜尋技術的網頁組件 (例如內容搜尋網頁組件和目錄項目重複使用網頁組件) 顯示在另一個網站的頁面上。如需詳細資訊，請參閱＜SharePoint Server 的跨網站發佈概觀＞。

我們為了測試跨網站發佈而建置的模型站台具有下列特性：

  • 發佈網站，大約有 5 百萬個頁面或項目。

  • 項目大約有 1,000 個相關聯的類別。

  • 內容位於其他網站集合中，一或多個目錄裡。

  • 網站使用受管理導覽，提供與項目相關聯之類別的連結。

  • 在本清單稍後描述的基準部署拓撲中，網站平均每秒最多接收 80 個網頁檢視。尖峰期間則每秒最高可達 100 個網頁檢視。若要增加此輸送量數字，請新增電腦至拓撲。若要減少此輸送量數字，請從拓撲中移除電腦。

  • 搜尋編目程式會以連續 1 分鐘的間隔 (每秒對目錄更新五次) 執行連續編目。

  • 網站具有下列頁面和流量模式：

    • 首頁，具有三個內容搜尋網頁組件和一個精簡搜尋面板網頁組件，共接收 15% 的流量。

    • 各類別頁面，具有三個內容搜尋網頁組件、一個分類精簡搜尋面板網頁組件，以及一個精簡搜尋面板網頁組件，共接收 45% 的流量。

    • 各目錄項目頁面，具有一個目錄項目重複使用網頁組件和兩個內容搜尋網頁組件，共接收 40% 的流量。

  • 每個內容搜尋與目錄項目重複使用網頁組件都會發出一個同步查詢。

  • 目錄項目頁面因為接收的流量不多，所以未使用匿名搜尋結果快取。

  • 伺服器陣列對當成前端網頁伺服器來執行的電腦，開啟二進位大型物件 (BLOB) 快取。

下圖是用來測試此案例的伺服器拓撲：

圖 1：測試實驗室伺服器拓撲

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

  • 一部電腦負責裝載 SQL Server (含有 SharePoint 使用的所有資料庫)

  • 一部電腦負責裝載 SharePoint 服務應用程式、分散式快取服務、搜尋分析資料處理與搜尋管理角色

  • 一部電腦負責裝載搜尋編目程式與內容處理 (CPC) 角色

  • 三部電腦負責裝載含有查詢處理機制的搜尋索引節點，並作為前端網頁伺服器

注意

此測試中採用的電腦是執行 Windows Server 2008 R2 的實體電腦。請參閱搜尋容量規劃和＜SharePoint Server 2013 的容量規劃＞，以取得關於如何使用虛擬機器和 Windows Server 2012 的建議。

重要

測試實驗室採用的拓撲組態已針對搜尋驅動式發佈案例進行最佳化。此組態與 SharePoint 部署的協同合作類型不同。例如，此組態使用前端網頁伺服器作為搜尋索引伺服器，以取得最佳效能。
在測試實驗室拓撲中，我們發現裝載應用程式伺服器的電腦未受到充分利用。因此，我們將分散式快取服務放在此應用程式伺服器上，而非專用伺服器上。在您的環境中，您可以決定將分散式快取服務裝載於專用伺服器上。為達到最佳效能，不建議您將分散式快取服務裝載於具有搜尋索引伺服器角色的前端網頁伺服器上。

測試實驗室報告

我們的測試實驗室與實體電腦和 Visual Studio Team System (VSTS) 負載測試使用圖 1 中的拓撲。如需詳細資訊，請參閱Visual Studio Team System。適用於測試電腦的技術規格是如下表所示。

注意

我們未使用瀏覽器快取或相依要求 (例如 VSTS 測試中的影像或 JavaScript 檔案)。依您自訂發佈網站的方式而定，發生的相依要求數量可能會有很大的不同。
我們在測試中所採用的頁面發出幾乎 50 個頁面載入時間 1 (PLT1) 要求類型 (空的瀏覽器快取) 和大約 3 個 PLT2 要求類型的要求 (後續要求，由瀏覽器快取提供結果)。索取這些項目的要求通常是由 SharePoint BLOB 快取，而不會大幅改變我們的效能數字。

伺服器元件 執行 SharePoint Server 的伺服器

處理器

Intel Xeon CPUs @2.27GHz (2 個處理器、 8 個核心總計、 16 的執行緒總數)

RAM

24 GB

作業系統

Windows Server 2008 R2 Enterprise SP1 64 位元

SharePoint 磁碟機的大小

內部磁碟 200 GB

用於搜尋索引的儲存體

外部磁碟陣列 78 GB (2 個 Dell PERC H700 SCSI)

網路介面卡的數量

1

網路介面卡速度

1 GB

驗證

無 - 匿名

軟體版本

SharePoint Server 2013
伺服器元件 資料庫伺服器

處理器

Intel Xeon CPU L5520 @2.27GHz (2 個處理器，共 8 個核心與 16 個執行緒)

RAM

24 GB

作業系統

Windows Server 2008 R2 Enterprise SP1 64 位元

磁碟陣列

2 個 Dell H700 SCSI

網路介面卡的數量

1

網路介面卡速度

1 GB

驗證

NTLM

軟體版本

Microsoft SQL Server 2008 R2 SP1

執行 10 分鐘的結果如下：

測試功能 綠色區域 紅色區域

VSTS 使用者數目 (模擬並行使用者)：

60

100

伺服器回應時間第 50 個百分位數*：

219 毫秒

302 毫秒

伺服器回應時間第 95 個百分位數*：

412 毫秒

635 毫秒

每秒網頁檢視：

78

98

這是個會顯示搜尋索引中之內容的跨網站發佈案例。不妨來看看搜尋查詢所在之伺服器所服務的查詢數目，以及匿名結果快取所服務的查詢數目。在此模型中，匿名結果快取服務大約 60% 的查詢。本文稍後會討論匿名結果快取。

測試功能 綠色區域 紅色區域

每秒總查詢：

235

294

匿名結果快取所服務的查詢：

145

182

搜尋所服務的查詢：

90

112

執行測試時這些電腦的平均 CPU 與尖峰記憶體使用量值如下：

測試功能 綠色區域 紅色區域

平均 CPU (每個前端網頁伺服器的搜尋索引節點)

59%

80%

平均 CPU (應用程式伺服器，含分散式快取)

8%

9%

平均 CPU (搜尋 CPC 節點)

5%

5%

平均 CPU (SQL Server)

未測量

未測量

尖峰記憶體使用量 (每個前端網頁伺服器的搜尋索引節點)

7.5 GB

7.5 GB

尖峰記憶體使用量 (應用程式伺服器，含分散式快取)

10.1 GB

10 GB

尖峰記憶體使用量 (搜尋 CPC 節點)

6.5 GB

6.5 GB

請注意，因為正常流量期間伺服器上執行的計時器工作各有不同，所以記憶體使用量可能會有一些不同。在能夠維持負載的情況下執行測試兩週之後，我們發現索引/前端網頁伺服器節點使用多達 12 GB 的記憶體。

搜尋網頁組件如何在跨網站發佈頁面上顯示內容

如果發佈頁面包含搜尋網頁組件 (例如內容搜尋網頁組件)，瀏覽器會在搜尋查詢還沒完成時就開始處理頁面。如此可以改善使用者感受到的頁面延遲。搜尋查詢完成後，就會傳送完整的查詢結果給瀏覽器，並關閉與瀏覽器的連線。使用者可能會覺得搜尋結果的載入並不同步。不過，查詢仍然是在還在接收索取頁面的要求時，就由伺服器發出。

請注意，內容搜尋網頁組件乃另採非同步模式，亦即等到頁面載入完畢後，才從瀏覽器發出查詢。

跨網站發佈網站上的負載變更所造成的影響

負載測試中採用了各種 VSTS 使用者數目 (類似同時存取網站的並行使用者數目)。下圖顯示，隨著負載增加，伺服器回應時間也跟著增加，且每秒服務的頁面數也呈現某種幅度的遞增。建議將伺服器回應時間保持在 750 毫秒以下，以確保使用者在使用 SharePoint 部署時不會覺得回應速度太慢。

圖 2：圖中顯示不同負載下的輸送量與伺服器回應時間

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

向外擴充跨網站發佈網站

如果您預期 SharePoint 部署接收的流量會比稍早所述的基準案例更多或更少，可以變更伺服器陣列上以索引與前端網頁伺服器角色執行的電腦數目，以配合該流量。下圖顯示在不同的負載模式下，和不同數目的前端網頁伺服器 (含有索引節點) 電腦下，向外擴充同一個跨網站發佈網站的結果；測試是先從只有一部前端網頁伺服器角色 (含有索引節點) 電腦的情況下開始進行，然後逐漸增加到六部電腦：

圖 3：向外擴充部署

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

在這每個組態中，我們已調整負載，讓伺服器回應時間的值與上節中的基準值差不多。

請注意，隨著電腦數目增加，拓撲複雜性升高所帶來的負面效應開始超越正面效應。相較於已在環境中的電腦，每部多加的電腦所獲得的輸送量都變得更少。提供這些數字，是為了顯示向外擴充時的模式。實際效能會依 SharePoint 部署的建置方式而異。

規劃網站時的指導方針

我們的效能測試多半使用稍早各節所述的部署。若您的部署與測試實驗室中所用的不同，下列清單提出的指導方針，可協助您進行正確的容量規劃決策。

  • 搜尋索引中的項目越多，通常會造成越高的延遲。每個索引分割區可以包含最多 1 千萬個項目。一般網站極少需要顯示多於 1 千萬個項目。因此，這些網站只需要一個分割區 (如稍早所述拓撲中的分割區)。若要裝載多於 1 千萬個項目，或想要有較多、較小、較快的索引分割區，您可以使用更多的索引分割區。如果您打算使用多個索引分割區，請參閱＜在 SharePoint Server 中擴充網際網路網站的搜尋＞來正確決定搜尋拓撲的大小。

  • 您每新增一個控制項或網頁組件到頁面 (或頁面版面配置)，都會對頁面的伺服器回應時間增加一些影響。

  • 避免使用五個以上同步內容搜尋網頁組件或目錄項目重複使用網頁組件頁面上。同時處理的要求] 頁面上， SharePoint Server 2013同時執行最多 5 個查詢，並傳回結果。如果五個以上的查詢] 頁面上，開始執行下一組的五個查詢之前SharePoint Server 2013會執行前五個查詢。如果頁面需要五個以上的內容搜尋網頁組件或目錄項目重複使用網頁組件，您可能會在非同步模式下執行額外的內容搜尋網頁組件或使用查詢規則和結果區塊。

  • 內容搜尋網頁組件和目錄項目重複使用網頁組件具有非同步模式。瀏覽器載入頁面後，就會執行與網頁組件相關聯的查詢。如果查詢速度會很慢，請使用此模式，讓使用者更快看到頁面的其餘部分。否則，建議您使用同步查詢來達到最佳頁面載入時間。

  • 如果精簡搜尋面板網頁組件有多個精簡器，則查詢處理時間會增加。您可以針對受管理屬性來變更要顯示的精簡器數目。如需詳細資訊，請參閱＜在 SharePoint Server 中設定精簡器和多面向導覽＞。

  • 如果導覽節點階層有很多層，而您使用分類精簡搜尋面板網頁組件，則查詢處理時間會增加。不建議在底下有多於 200 個導覽節點的頁面上使用分類精簡搜尋面板網頁組件。導覽節點太多可能會導致伺服器回應時間緩慢，並使輸送量降低。

  • 如果您必須設計高度可用的 SharePoint 部署，則必須新增下列項目：

    • 額外一部電腦，負責在現有電腦無法使用時，與分散式快取角色的服務應用程式一起執行

    • 額外一些電腦，負責在有一或多部含有索引節點的前端網頁伺服器電腦無法使用時，維持負載

    • 額外一部 CPC 角色的電腦，以確保當具有 CPC 角色的電腦無法使用時，網站中仍然會反映更新

    • 一套 SQL Server 拓撲，負責在其中一部資料庫伺服器無法使用時，繼續服務資料庫查詢

搜尋編目速度與內容新鮮度

在測試過程中，我們也測試了所發佈目錄內容的更新程序。接著，我們觀察更新的項目出現在發佈網站中之前經過的時間量。在實驗中，我們每秒對目錄進行更新五次，並將目錄上的連續編目設為一分鐘間隔。我們觀察到這些變更出現在發佈網站中所需的時間平均約為兩分鐘。最短時間為快滿一分鐘，最長時間則為三分鐘。增加以 CPC 角色執行的電腦數目時，這些數字並未出現重大變更。

不過，就目錄的完整編目而言，增加以 CPC 角色執行的電腦數目，也會增加每秒處理的項目數。下圖顯示每秒處理的項目數目與伺服器陣列中具有 CPC 角色之電腦數目的關係。請注意，此測試資料取自的 SharePoint 部署，並非基準測試中所使用的部署。這些結果應套用於 SharePoint 部署，因為新增更多 CPC 節點，將可改善完整編目時間。

圖 4：內容處理 (CPC) 電腦對完整編目所造成的影響

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

因此，如果您需要更快地完整編目目錄，可以在部署中增加使用 CPC 角色的電腦數目。

Managed Metadata Service 應用程式上的負載

我們的測試顯示，在有網站使用受管理導覽的發佈案例中，Managed Metadata Service 應用程式上沒有重大的記憶體或 CPU 需求。對於如稍早所述的部署，Managed Metadata Service 應用程式可能是在執行其他 SharePoint 服務應用程式的電腦上執行。受管理導覽功能會在接收到第一個索取網站的要求時，對該服務應用程式建立一個連線。後續要求則會使用前端網頁伺服器所快取的值。因此，當要求是由前端網頁伺服器滿足時，Managed Metadata Service 應用程式上就沒有負載。

匿名搜尋結果快取

匿名搜尋結果快取會儲存查詢的結果、查詢的精簡資料，以及其他從 SharePoint 分散式快取服務傳回的結果表格。每個快取項目皆取決於查詢的參數 (例如結果的排序順序)、所要求的精簡器以及任何動態重新排序規則。快取會影響 Web 應用程式處理的所有查詢，包括來自搜尋網頁組件的查詢以及來自 CSOM 用戶端的查詢。如需詳細資訊，請參閱＜SharePoint Server 的搜尋架構概觀＞和＜在 SharePoint Server 中擴充網際網路網站的搜尋＞。

此快取不會用於因安全性考量而受到驗證的查詢。

建議您設定只在執行 SharePoint 服務應用程式的電腦上執行分散式快取服務，以取得最佳結果。分散式快取服務不應該執行於擔任前端網頁伺服器角色的電腦上。

根據預設，匿名搜尋結果快取會每 15 分鐘重新整理一次項目。您可以使用 Microsoft PowerShell，在已設定此快取的 Web 應用程式上設定快取持續時間：

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

如果您希望搜尋結果的新鮮度比預設值所提供的高，請降低此值。請注意，這會增加搜尋服務所須服務的查詢數目。

建議您在接收高流量的發佈頁面上一律使用此快取。這類頁面的一些範例包括網站首頁，以及使用搜尋網頁組件的類別頁面。不建議針對目錄項目頁面進行快取，這是因為個別目錄項目頁面受到存取的機率遠少於首頁，而將這類項目儲存在快取中可能並不值得。

當我們在具有相同負載模式的測試環境中關閉匿名搜尋結果快取時，伺服器回應時間大幅增加，而每秒網頁檢視數目的輸送量減少。下圖顯示此關係：

圖 5：匿名搜尋結果快取所造成的影響

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

根據預設，內容搜尋網頁組件會設定成使用匿名搜尋結果快取。目錄項目頁面則因為通常只展現稀疏的存取模式，所以未被設定成使用它。

若要設定個別網頁組件的快取行為使用 (或不使用) 匿名搜尋結果快取，請在網頁組件的 DataProviderJSON 屬性中設定 "TryCache" 子屬性的值。如果值為 "true"，則查詢會使用快取。如果值為 "false"，則查詢不會對匿名搜尋查詢來使用快取。

輸出快取所造成的影響

輸出快取是有效的方式來減少SharePoint Server 2013發佈案例中的負載。如需詳細資訊輸出快取本文中的運作方式，請參閱輸出快取與快取設定檔。

SharePoint 部署可以利用輸出快取，減少 SharePoint 內容資料庫與搜尋服務應用程式所承受的負載。以下是一些範例情況：

  • 您有些頁面會一直接收到大量流量。

  • 您的 SharePoint 內容資料庫會一直接收到大量流量。

  • 用來服務搜尋查詢的電腦具有很高的 CPU 使用率。

建議您將輸出快取用於您網站上極常用的頁面，例如網站的首頁或最上層類別頁面，以及特定會接收到大量流量的項目頁面。

重要

當啟用輸出快取的頁面也包含內容搜尋網頁組件中SharePoint Server 2013有已知的問題。若要避免此問題部署中的，安裝SharePoint Server 2013 更新： 2013 年 3 月 12 日。

下圖顯示我們在測試環境中的首頁與接收 60% 網站流量的類別頁面上使用輸出快取時，所得到的一些結果。

圖 6：在首頁與類別頁面上使用輸出快取所造成的影響

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

注意

內容搜尋網頁組件有項以非同步模式執行的設定。輸出快取並不適用於來自非同步內容搜尋網頁組件的負載。

流量分析處理

若要可供使用SharePoint Server 2013流量分析的相關資訊會處理在使用狀況資料庫中的資訊。在我們的拓撲中分析處理發生在包含 [搜尋管理] 節點、 分散式快取服務和其他服務應用程式的節點。如需詳細資訊，請參閱SharePoint Server 的分析處理概觀

我們所需某些分析處理使用舊版測試中所用的跨網站發佈網站的時間單位。我們測量時間該SharePoint Server 2013取得處理大量的 click 事件在網站頁面上的。雖然這些結果是從跨網站發佈網站，但是他們也適用於使用-就地製作的發佈方法的網站。

為了測試流量分析處理，我們有整整一週每天都產生下列模擬事件：

  • 400,000 位使用者對 3 百萬個清單項目的 27,500,000 個 click 事件。

    我們採用 Zipf 分佈，讓一些項目和使用者具有許多事件，而讓其他項目和使用者具有較少的事件。

如此共產生了每天 7,500,000 個事件，以模擬不同使用者對網站產生的不同流量模式。

我們觸發了分析作業七次來模擬一週的流量。我們每天都對過去六天所累積的資料執行一次流量分析工作。然後，我們測量第七天所用的時間。第七天將是處理時間最長的那天，因為需要處理整週的項目並更新關係圖。第 8 天的執行時間和磁碟使用量會與第 1 天類似。

分析處理並未對執行它的電腦造成重大影響，因此我們得以繼續成功地服務查詢，並使搜尋驅動式網站上保持新鮮的內容。

結果彙總於下表：

測試排程 更新關係圖 執行時間 (小時) 總尖峰磁碟使用量 流量分析尖峰磁碟使用量

第 1 天

否

02:35

2.65 GB

第 2 天

否

02:43

第 3 天

否

03:23

第 4 天

否

04:39

第 5 天

否

06:08

第 6 天

否

07:35

第 7 天

是

08:29

82.4 GB

4 GB

下圖顯示各天的執行時間：

圖 7：每天的執行時間 (小時)

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

對經驗證使用者的跨網站發佈

內部網路網站一般用於 SharePoint 發佈功能。藉由使用SharePoint Server 2013，這些網站也可開機的跨網站發佈。下列各節說明一些重要差異考慮當您規劃使用驗證使用者的跨網站發佈的網站。以外的下列各節中提及的例外，套用至可匿名存取網站的規則仍適用於驗證的使用者存取的網站。

缺乏匿名搜尋結果快取

如稍早在＜匿名搜尋結果快取＞一節中所提，此快取只適用於匿名存取 SharePoint 網站的使用者。相較於使用匿名搜尋結果快取的匿名存取網站，經驗證使用者所存取網站的輸送量容量會低很多。內部網路網站通常很少會接收到如上節所提一樣高的負載 (最多 100 個頁面檢視/秒)。不過，這是需要考慮的重要差異。

在這些案例中，使用輸出快取可以將缺乏匿名搜尋結果快取所造成的影響減輕一些。如果預期跨網站發佈網站每秒會有多個頁面檢視，則應該考慮對其網站啟用輸出快取。

重要

內容搜尋網頁組件有項設定會使自己以非同步模式執行 (如果啟用的話)。輸出快取並不適用於來自非同步內容搜尋網頁組件的負載。

搜尋索引較大

根據部署SharePoint Server 2013企業的大小、 SharePoint Server 2013的內部網路部署通常會索引更大的數字的文件。這表示這些文件編製索引所需的搜尋拓撲也不同相較於前一節所述的拓撲。請參閱在 SharePoint Server 規劃搜尋來適當地調整您的 SharePoint 部署的大小。

就地編寫型發佈

本節提供指引和使用SharePoint Server 2013、 的結果，但它不會不將詳細說明會影響容量規劃的不同功能。如需在此區域的詳細資訊，請參閱在 SharePoint Server 中規劃 Web 內容管理。

有匿名使用者時的就地編寫型發佈

在測試中，我們使用具有下列特性的網站：

  • 網站，有最多 20,000 個文章頁面分成 20 個資料夾 (每個資料各 1,000 個頁面)，散布在單一網站集合中的 50 個網站。

  • 網站使用結構化導覽。

  • 網站一般每秒至少會接收 50 到 100 個網頁檢視。

  • 流量模式符合下列頁面組合：

    • 20 個頁面，包含單一內容查詢網頁組件，會發出不同範圍的內容資料庫查詢 (20% 的流量)

    • 30 個頁面，包括多個內容查詢網頁組件，會發出不同範圍的內容資料庫查詢 (30% 的流量)

    • 1,600 篇文章，含有 40k 的文字和兩個影像 (接收 50% 的流量)

下圖是建議的伺服器拓撲：

圖 8：就地編寫型發佈測試拓撲

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

  • 1 部電腦裝載 SQL Server

  • 1 部電腦裝載 SharePoint 服務應用程式，以作為前端網頁伺服器

測試實驗室結果

我們運用上圖所示的拓撲，在測試實驗室中使用實體電腦與一項 Visual Studio Team System 負載測試。

下表顯示我們在測試的電腦中使用的技術規格：

伺服器元件 SharePoint Server

處理器

Intel Xeon CPU @2.33GHz (2 個處理器、 8 個核心總計、 8 的執行緒總數)

RAM

24 GB

作業系統

Windows Server 2008 R2 Enterprise 64 位元

網路介面卡的數量

2

網路介面卡速度

1 Gbps

驗證

無 - 匿名

負載平衡器類型

Windows 軟體負載平衡器

軟體版本

SharePoint Server 2013
伺服器元件 資料庫伺服器

處理器

Intel Xeon CPU MP7130M @2.79GHz (2 個處理器，共 8 個核心與 16 個執行緒)

RAM

16 GB

作業系統

Windows Server 2008 R2 Enterprise 64 位元

磁碟陣列

2 x Dell PERC 5/E

網路介面卡的數量

1

網路介面卡速度

1 GB 或 Gbps

驗證

NTLM

軟體版本

Microsoft SQL Server 2008 R2 SP1

下表顯示執行 10 分鐘的結果：

測試功能 綠色區域 紅色區域

VSTS 使用者數目：

5

15

伺服器回應時間第 50 個百分位數：

69 毫秒

112 毫秒

伺服器回應時間第 95 個百分位數：

92 毫秒

221 毫秒

每秒網頁檢視：

57

93

平均 CPU (應用程式伺服器和前端網頁伺服器)

55

97

平均 CPU (SQL Server)

7

9

尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器)

8.9 GB

8.9 GB

輸出快取所造成的影響

輸出快取是有效的方式來減少SharePoint Server 2013發佈案例中的負載。如需詳細資訊，請參閱在 SharePoint Server 中規劃快取及效能。

下表顯示在已啟用輸出快取且點擊比率達 90% 的情況下，執行 10 分鐘的結果：

測試功能 綠色區域 紅色區域

VSTS 使用者數目：

5

15

伺服器回應時間第 50 個百分位數：

2 毫秒

2 毫秒

伺服器回應時間第 95 個百分位數：

74 毫秒

88 毫秒

每秒網頁檢視：

190

418

平均 CPU (應用程式伺服器和前端網頁伺服器)

58

85

平均 CPU (SQL Server)

5

7

尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器)

9.2 GB

9.4 GB

測試結果顯示，使用輸出快取可以大幅增加 SharePoint 發佈網站的輸送量，並且減少伺服器回應時間。對於由輸出快取服務的要求，回應時間幾乎為馬上。

下圖顯示測試結果的摘要：

圖 9：在快取點擊比率達 90% 的情況下，輸出快取所造成的影響

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

受管理導覽所造成的影響

SharePoint Server 2013，在發佈網站也可以使用受管理的導覽。如需如何設定此的詳細資訊，請參閱SharePoint Server 中受管理導覽的概觀。

我們對使用受管理導覽的測試網站，進行了一組我們在結構化導覽測試中所進行的相同測試。測試結果顯示，網站不論使用受管理導覽還是結構化導覽，在效能上都沒有重大差異。

測試功能 綠色區域 紅色區域

VSTS 使用者數目：

5

15

伺服器回應時間第 50 個百分位數：

70 毫秒

111 毫秒

伺服器回應時間第 95 個百分位數：

95 毫秒

215 毫秒

每秒網頁檢視：

56

94

平均 CPU (應用程式伺服器和前端網頁伺服器)

54

97

平均 CPU (SQL Server)

7

9

尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器)

8 GB

8 GB

下圖顯示相同的網站使用不同類型之導覽時的結果：

圖 10：受管理導覽與結構化導覽的比較

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

新增電腦 (向外擴展) 所造成的影響

如果您找出您必須從 SharePoint 部署多個輸送量、 向外延展 （增加主控SharePoint Server 2013的電腦數目） 是要考慮的選項。下圖顯示當我們將更多電腦新增至伺服器陣列輸送量會增加的方式：

圖 11：新增前端網頁伺服器對輸送量造成的影響

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

在我們的測試我們會增加執行SharePoint Server 2013使伺服器回應時間已大約相同 （筆 11 毫秒的綠色區域的紅色區域的筆 250 毫秒） 已新增每部電腦的伺服器上的負載。

有經驗證使用者時的就地編寫型發佈網站

SharePoint 發佈功能通常用於內部網路，而在內部網路中，存取網站的使用者都經過驗證。本節說明我們使用經驗證使用者進行的測試，以及所造成的影響。

下表針對經驗證使用者透過搭配使用宣告式驗證與 NTLM 來存取的就地編寫型發佈網站，顯示測試結果。請注意，這些測試中所使用的硬體與上節中的測試完全相同。

測試功能 綠色區域 紅色區域

VSTS 使用者數目：

5

15

伺服器回應時間第 50 個百分位數：

76 毫秒

107 毫秒

伺服器回應時間第 95 個百分位數：

103 毫秒

194 毫秒

每秒網頁檢視：

54

100

平均 CPU (應用程式伺服器和前端網頁伺服器)

50

97

平均 CPU (SQL Server)

6

9

尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器)

9.5 GB

9.5 GB

這些數字顯示，無論是使用匿名要求還是經驗證要求，伺服器回應時間與輸送量並無太大不同。

下圖顯示相同網站使用不同類型之要求時的結果：

圖 12：匿名要求與經驗證要求的比較

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

輸出快取在經驗證案例中所造成的影響

向伺服器提出的經驗證要求，需要往返內容資料庫一趟，以確保存取內容的帳戶具有檢視內容的權限。這表示輸出快取的效能特性在經驗證網站上與在匿名網站上並不同。

下表顯示在已啟用輸出快取且快取點擊比率達 90% 的情況下，執行 10 分鐘所得到的結果：

測試功能 綠色區域 紅色區域

VSTS 使用者數目：

6

18

伺服器回應時間第 50 個百分位數：

17 毫秒

29 毫秒

伺服器回應時間第 95 個百分位數：

87 毫秒

118 毫秒

每秒網頁檢視：

114

236

平均 CPU (應用程式伺服器和前端網頁伺服器)

50

97

平均 CPU (SQL Server)

7

10

尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器)

9.9 GB

10 GB

下圖顯示這些結果的摘要：

圖 13：經驗證輸出快取所造成的影響

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

See also

在 SharePoint Server 中規劃 Web 內容管理
在 SharePoint Server 中設定 web 內容管理解決方案
管理 SharePoint Server 中的 web 內容管理
Configure cache settings for a web application in SharePoint Server
在 SharePoint Server 中規劃快取及效能