預估 SharePoint Server 2013 (社交環境的效能和容量需求)
適用於：
Subscription Edition SharePoint in Microsoft 365
若要為企業內部網路我的網站和社交運算入口網站解決方案建立效能和容量計劃，本文包含下列領域的相關信息：
實驗室環境規格，例如硬體、伺服器數位拓撲和伺服器數位設定
測試伺服器陣列工作負載和資料集，其用於產生測試負載
測試結果和分析 ，示範並說明特定縮放點負載下的輸送量、延遲和硬體需求趨勢。
使用本文中的資訊來瞭解下列概念：
一般和尖峰負載下的案例特性
當伺服器數位伺服器相應放大時，效能趨勢的變更方式
如何為規劃的架構預估適當的起點
當您規劃伺服器陣列需要在尖峰負載下維持可接受的效能層級時，需要考慮的重要因素
此環境簡介
企業通常會使用 SharePoint Server 2013 來發布我的網站和社交運算入口網站，以驗證使用者在內部網路網站上的存取權。 本文包含容量和效能數據，可協助規劃要使用的計算機數目，以及在 SharePoint Server 2013 中發布我的網站和社交運算入口網站所需的電腦類型。
其他指引說明如何在 SharePoint Server 2013 企業版我的網站和社交運算入口網站解決方案中相應放大伺服器。 容量規劃會告知所要購買的硬體以及可讓您的解決方案最佳化的系統組態相關決策。
由於個別的 SharePoint Server 2013 伺服器數位是唯一的，因此每個伺服器陣列都有不同的需求，取決於硬體、用戶行為、已安裝功能的設定，以及許多其他因素。 因此，如果本指南未提到您的情況，請另行以自家的硬體在自己的環境中進行測試。 如果您規劃的設計和工作負載跟本文所述的環境很像，可以直接使用本文來得出如何擴充環境的結論。
本文中的測試結果是在測試實驗室中產生，使用工作負載、數據集和架構，在高度控制的條件下模擬生產環境。 雖然在設計這些測試時非常謹慎，但在測試實驗室中得到的效能特性永遠不會與實際執行環境中的行為相同。 這些測試結果並不代表實際執行伺服器陣列的效能和容量特性。 不過，這些測試結果可顯示出在輸送量、延遲與硬體需求方面觀察到的趨勢。 運用這些對於所觀察到資料的分析，您將更能規劃容量並管理伺服器陣列。
本文包含下列內容：
規格，包括硬體、拓撲及設定
工作負載，包括對伺服器陣列需求、使用者數目及使用狀況特性的分析
資料集，例如資料庫大小和內容類型
將網頁伺服器向外延展的測試結果與分析
在閱讀本文前，請閱讀下列文章，確保您已了解 SharePoint Server 2013 中容量管理的主要概念。
這些文章會提供下列資訊：
容量管理的建議方法
善加利用本文資訊的方式
詞彙
下列清單包含本文中主要詞彙的定義：
RPS： 每秒要求數。 RPS 是伺服器陣列或伺服器在一秒內收到的要求數目。 這是常見的伺服器陣列負載度量方式。
重要事項
請注意，要求與頁面負載不同。 每個頁面都包含數個元件，每個元件都會在瀏覽器載入頁面時建立一或多個要求。 因此，一個頁面負載可建立數個要求。 使用不重要資源的驗證檢查和事件通常不會計入 RPS 度量。
綠色區域： 綠色區域代表一組在正常作業條件下定義的負載特性，最多為預期的每日尖峰負載。 在此範圍中運作的伺服器陣列無論是回應時間或延遲，皆會在可接受的程度之內。
在此狀態下，伺服器可維持在下列標準︰
至少 75% 要求的伺服器端延遲小於 0.5 秒。
所有伺服器都維持低於 50% 的平均 CPU 使用率。
失敗率小於 0.1%。
紅色區域 (最大值)︰紅色區域代表在尖峰運作條件下定義的一組負載特性。 在紅色區域，伺服器陣列經歷非常高的暫時性資源需求，而只能撐住有限的時間，而後就會發生失敗與其他效能和可靠性的問題。
在此狀態下，伺服器可在有限的時間撐著維持在下列標準︰
至少 75% 要求的伺服器端延遲小於 1 秒。
平均資料庫伺服器 CPU 使用率小於 80%。
失敗率小於 0.1%。
概觀
本節摘要說明我們的調整方法、此實驗室環境與類似案例研究環境之間的關聯性，以及我們的測試方法。
延展方法
建議您依照調整測試實驗室環境的特定順序，調整環境中的計算機。 這種方法可讓您找到工作負載的最佳設定。
我們將效能測試週期分成三個工作負載類別。 判斷類別界限的主要參數是使用者配置檔的數目，設定為 10K、100K 和 500K 使用者設定檔測試。 另一個參數是作用中用戶的數目，這些使用者正在執行與社交功能集相關的動作。 我們使用配置檔的用戶數目和作用中用戶的數目，執行測試來模擬應用程式的使用方式，類似於實際部署。 下表描述初始數據集和作用中用戶的數目。
初始數據集
| 實體 | 具有這項功能的使用者百分比 | 小型 (10000 名使用者) | 中型 (10 萬名使用者) | 大型 (50 萬使用者) |
|---|---|---|---|---|
| 用戶的使用者配置檔數目 |
100% |
10K |
100K |
500K |
| 布建的我的網站數目 |
100% |
10K |
100K |
500K |
| 具有使用者相片的使用者配置檔數目 |
50% |
5K |
50K |
250K |
| 具有文章的使用者配置檔數目 |
10% |
1K |
10K |
50K |
| 小組數目 |
1,860 |
18,600 |
93K |
|
| 每天的作用中用戶數目 |
10% |
1K |
10K |
50K |
| 每小時作用中的用戶數目 |
5% |
500 |
5K |
25K |
測試著重於下列主要案例：
新聞摘要頁面存取和其他動作
[設定檔] 頁面
網站摘要頁面存取和其他動作
Outlook 社交連接器活動摘要同步
OneDrive 頁面存取
OneDrive 用戶端使用量
為了模擬實際的部署案例，所有測試都是在已經有數據的資料庫上執行。 數據集是樹狀結構組織的模型，每個小組平均有 4-6 位使用者，且深度為 3-4 層。 為了產生這些數字，我們已分析來自內部社交網站的流量。 下表描述我們用來建置初始數據集的一組參數。
初始資料庫的數據模型
| 數據實體描述 | 數字 |
|---|---|
| 小組中的平均用戶數目 |
5 |
| 每個組織的平均層級數目 |
4 |
| 每 1,000 位使用者的小組數目 |
186 |
| 使用者所遵循的同事平均數目 |
50 |
| 使用者配置檔屬性的數目 |
93 |
下表描述會導致數據母體擴展的動作參數集：
使用方式特性
| 參數 | 數位或百分比 |
|---|---|
| 具有 1-3 篇文章的使用者百分比 |
10% |
| 每位使用者的平均貼文數目 |
2 |
| 每篇文章的平均回復數目 |
2 |
| 喜歡的文章百分比 |
15% 的成本 |
| 具有連結的文章百分比 |
5% |
| 具有標籤的文章百分比 |
12% |
| 具有使用者提及的文章百分比 |
8% |
| 已附加影像的文章百分比 |
5% |
為了建立每個規模測試，我們已將下列動作混合套用至上述數據集和作用中用戶的數目：
用戶讀取動作
| 使用者動作 | 採取此動作的使用者百分比 | 案例 | 功能或 URL |
|---|---|---|---|
| 流覽至 [我的網站] 首頁 |
12% |
新聞摘要 |
新聞摘要頁面 (http://my/default.aspx) |
| 流覽至使用者的公用配置檔頁面 |
8% |
設定檔 |
配置文件頁面 (http://my/person.aspx?accountname=<別> 名) |
| 瀏覽至使用者的私人配置檔頁面 |
4% |
設定檔 |
配置文件頁面 (http://my/person.aspx) |
| 自動同步處理活動摘要 |
32% |
Outlook Social Connector |
無 |
| 流覽至 [ 我正在追蹤的人] 頁面 |
3% |
追蹤人員清單 |
http://my/MyPeople.aspx |
| 瀏覽至預設文件庫 |
6% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Documents |
| 瀏覽至追蹤的文件頁面 |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| 瀏覽至追蹤的文件頁面 |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| 流覽至網站摘要頁面 |
8% |
網站摘要 |
網站摘要頁面 (https://< domain>/teams/<site>/newsfeed.aspx_ |
| 檢視線程上的所有回復 |
1% |
新聞摘要 |
新聞摘要頁面 (http://my/default.aspx) |
| 檢視 所有人 摘要 |
3% |
新聞摘要 |
新聞摘要頁面 (http://my/default.aspx) |
| 檢視新聞摘要的更多文章 |
2% |
新聞摘要 |
新聞摘要頁面 (http://my/default.aspx) |
|
@mentions檢視頁面 |
1% |
新聞摘要 |
新聞摘要頁面 (http://my/default.aspx) |
| 檢視新聞摘要 (行動裝置) |
1% |
行動裝置 |
REST) 呼叫 (行動表示狀態傳輸 |
| 檢視分類的新聞摘要 |
3% |
行動裝置 |
行動裝置 REST 通話 |
使用者寫入動作
| 使用者動作 | Percentage | 案例 | 功能或 URL |
|---|---|---|---|
| 在摘要中建立根文章 |
0.5% |
新聞摘要 |
新聞摘要頁面 (http://my/default.aspx) |
| 就像摘要中的貼文 |
0.3% |
新聞摘要 |
新聞摘要頁面 (http://my/default.aspx) |
| 回復摘要中的貼文 |
0.7% |
新聞摘要 |
新聞摘要頁面 (http://my/default.aspx) |
| 使用 在摘要中建立文章 @mention |
0.1% |
新聞摘要 |
新聞摘要頁面 (http://my/default.aspx) |
| 在網站摘要中建立根文章 |
0.5% |
網站摘要 |
網站摘要頁面 (https://< domain>/teams/<site>/newsfeed.aspx) |
| 使用 在網站摘要中建立文章 @mention |
0.5% |
網站摘要 |
網站摘要頁面 (https://< domain>/teams/<site>/newsfeed.aspx) |
| 回復網站摘要中的貼文 |
0.15% |
網站摘要 |
網站摘要頁面 (https://< domain>/teams/<site>/newsfeed.aspx) |
| 使用標籤在網站摘要中建立文章 |
0.05% |
網站摘要 |
網站摘要頁面 (https://< domain>/teams/<site>/newsfeed.aspx) |
OneDrive 用戶端動作
| 使用者動作** | Percentage | 案例 | 功能或 URL |
|---|---|---|---|
| OneDrive 初始同步處理 |
0.2% |
OneDrive |
初始同步 |
| OneDrive 累加同步 - 下載檔案 |
0.88% |
OneDrive |
累加同步 |
| OneDrive 累加同步處理 - 沒有變更 |
8.1% |
OneDrive |
累加同步 |
測試方法
我們從社交功能的最低 SharePoint Server 2013 伺服器陣列設定開始。 我們已將特性社交負載套用至測試伺服器陣列，並增加負載，直到觀察到正常和最大伺服器容量的層級為止。 我們已分析每個負載層級的瓶頸，並新增多載角色的機器來相應放大伺服器陣列組態。 這項新增功能可減輕每個案例中的瓶頸，併為特定數據集提供伺服器延展性特性的檢視。 我們針對三個部署大小重複此向外延展程式，以提供SharePoint Server 2013 伺服器陣列延展性特性和容量規劃指導方針的代表性摘要。
規格
本節提供有關實驗室環境硬體、軟體、拓撲和設定的詳細資訊。
重要事項
測試實驗室中的 Al Web 伺服器和應用程式伺服器已使用 Hyper-V 主機進行虛擬化。 資料庫伺服器未經虛擬化。 下列各節會個別詳細說明實體主機硬體和虛擬機虛擬硬體。
硬體
下表列出此測試中所使用計算機的硬體規格。 在測試多次反覆運算期間新增至伺服器數位的前端網頁伺服器也符合這些規格。
Hyper-V 主機
伺服器數位總共包含三部設定完全相同的 Hyper-V 主機，而每部主機都會執行一到四部虛擬機。
| 主機硬體 | 值 |
|---|---|
|
處理器 |
2 四核心 2.27 GHz 處理器 |
|
RAM |
64 GB |
|
作業系統 |
Windows Server 2008 R2 SP1 |
|
網路介面卡的數量 |
2 |
|
網路介面卡速度 |
1 Gigabit |
虛擬網頁伺服器與應用程式伺服器
伺服器陣列具有一到八部虛擬網頁伺服器。 額外一部執行分散式快取服務的專用伺服器。
注意事項
在生產環境中，執行分散式快取服務的專用伺服器通常會部署在高可用性組態中。 為了進行測試，我們將一部專用伺服器用於分散式快取，因為高可用性不是重要因素。
| VM 硬體 | 網頁伺服器 |
|---|---|
|
處理器 |
4 個虛擬處理器 |
|
RAM |
12 GB |
|
作業系統 |
Windows Server 2008 R2 SP1 |
|
SharePoint 磁碟機的大小 |
100 GB |
|
網路介面卡的數量 |
2 |
|
網路介面卡速度 |
1 Gigabit |
|
驗證 |
Windows NTLM |
|
負載平衡器類型 |
F5 Big IP |
|
本機執行服務 |
Microsoft SharePoint Foundation Web 應用程式、Microsoft SharePoint Foundation 內送電子郵件、Microsoft SharePoint Foundation 工作流程定時器服務、受控元數據 Web 服務、使用者配置檔服務 |
| VM 硬體 | 快取 |
|---|---|
|
處理器 |
4 個虛擬處理器 |
|
RAM |
12 GB |
|
作業系統 |
Windows Server 2008 R2 SP1 |
|
SharePoint 磁碟機的大小 |
100 GB |
|
網路介面卡的數量 |
2 |
|
網路介面卡速度 |
1 Gigabit |
|
驗證 |
Windows NTLM |
|
本機執行服務 |
分散式快取，Microsoft SharePoint Foundation 工作流程定時器服務 |
| VM 硬體 | 搜尋查詢元件 |
|---|---|
|
處理器 |
4 個虛擬處理器 |
|
RAM |
12 GB |
|
作業系統 |
Windows Server 2008 R2 SP1 |
|
網路介面卡的數量 |
2 |
|
網路介面卡速度 |
1 Gigabit |
|
驗證 |
Windows NTLM |
|
本機執行服務 |
Microsoft SharePoint Foundation Web 應用程式、Microsoft SharePoint Foundation 內送電子郵件、Microsoft SharePoint Foundation 工作流程定時器服務、搜尋查詢和網站設定服務、SharePoint Server 搜尋 |
| VM 硬體 | 搜尋索引元件 |
|---|---|
|
處理器 |
4 個虛擬處理器 |
|
RAM |
12 GB |
|
作業系統 |
Windows Server 2008 R2 SP1 |
|
網路介面卡的數量 |
2 |
|
網路介面卡速度 |
1 Gigabit |
|
驗證 |
Windows NTLM |
|
本機執行服務 |
Microsoft SharePoint Foundation Web 應用程式、Microsoft SharePoint Foundation 內送電子郵件、Microsoft SharePoint Foundation 工作流程定時器服務、SharePoint Server 搜尋 |
資料庫伺服器
一個實體資料庫伺服器執行具有 SharePoint 資料庫的預設 SQL Server 執行個體。 本文不會追蹤記錄資料庫。
注意事項
如果您啟用使用報表，建議您將記錄資料庫儲存於不同的邏輯單元編號 (LUN)。 大型部署及部分中型部署可能需要專用的記錄資料庫伺服器，以因應大量記錄事件產生的處理器需求。 > 在此實驗室環境中，記錄受到限制，而且記錄資料庫會儲存在 SQL Server 的個別實例中。
資料庫伺服器 – 預設執行個體
|
處理器 |
2 個四核心 3.3 GHz 處理器 |
|
RAM |
32 GB |
|
作業系統 |
Windows Server 2008 R2 SP1 |
|
儲存體與幾何 |
直接連接儲存裝置 (DAS) 具有 6 x 300 GB 15krpm 磁碟的內部陣列 具有 15 x 450 GB 15krpm 磁碟的外部陣列 外部RAID 10 (50 x 內容數據，每個) 2x3 個主軸 300 GB 50 x 個內容記錄 (內部 RAID10，每個) 2x2 個主軸 300 GB 1 x 暫存數據 (內部 RAID10，每個) 2x2 個主軸 300 GB 1 x 暫存記錄 (內部 RAID10,2x2 主軸 300 GB 每個) |
|
網路介面卡的數量 |
1 |
|
網路介面卡速度 |
1 Gigabit |
|
驗證 |
Windows NTLM |
|
軟體版本 |
SQL Server 2008 R2 |
拓撲
下表顯示此實驗室環境的拓撲：
實驗室環境拓撲
| 角色 | 小型部署 (10000 名使用者) | 中型部署 (10 萬名使用者) | 大型部署 (50 萬名使用者) |
|---|---|---|---|
| 網頁伺服器 |
2-4 |
4-8 |
8 |
| 快取 |
1 |
1-2 |
3 |
| SQL Server |
1 |
1-2 |
2 |
測試程式
重要事項
測試只會在一般社交運算入口網站上模型化一般工作時間使用量。 我們並未考慮用戶產生的流量在日/夜循環產生的週期性變更。 我們已使用相同的測試工作負載獨立測試定時器工作，例如需要大量資源的配置檔同步處理和人員搜尋編目等定時器工作，以判斷其效果。 > 這些測試著重於社交作業，例如新聞摘要、社交標記和讀取人員配置檔。 測試混合包含少量的一般共同作業流量，以更有效地模擬生產環境。 我們預期這些結果將有助於設計專屬於「我的網站」和社交功能的個別入口網站。 > 測試混合不包含來自搜尋內容搜尋。 >
我們針對社交功能的小型、中型和大型部署進行了測試。 為了設定伺服器硬體，我們至少開始設定最小大小的設定，並使用數據集填入測試資料庫，如 調整方法 一節中所述。
我們使用 Visual Studio Team System (VSTS) 來模擬工作負載並套用特性社交負載，一開始會對伺服器產生少量負載。 我們一致地將此負載緩慢增加，並在所有伺服器角色上記錄效能計量，直到觀察到 RPS 上限為止。 這可辨識為伺服器數位上套用的負載增加，因伺服器瓶頸條件約束而導致傳遞的 RPS 輸出不會增加的狀態。
從這些記錄的計量中，我們定義了綠色區域和紅色區域狀態，這代表 VM 伺服器在指定電腦設定中的正常和完全載入狀態。 然後，我們在綠色區域和紅色區域層級套用穩定負載，以分析這些負載上的穩定狀態效能計量。 這會在每個拓撲組態的這些主要載入條件下，提供 VM 伺服器的伺服器健康情況和效能表示法。
在瞭解每個拓撲的綠色和紅色負載特性和縮放曲線之後，我們識別出限制 RPS 的縮放瓶頸。 在社交工作負載的案例中，這通常是小型數據集的 Web 伺服器 CPU。 對於較大的數據集，我們也觀察到分散式快取節點上的記憶體壓力。 我們已將多載角色的虛擬伺服器新增至組態，以移除每個案例中的瓶頸，並繼續向外延展程式。 接著，我們會在每個設定大小重複分析效能趨勢及其與綠色和紅色區域定義的一致性，直到達到特定部署大小的需求為止。
在瞭解每個部署大小之後，我們會將測試伺服器陣列重新設定為下一個較大大小的最小組態、依照 調整方法 一節中所述填入數據集，並重複分析/向外延展程序週期，並測量每個數據集大小的相應放大特性。
結果與分析
本節顯示三個部署大小的測量結果。 具體來說，它會顯示藉由新增網頁伺服器相應放大伺服器陣列，會如何影響綠色和紅色區域 RPS、延遲和平均 CPU 使用量。
下列趨勢在所有三個部署大小之間是一致的：
紅色和綠色區域 RPS 會隨著虛擬網頁伺服器數目以線性方式增加。
所有已測試組態的主要瓶頸是 Web 伺服器 CPU。
在紅色區域，延遲會隨著我們新增網頁伺服器並增加負載而稍微增加。 這是由於 SQL Server 和分散式快取服務 (的額外壓力所造成，該服務會在測試伺服器陣列) 中的所有網頁伺服器上執行。
此外，SQL Server 和分散式快取電腦上的平均 CPU 使用量會隨著網頁伺服器數目增加而增加。 這是由 SQL Server 和分散式快取服務上的其他快取負載所造成。
綠色區域延遲會隨著網頁伺服器數目增加而維持相當一般。 這是因為網頁伺服器不會在綠色區域負載層級過度負荷。
小規模結果
下圖顯示增加網頁伺服器數目對綠色和紅色區域的 RPS 有何影響。
下圖顯示增加網頁伺服器數目如何影響綠色和紅色區域負載層級的延遲。
下圖顯示增加網頁伺服器數目如何影響綠色和紅色區域負載層級的平均CPU使用量。
中階結果
下圖顯示增加網頁伺服器數目對綠色和紅色區域的 RPS 有何影響。
下圖顯示增加網頁伺服器數目如何影響綠色和紅色區域負載層級的延遲。
下圖顯示增加網頁伺服器數目如何影響綠色和紅色區域負載層級的平均CPU使用量。
大規模結果
下圖顯示增加網頁伺服器數目對綠色和紅色區域的 RPS 有何影響。
下圖顯示增加網頁伺服器數目如何影響綠色和紅色區域負載層級的延遲。
下圖顯示增加網頁伺服器數目如何影響綠色和紅色區域負載層級的平均CPU使用量。
隨著網頁伺服器數目增加，會發生下列事件：
SQL Server 和分散式快取節點的平均 CPU 使用量會增加，因為這些共用資源會增加負擔。
紅色區域的平均 Web 伺服器 CPU 使用量會因瓶頸稍微轉移到 SQL Server 和分散式快取計算機而稍微減少。
綠色區域的平均 Web 伺服器 CPU 使用量會保持不變，因為伺服器會保留在建議的負載層級。
建議
以效能測量的成功 SharePoint Server 2013 社交部署取決於下列因素：
您想要支援的作用中用戶數目
讀取和寫入作業的預期交易混合
負載如何分散到伺服器數位伺服器
預期的作用中用戶數目是決定您應該在拓撲中擁有之伺服器數目的一個關鍵因素。 作用中用戶的數目也會決定裝載各種服務的啟用方式，這些服務必須針對整個伺服器的社交案例啟用。
雖然我們的測試使用一般數據集，並套用您在真實世界客戶部署中可能預期的負載複雜度，但每個部署都是唯一的。 您的容量規劃工作應該考慮預期的使用特性、功能設定和硬體資源可用性。 可能會大幅影響或變更容量數目的一些因素如下所示：
電子郵件使用量增加的模式可能會增加 Outlook Social Connector 產生的負載。
例如， (寫入動作的百分比大幅增加，標記或 @mention) 交易混合中的增加可能會增加資料庫伺服器上的負載。
您可以新增或移除網頁伺服器，以平衡網頁伺服器、SQL Server 和分散式快取節點之間的 CPU 負載。
請仔細遵循標準 SharePoint Server 2013 設定指引，以獲得最佳效能。 對社交交易特別重要的考慮如下：
配置檔 DB 的個別實體磁碟 - 由於社交交易在配置檔 DB 上的大量磁碟使用量，建議您在執行 SQL Server 的伺服器上，將 Profile DB 保留在自己的實體磁碟集上。
User Profile Service 應用程式的記憶體需求 - User Profile Service 應用程式位於前端網頁伺服器上，且高度依賴其記憶體內部快取。 請確定前端 Web 伺服器有足夠的 RAM 可快取許多數據要求。 每個前端 Web 伺服器的最低建議 RAM 為 12 GB。
分散式快取伺服器的記憶體需求- 社交功能，尤其是微記錄，高度依賴足夠且健全的分散式快取記憶體。 當重新填入此快取時，這些計算機上的記憶體不足情況可能會降低 SharePoint 伺服器數位的容量。 因此，建議您將裝載分散式快取的伺服器設定為使用至少 12 GB 的 RAM，並根據部署中的使用者總數視需要相應放大。
SharePoint Server 2013 社交部署會強制為每個想要使用社交功能的使用者布建個人網站。 規劃在內容資料庫 層級建立個人網站集合的成長。 如需如何調整個人網站集合的詳細資訊，請參閱 SharePoint 2013 的軟體界限和限制。