評估效能和容量需求的社交環境 (SharePoint Server 2013)

 

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

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

**摘要:**了解如何決定數目和類型所需的容量計劃的 「 我的網站和 SharePoint Server 2013 為基礎的社交運算入口網站的電腦。

若要建立效能和容量規劃 「 我的網站的企業內部網路與社交運算入口網站解決方案,本文會包含下列領域的相關資訊:

  • 實驗室環境規格,如硬體、 伺服器陣列拓撲及伺服器陣列設定

  • 用於產生測試負載的測試伺服器陣列工作負載與資料集

  • 測試結果與分析︰ 示範與說明在特定刻度點的負載下,輸送量、 延遲及硬體需求的趨勢。

使用本文中的資訊來瞭解下列概念:

  • 一般和尖峰負載下案例的特性

  • 效能趨勢如何變更時向外延展伺服器陣列的伺服器

  • 如何估算適當您計劃的架構起點

  • 考慮當您計劃的資源在伺服器陣列的重要因素必須維持可接受的層級的尖峰負載下的效能

本文內容:

  • 環境簡介

  • 詞彙

  • 概觀

  • 規格

  • 結果與分析

環境簡介

企業通常會使用SharePoint Server 2013發佈我的網站及經過驗證的使用者存取內部網路網站上的社交運算入口網站。本文包含可協助您規劃要使用的電腦數目和類型所需發佈SharePoint Server 2013中的 「 我的網站與社交運算入口網站的電腦的容量與效能資料。

其他指引說明如何向外延展SharePoint Server 2013企業 「 我的網站和社交運算入口網站解決方案中的伺服器。容量計劃會告知硬體,以最佳化您的解決方案的購買和系統設定的相關決策。

個別SharePoint Server 2013伺服器陣列是唯一的因為每個伺服器陣列會有不同的硬體、 使用者行為、 的已安裝的功能、 設定及許多其他因素而定的需求。因此,補充這份指導您自己環境中硬體上的其他測試。如果您計劃的設計和工作負載的格式類似於本文所述的環境,您可以使用本文來繪製結論有關如何擴充您的環境。

本文中的測試結果產生在測試實驗室中,來模擬高度控制的情況下為實際執行環境中使用工作負載、 資料集和架構。雖然小心已運用在設計這些測試,在測試實驗室的效能特性一些永遠不在實際執行環境的行為相同。這些測試結果不代表實際執行伺服器陣列的效能與容量特性。而是測試結果示範觀察到的輸送量、 延遲及硬體需求的趨勢。若要協助您規劃容量及管理自己的伺服器陣列使用觀察到的資料的分析。

本文包括下列資訊︰

  • 規格︰其中包括硬體、拓撲及設定

  • 工作負載︰其中包括對伺服器陣列需求、使用者數目及使用狀況特性的分析

  • 資料集,例如資料庫大小和內容類型

  • 將網頁伺服器向外延展的測試結果與分析

閱讀本文之前,請閱讀下列文章,以確認您了解SharePoint Server 2013中的容量管理的重要概念。

這些文章提供下列資訊︰

  • 容量管理的建議方法

  • 如何有效利用本文中的資訊

詞彙

下列清單包含之本文中找到的關鍵字詞的定義:

  • **RPS︰**每秒要求數。RPS 表示伺服器陣列或伺服器在一秒內所收到的要求數。常用於測量伺服器及伺服器陣列的負載。

    重要

    頁面載入跟該要求的附註。每個頁面包含數個元件,每一種會建立一或多個要求瀏覽器中載入頁面時。因此,一個載入頁面建立數個要求。不在 RPS 測量計算驗證檢查及事件通常用於微乎其微的資源。

  • **綠色區域︰**綠色區域代表在一般運作條件下定義的一組負載特性,包含預期的每日尖峰負載。在此範圍中運作的伺服器陣列無論是回應時間或延遲,皆在可接受的程度內。

    在此狀態下,伺服器可維持在下列標準︰

    • 至少 75%的要求之伺服器端延遲為小於 0.5 秒。

    • 所有伺服器都維持平均 CPU 使用率小於 50%。

    • 失敗率為小於 0.1%。

  • **紅色區域 (最大值)︰**紅色區域代表在尖峰運作條件下已定義的一組負載特性。在紅色區域中,伺服器陣列會經歷非常高的暫時性資源需求,而只能持續有限的時間,接著就會發生失敗與其他效能和可靠性的問題。

    在此狀態下,伺服器可在有限的持續時間內維持下列準則︰

    • 至少 75%的要求伺服器端的延遲是少於 1 秒。

    • 平均資料庫伺服器 CPU 使用率是小於 80%。

    • 失敗率為小於 0.1%。

