共用方式為


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

適用於:yes-img-13 2013no-img-16 2016no-img-19 2019no-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

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

SharePoint 發佈網站包含不同的網站,與適用於各個網站的相關聯方法。 SharePoint Server 2013 的發佈功能旨在協助建立品牌化網際網路、內部網路和外部網路網站。 如需 SharePoint Server 2013 發佈的詳細資訊,請參閱在 SharePoint Server 中發佈至網際網路、內部網路及外部網路網站的功能概觀

簡介

本文將討論下列案例:

  • 網際網路形象網站

    提供資訊給客戶、合作夥伴、投資人及潛在員工。 這種類型的網站可讓匿名網際網路使用者找到公司的相關資訊。 一般而言,這些網站是品牌化的,公司嚴格控制內容。

  • 網際網路商務網站

    促銷公司提供給客戶的產品和服務。 這些網站可以顯示公司供應項目的產品目錄。

  • 內部網路網站

    公司在組織內部發佈此網站。 這些網站分享經過驗證使用者的資訊,公司嚴格管理網站,限制存取權或者開放給所有內部使用者。

  • 外部網路網站

    讓遠端員工、合作夥伴及客戶得以存取目標內容。 這些網站可以提供知識庫的存取權,知識庫使用以中繼資料標記的撰寫內容,對文章加以分類。 使用者可以搜尋或瀏覽特定資訊,例如疑難排解和支援文章。

跨網站集合發佈和內容搜尋網頁組件可讓內容在網站集合的這些案例中重複使用。 這些特色與功能會影響您規劃容量的方式。 如需詳細資訊,請參閱 SharePoint Server 的跨網站發佈概觀

注意事項

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

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

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

注意事項

本文中所述的案例,可以由跨網站發佈與就地撰寫網站兩者來達成。 跨網站發佈和受管理導覽功能彼此不互相依賴,可以單獨使用。

本文中使用的模型提及下列兩個主要計量:

  • 輸送量

    網站可承受的每秒頁面檢視數目

  • 伺服器回應時間

    伺服器處理要求所需的時間,會影響使用者檢視頁面所耗費的時間。 我們在本文件中提供的伺服器回應時間是第 95 和第 50 個百分位數值。 這些值表示分別有 95% 和 50% 的要求比提供的值還要快。 我們是用 SharePoint 使用量資料庫針對指定要求記錄的「期間」來測量這些值。

  • 內容有效期限

    更新項目反映在搜尋結果的所需時間,是您在使用跨網站發佈案例時可以考量的一個良好計量。

本文中所述的案例使用下列兩個狀態:

  • 綠色區域

    伺服器使用率在 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 的實體電腦。 如何如何使用虛擬機器和 Windows Server 2012 的建議,請參閱搜尋容量規劃和 SharePoint Server 2013 的容量規劃

重要事項

我們的測試實驗室拓撲設定已針對搜尋導向發佈案例進行最佳化。 這項設定不同於 SharePoint 部署的共同作業類型。 例如,我們的設定使用前端網頁伺服器作為搜尋索引伺服器,以取得最佳效能。 > 在測試實驗室拓撲中,我們已了解裝載應用程式伺服器的計算機使用量過低。 因此,我們會將「分散式快取服務」放到此應用程式伺服器上,而不是專用伺服器上。 您可能會決定要將「分散式快取服務」裝載在環境中的專用伺服器上。 為了獲得最佳效能,我們不建議您將「分散式快取服務」裝載在具有搜尋索引伺服器角色的前端網頁伺服器上。

測試實驗室報告

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

注意事項