概觀

本節摘要說明我們延展方法,此實驗室環境和類似的案例研究環境中,與我們測試方法之間的關係。

延展方法

我們建議您在特定順序我們後面的縮放比例我們的測試實驗室環境中對環境中向外的電腦。這個方法可讓您尋找您工作負載的最佳組態。

我們會將效能測試循環分成三種工作負載類別。決定類別界限的主要參數是數字的使用者設定檔,設為在 10k、 100 K 和 500 位使用者設定檔測試。另一個參數是作用中使用者所執行的社交功能集相關的動作數目。同時具有設定檔的使用者數目及作用中使用者數,我們已執行測試以模擬就是類似實際部署的應用程式的使用方式。下表說明初始的資料集和作用中使用者數。

初始資料集

Entity %的使用者具有此功能 小型 (10 位使用者) 中型 (100 位使用者) Large (500 位使用者)

使用者設定檔的使用者數目

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 Social Connector 活動摘要同步處理

  • 商務用 OneDrive ] 頁面上的存取

  • 商務用 OneDrive用戶端使用狀況

若要模擬真實感化的部署案例、 已經有資料的資料庫上執行所有測試。資料集是樹狀目錄組織的平均每小組、 4-6 使用者與 3-4 層級深入的模型。若要產生這些數字,我們分析來自內部的社交網站的流量。下表說明我們用來建立初始的資料集的參數組。

初始資料庫的資料模型

資料實體描述 數字

在小組中使用者的平均數目

5

組織各層級的平均數目

4

小組每 1000 位使用者的數目

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:// < 網域 > /teams/ < 網站 > /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

手機

行動裝置的其餘呼叫

使用者寫入的動作

使用者動作 百分比 案例 功能或 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:// < 網域 > /teams/ < 網站 > / newsfeed.aspx)

網站與 @mention 摘要中建立貼文

0.5%

網站摘要