我們在 VSTS 測試中,未使用瀏覽器快取或相依要求,例如映像或 JavaScript 檔案。 根據您自訂發佈網站的方式,所發生的相依要求數量會有顯著的差異。 > 我們在測試中使用的頁面, (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 x Dell PERC H700 SCSI)
網路介面卡的數量 2
網路介面卡速度 1 GB
驗證 無 - 匿名
軟體版本 SharePoint Server 2013
伺服器元件 資料庫伺服器
處理器 Intel Xeon CPUs L5520 @2.27GHz (2 個處理器,總計 8 核心,總計 16 個執行緒)
RAM 24 GB
作業系統 Windows Server 2008 R2 Enterprise SP1,64 位元
磁碟陣列 2 x Dell H700 SCSI
網路介面卡的數量 2
網路介面卡速度 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 10GB
尖峰記憶體使用量 (搜尋 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 會平行處理最多五個查詢,並傳回結果。 如果頁面上超過五個查詢,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()

如果您想要讓搜尋結果比預設值還要新,請降低值。 請注意,這樣會增加 Search 服務需要提供服務的查詢數量。

我們建議您一律在接收大量流量的發佈頁面上使用快取。 這些類型頁面的一些範例是使用搜尋網頁組件的網站首頁和類別頁面。 我們不建議針對目錄項目頁面進行快取。 因為個別目錄項目頁面相較於首頁,被存取的頻率低許多,而且在快取中儲存項目可能不值得。

當我們在具有相同負載模式的測試環境中關閉「匿名搜尋結果快取」時,伺服器回應時間顯著增加,且每秒頁面檢視數量中的輸送量降低。 以下是顯示這個關聯的圖表:

圖 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 處理網站中大量頁面點選事件所耗費的時間。 雖然這些結果是來自跨網站發佈網站,但是也適用於使用就地撰寫發佈方法的網站。

根據我們有關使用量分析處理的測試,我們產生了下列模擬事件,在一週的每天執行:

  • 兩千七百五十萬次點選事件分佈於 3 百萬個清單項目和 400,000 個使用者。

    我們使用 Zipf 分佈,因此某些項目和使用者具有許多事件,而其他項目和使用者則具有較少事件。

這會產生總計每天七百五十萬次事件,模擬不同使用者對網站產生不同流量模式。

我們會觸發分析執行七次,以模擬一週的流量。 我們針對累積超過六天的資料,每天執行「使用量分析」作業。 然後我們測量第七天所耗用的時間。 第七天是處理耗用最久時間的一天,因為要處理完整一週的項目,且關聯圖表要更新。 第 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 個文章頁面,分成單一集合中跨 50 個網站 20 個資料夾,各包含 1,000 個頁面。

  • 網站會使用結構化瀏覽。

  • 網站通常會接收每秒最少 50 到 100 個頁面檢視。

  • 流量模式會點擊下列頁面混合:

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

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

    • 1,600 份文章,包含 4 萬字和兩個影像 (接收 50% 的流量)

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

圖 8:就地撰寫發佈測試拓撲

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

  • 1 部裝載 SQL Server 的電腦

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

測試實驗室結果

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

下表顯示測試所使用電腦的技術資訊:

伺服器元件 SharePoint 伺服器
處理器 Intel Xeon CPUs @2.33GHz (2 個處理器,總計 8 核心,總計 8 個執行緒)
RAM 24 GB
作業系統 Windows Server 2008 R2 Enterprise,64 位元
網路介面卡的數量 2
網路介面卡速度 1 Gbps
驗證 無 - 匿名
負載平衡器類型 Windows 軟體負載平衡器
軟體版本 SharePoint Server 2013
伺服器元件 資料庫伺服器
處理器 Intel Xeon CPUs 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 中規劃快取及效能

下表顯示執行 10 分鐘的結果,已啟用輸出快取且有 90% 點擊率:

測試功能 綠色區域 紅色區域
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 圖表顯示在綠色與紅色區域中使用匿名要求與通過驗證之要求的等比例效能。

已驗證案例中輸出快取的效果

對伺服器的已驗證要求需要到內容資料庫的來回行程,以確定存取內容的帳戶具有檢視內容的權限。 這表示已驗證網站的輸出快取效能特性,相較之下,與匿名網站不同。

下表顯示我們所收到執行 10 分鐘的結果,已啟用輸出快取且有 90% 快取點擊率:

測試功能 綠色區域 紅色區域
VSTS 使用者數目: 6 18
伺服器回應時間第 50 個百分位數: 17 毫秒 29 毫秒
伺服器回應時間第 95 個百分位數: 87 毫秒 118 毫秒
每秒檢視頁面: 114 236
平均 CPU (應用程式伺服器和前端網頁伺服器) 50 97
平均 CPU (SQL Server) 7 10
尖峰記憶體使用量 (應用程式伺服器和前端網頁伺服器) 9.9 GB 10GB

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

圖 13:已驗證輸出快取的效果

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

另請參閱

概念

SharePoint Server 中的 Web 內容管理

在 SharePoint Server 中設定 Web 內容管理解決方案

在 SharePoint Server 中設定 Web 應用程式的快取設定

在 SharePoint Server 中規劃快取及效能