網站摘要] 頁面 (https:// < 網域 > /teams/ < 網站 > / newsfeed.aspx)

在 [網站摘要發文回覆

0.15%

網站摘要

網站摘要] 頁面 (https:// < 網域 > /teams/ < 網站 > / newsfeed.aspx)

在網站具有標記摘要中建立貼文

0.05%

網站摘要

網站摘要] 頁面 (https:// < 網域 > /teams/ < 網站 > / newsfeed.aspx)

商務用戶端動作 OneDrive

使用者動作 百分比 案例 功能或 URL

商務用 OneDrive初始同步處理

0.2%

商務用 OneDrive

初始同步處理

商務用 OneDrive累加同步處理-下載 (英文) 檔案

0.88%

商務用 OneDrive

累加同步處理

商務用 OneDrive累加同步處理-沒有變更

8.1%

商務用 OneDrive

累加同步處理

測試方法

我們開始使用社交功能的基本SharePoint Server 2013伺服器陣列設定。我們套用至測試伺服器陣列的特性的社交負載,並增加負載直到我們觀察到層級的一般和最大伺服器容量。我們分析在每個這些的載入層級和向外延展伺服器陣列設定的多載角色新增的機器瓶頸。此除了減輕每個瓶頸並針對特定資料集所提供的伺服器延展性特性的檢視。我們的容量規劃重複此向外延展的程序提供代表性摘要SharePoint Server 2013伺服器陣列的延展性特性的三種部署大小和指導方針。

規格

本節提供硬體、 軟體、 拓撲及設定的實驗室環境的詳細的資訊。

重要

Al 網頁伺服器和應用程式伺服器測試實驗室中的已套用到虛擬化使用 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 磁碟陣列

50 x 內容資料 (外部 RAID10,2 x 3 磁針每個 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

拓撲

下表說明此實驗室環境的拓撲:

實驗室環境的拓撲

角色 小型部署 (10 位使用者) 中型部署 (100 位使用者) 大型部署 (500 位使用者)

網頁伺服器

2-4

4-8

8

快取

1

1-2

3

SQL Server

1

1-2

2

測試程序

重要

  • 測試僅模型一般營業時間使用一般的社交運算入口網站。我們並未在一天/晚上循環產生使用者產生流量考量循環的變更。我們測試過等設定檔同步處理和人員搜尋編目需要單獨具有相同的測試工作負載來判斷其效果的大幅資源的計時器工作。

  • 測試聚焦社交作業,例如新聞、 社交標記及讀取人員設定檔。測試混合包含少量的一般共同作業流量更妥善地模擬在實際執行環境。我們預期這些結果有助於設計專用於 「 我的網站及社交功能的個別入口網站。

  • 測試混合不包含來自搜尋內容編目的流量。

我們執行測試針對小型、 中型及大型部署的社交功能。若要設定伺服器硬體,我們在最小大小的最小設定啟動並填入資料集的縮放比例方法] 區段中所述的測試資料庫。

我們使用 Visual Studio Team System (VSTS) 來模擬的工作量及套用特性社交負載主導對伺服器的小型負載第一次。我們統一緩慢增加此負載和直到我們觀察到最大 RPS 記錄在所有伺服器角色上的效能評量。這 was 辨識伺服器陣列上的套用負載增加其中因為沒有增加所造成的狀態傳遞 RPS 輸出伺服器瓶頸條件約束。

從這些記錄的評量,我們會定義綠色區域與紅色區域的狀態,它表示在特定的電腦設定的虛擬機器伺服器一般和滿載狀態。我們再套用在綠色區域與紅色區域層級來分析穩定狀態效能評量在這些載入穩定負載。提供此伺服器每種拓撲設定這些主要負載的情況下的虛擬機器伺服器健康狀況與效能的表示法。

我們瞭解綠色和紅色負載特性和每種拓撲的縮放比例的曲線上之後,我們會識別限制 RPS 的縮放比例瓶頸。但如果是社交工作量,這通常是小型資料集的網頁伺服器 CPU。大型資料集,我們也會觀察分散式快取節點上的記憶體壓力。我們要在每個案例中移除瓶頸,並繼續向外延展的程序設定新增虛擬伺服器的多載角色。我們再重複效能趨勢和綠色和紅色區域定義在每個設定的大小以其符合性的分析直到我們達到特定部署大小的需求。

我們瞭解每個部署大小之後,我們重新設定最小的下一個較大的間距設定測試伺服器陣列、 填入 [縮放比例方法] 區段中所述的資料集和重複分析/向外延展程序循環及單位的每一個資料集大小的向外延展特性。

結果與分析

本節說明這三種部署大小的測量的結果。尤其是它會顯示向外延展伺服器陣列新增網頁伺服器的影響綠色和紅色區域的 RPS、 延遲及平均 CPU 使用率。

下列趨勢跨所有三個部署大小是一致的:

  • 綠色和紅色區域的 RPS 以線性方式增加虛擬網頁伺服器的數目。

  • 跨所有已測試設定的主要瓶頸是網頁伺服器 CPU。

  • 紅色區域在稍微的延遲增加為我們新增網頁伺服器,並增加負載。這是由SQL Server及分散式快取服務 (這執行測試伺服器陣列中的所有網頁伺服器) 上新增壓力所造成。

  • 此外, SQL Server與分散式快取的電腦上的平均 CPU 使用量增加網頁伺服器增加數。這是由 on SQL Server與分散式快取服務快取的額外負載所造成。

  • 綠色區域的延遲會維持單層為 web 伺服器個數增加。這是因為在網頁伺服器都不負荷過大時於綠色區域的載入層級。

小規模結果

下圖顯示如何增加網頁伺服器的數目會影響 RPS 對綠色與紅色區域。

這個螢幕擷取畫面顯示在有 10000 位使用者的案例中,增加前端網頁伺服器的數目會對綠色與紅色區域的 RPS 產生何種影響。

下圖顯示如何增加網頁伺服器的數目會影響這兩個綠色和紅色區域負載層級的延遲。

這個螢幕擷取畫面顯示在有 10000 位使用者的案例中,增加前端網頁伺服器的數目會對綠色與紅色區域的延遲產生何種影響。

下圖顯示如何增加網頁伺服器的數目會影響對這兩個綠色和紅色區域負載層級的平均 CPU 使用量。

這個螢幕擷取畫面顯示在有 10000 位使用者的案例中,增加前端網頁伺服器的數目會對綠色與紅色區域的 CPU 使用量產生何種影響。

中型規模結果

下圖顯示如何增加網頁伺服器的數目會影響 RPS 對綠色與紅色區域。

這個螢幕擷取畫面顯示在有 100000 位使用者的案例中,增加前端網頁伺服器的數目會對綠色與紅色區域的 RPS 產生何種影響。

下圖顯示如何增加網頁伺服器的數目會影響這兩個綠色和紅色區域負載層級的延遲。

這個螢幕擷取畫面顯示在有 100000 位使用者的案例中,增加前端網頁伺服器的數目會對綠色與紅色區域的延遲產生何種影響。

下圖顯示如何增加網頁伺服器的數目會影響對這兩個綠色和紅色區域負載層級的平均 CPU 使用量。

這個螢幕擷取畫面顯示在有 100000 位使用者的案例中,增加前端網頁伺服器的數目會對綠色與紅色區域的 CPU 使用量產生何種影響。

大型結果

下圖顯示如何增加網頁伺服器的數目會影響 RPS 對綠色與紅色區域。

這個螢幕擷取畫面顯示在有 500000 位使用者的案例中,增加前端網頁伺服器的數目會對綠色與紅色區域的 RPS 產生何種影響。

下圖顯示如何增加網頁伺服器的數目會影響這兩個綠色和紅色區域負載層級的延遲。

這個螢幕擷取畫面顯示在有 500000 位使用者的案例中,增加前端網頁伺服器的數目會對綠色與紅色區域的延遲產生何種影響。

下圖顯示如何增加網頁伺服器的數目會影響對這兩個綠色和紅色區域負載層級的平均 CPU 使用量。

這個螢幕擷取畫面顯示在有 500000 位使用者的案例中,增加前端網頁伺服器的數目會對綠色與紅色區域的 CPU 使用量產生何種影響。

網頁伺服器數目增加時,會發生下列事件:

  • 平均 CPU 使用量增加SQL Server與分散式快取節點因為在這些共用資源的新增負擔。

  • 平均網頁伺服器 CPU 使用量紅色區域在稍微減少因瓶頸移位稍微SQL Server及分散式快取的電腦。

  • 因為伺服器會保留不在建議的載入層級平均網頁伺服器於綠色區域的 CPU 使用率維持不變。

建議

成功SharePoint Server 2013社交部署是由效能衡量取決於下列因素:

  • 您要支援的作用中使用者的數目

  • 預期的交易混合的讀取和寫入作業

  • 負載分散於伺服器陣列中伺服器的方式

預期的作用中使用者數是一個的關鍵因素決定您應該規劃拓撲中的伺服器的數目。作用中使用者數也會判斷組成主控的各種服務所需的社交案例跨伺服器已啟用。

但是我們測試用典型資料集並套用您可能會預期在實際客戶部署中的負載複雜性,每個部署是唯一的。容量規劃投入比應考慮預期的使用狀況特性、 功能設定和硬體資源的可用性。一些因素可以影響或變更的容量數字的重大的方式如下:

  • 增加的電子郵件流量模式可能會增加 Outlook Social Connector 所產生的負載。

  • 大幅增加百分比的交易混合寫入動作 (例如增加的標記或 @mention) 可能會增加資料庫伺服器上的負載。

  • 您可以新增或移除的網頁伺服器以平衡 CPU 負載網頁伺服器、 SQL Server,與分散式快取節點之間。

謹慎遵循以達最佳效能標準SharePoint Server 2013設定指導。特別針對社交交易重要的考量如下所示:

  • 不同的實體磁碟的設定檔資料庫-因為對設定檔資料庫可能造成社交交易的粗磁碟使用量我們建議您保留設定檔資料庫上執行SQL Server的伺服器上的實體磁碟一組自己。

  • User Profile service 應用程式的記憶體需求的 User Profile service 應用程式位於前端網頁伺服器與嚴重依賴其於記憶體中快取。請確定前端網頁伺服器具有足夠的 RAM 快取許多要求的資料。最小值的建議 RAM 為 12 GB 每部前端網頁伺服器。

  • 分散式快取伺服器的記憶體需求-社交功能、 微型部落格特別是,而定嚴重不足與完善的分散式快取儲存。雖然此快取要重新填入這些電腦上的記憶體不足情況可能會降低 SharePoint 伺服器陣列的容量。因此建議您將主機分散式快取使用至少 12 GB 的 RAM,並向外延展伺服器設定為所需根據使用者總數部署中。

SharePoint Server 2013社交部署會強制佈建針對每個想要使用社交功能的使用者個人網站。規劃建立個人網站集合層級的內容資料庫的成長。如需如何擴充個人網站集合的詳細資訊,請參閱SharePoint 2013 的軟體界限及限制

See also

規劃 SharePoint Server 2013 中規劃效能

SharePoint 2013 的軟體界限及限制