效能與容量規劃 (FAST Search Server 2010 for SharePoint)

發行項
03/07/2017

適用版本： FAST Search Server 2010

上次修改主題的時間： 2015-03-09

在規劃Microsoft FAST Search Server 2010 for SharePoint 部署的效能與容量時，必須針對您自己的商務環境以及系統架構，做多方面的考量。

商務環境考量
系統架構考量

如需如何規劃 Microsoft SharePoint Server 2010 伺服器陣列整體效能與容量的詳細資訊，請參閱＜SharePoint Server 2010 的容量規劃＞。

注意

本文假設您使用 SharePoint Server 2010 編目程式、索引連接器架構及 FAST Search Server 2010 for SharePoint 內容 Search Service 應用程式 (內容 SSA) 編目內容。

商務環境考量

在您的環境中，定義下列各項：

內容磁碟區容量	必須有多少內容可供搜尋？項目總數應包括所有物件：文件、網頁、清單項目等等。
可用性	可用性需求為何？客戶需要可倖免於特定伺服器故障的搜尋解決方案嗎？請注意，可用性有兩個主要層級：查詢比對的可用性，以及索引的可用性。
內容新鮮度	搜尋結果必須多「新鮮」？您希望在客戶修改資料之後多久，搜尋可在結果中提供更新的內容？您希望內容變更的頻率為何？
查詢評估容量	同時會有多少人搜尋整個內容？這包括使用者輸入查詢方塊，以及其他隱藏的查詢，例如網頁組件自動搜尋資料，或是 Microsoft Outlook 2010 Social Connector 要求的活動編目，包含需要從搜尋系統進行安全性調整的 URL。

系統架構考量

在系統架構方面，請確定您了解索引和查詢評估程序，以及其所產生之各種拓撲選擇和網路流量的效果。此外，您可能也會想要注意網頁分析器元件的規劃，因為此元件的效能取決於索引項目的數目，以及項目是否包含超連結。

編製索引對效能與容量的影響
查詢評估對效能與容量的影響
拓撲對效能與容量的影響
網路流量對效能與容量的影響
網頁連結分析對效能與容量的影響

編製索引對效能與容量的影響

在將內容編目的過程中，FAST Search Server 2010 for SharePoint 伺服器陣列要經歷好幾個階段：索引擷取、索引維護及索引清理。

索引擷取

索引擷取階段的特點是完整 (可能為並行) 編目。

在新增內容時，編目效能主要取決於所設定的項目處理元件數。CPU 核心數及其個別速度都會影響結果。就一級近似值而言，1GHz 的 CPU 核心每秒可以處理一個普通大小的 Office 文件 (約 250 Kb)。例如，在使用 48 個 CPU 核心 (每個 2.26GHz) 處理項目的情況下，可提供的總預估輸送量為平均每秒 48 × 2.26 ≈ 100 個項目。

索引維護

索引維護階段的特點是所有內容的累加編目，偵測新的及變更的內容。一般來說，當您編目 SharePoint Server 2010 內容來源時，所遇到的大部分變更都與存取權有關。

累加編目可包含各種作業：

存取權 (ACL) 變更及刪除：這些作業所需的項目處理接近零，但索引器中的處理負載量很高。編目速率會高於完整編目。
內容更新：除了索引器需要的處理比新增內容多之外，這些作業還需要完整項目處理。就內部而言，這類更新對應於舊項目的刪除，以及新內容的增加。
增加：累加編目也可能包含新發現的項目。這些編目的工作量與索引擷取編目相同。

累加編目可能會比初始完整編目快或慢，需視作業類型而定。如果主要是 ACL 更新及刪除，就會比較快；如果主要是已更新的項目，就會比較慢。

除了內容來源的更新之外，像連結分析、點選連結記錄分析以及索引分割區重新組織之類的內部作業，也會改變索引。FAST Search Server 2010 for SharePoint 連結分析及點選連結記錄分析，會對索引產生額外的內部更新。例如，某項目中的超連結會導致與參照項目相關聯之錨定文字資訊的更新。這類更新的負載模式與 ACL 更新相似。索引器會定期執行索引分割區的內部重新組織，以及資料磁碟重組。它會在每天凌晨 3 點開始磁碟重組，並在需要時，重新分散至各個分割區。這兩項內部作業都暗示著，您可能也會在進行中的內容編目間隔之外，看到索引活動。

索引清理

當您從 Search Service 應用程式刪除內容來源及/或起始位址時，就會進入索引清理階段。當內容索引連接器找不到主機供應的內容時，也會進入此階段：索引連接器會在三個連續編目期間尋找主機，但是如果找不到主機，即會刪除內容來源，並導致索引進入清理階段。

查詢評估對效能與容量的影響

整體索引有兩個分割層級：索引資料欄及索引分割區。

當完整的索引太大，而無法存放在一部伺服器上時，您可以將它分成數個各自獨立的索引資料欄。然後查詢比對元件會對照搜尋叢集中的所有索引資料欄來評估查詢，並將得自每個索引資料欄的結果，合併到最終的查詢結果清單。在每個索引資料欄內，索引器會利用索引的分割，以較低的索引及查詢延遲處理大量索引項目。此分割作業是動態的，並且會在每個索引伺服器的內部處理。當查詢比對元件評估查詢時，每個分割區都會在個別的執行緒中執行。預設分割區數目為 5。若要讓每部伺服器 (資料欄) 處理 1500 萬以上的項目，您必須設定較大量的分割區。

單一查詢評估的圖解如下。

單一查詢圖例

CPU 處理 (淡藍色) 之後，接著是等待磁碟存取週期 (白色)，以及實際的磁碟資料讀取傳輸 (深藍色)；每個查詢會依序重複 2-10 次。這表示除了儲存裝置子系統的 I/O 延遲之外，CPU 的速度也會影響查詢延遲。查詢比對元件會在所有索引資料欄中，跨多個索引分割區，個別平行評估每一個查詢。在預設的五個分割區設定中，這表示在每個資料欄內的五個個別執行緒中，都會評估每個查詢。

當查詢負載增加時，查詢比對元件會平行評估多個查詢，如下圖所示。

多個查詢圖例

由於查詢評估的不同階段會在不同時間發生，所以並行 I/O 存取不可能成為瓶頸。CPU 處理顯示相當大的重疊，其會橫跨伺服器的可用 CPU 核心進行排程。在已測試的所有情況中，當所有可用 CPU 核心使用率為 100% 時，查詢輸送量即達其上限。在儲存裝置子系統飽和之前，就會發生此情況。CPU 核心愈多、愈快，可增加查詢輸送量，最後使磁碟存取成為瓶頸。如需已測試情況的詳細資訊，請參閱 FAST Search Server 2010 for SharePoint 容量規劃(可能為英文網頁)白皮書。

注意

在具有許多索引資料欄的較大部署中，查詢處理與查詢比對元件之間的網路流量可能也會變成瓶頸，您可以考慮增加此介面的網路頻寬。

針對查詢負載達到輸送量上限的 CPU 耗盡點，與查詢延遲較無關聯。每個查詢的延遲都是最大索引分割區中項目數的函數。請注意，當您在閒置時段之後套用查詢負載時，查詢延遲會因為快取效果而稍微提高。持續進行的編目會讓查詢延遲降低一些。但是如果搜尋資料列有備份索引器，效果就會比在與索引器及項目處理相同之伺服器上執行搜尋的系統低很多。

拓撲對效能與容量的影響

由於編製索引和查詢比對都會使用 CPU 資源，若將編製索引和查詢比對部署在相同的資料列上，則在內容編目期間，查詢效能會有些降低。單一資料列部署可能會使編製索引、查詢比對及項目處理全都在相同的伺服器上執行。

您可以部署專用的搜尋資料列，將查詢流量與編製索引及項目處理隔離。這需要搜尋叢集中有兩倍數量的伺服器，以提供較優質且較一致的查詢效能。這樣的設定也可以提供查詢處理及查詢比對備援。當索引器建立新一代的索引 (給定分割區的新版索引) 時，專用的搜尋資料列勢必會在編目及編製索引期間帶來額外的流量。索引器元件會將新的索引資料透過網路傳遞至查詢比對元件。若有適合的儲存裝置子系統，針對查詢效能的主要效果，會因為快取失效的關係，當新一代的索引到達時，有少量降低。

您也可以部署備份索引器，以處理主要索引器上無法回復的錯誤。您通常會將備份索引器與搜尋資料列共置。就此情況而言，您不應將項目處理部署至已合併的備份索引器與搜尋資料列。備份索引器會增加搜尋資料列上的 I/O 負載，因為主要與備份索引器之間會有額外的內部管理通訊，以讓這兩部伺服器上的索引資料保持同步。這其中也包括這兩部伺服器之磁碟上的額外資料儲存。請確定您已規劃儲存裝置子系統處理額外的負載。

網路流量對效能與容量的影響

隨著個別伺服器上的 CPU 效能增加，伺服器之間的網路連線可能會成為瓶頸。舉例來說，即使是具備四部伺服器的小型 FAST Search Server 2010 for SharePoint 伺服器陣列，每秒可處理 100 個以上的項目並編製索引。如果一般項目為 250 Kb，這就代表大約每秒 250 Mbit 的平均網路流量。即使是每秒 1Gbit 的網路連線，這樣的負載也可能會飽和。

由內容編目及編製索引而產生的網路流量，可分解如下：

內容 SSA 中的索引連接器從來源擷取內容
內容 SSA (在 SharePoint Server 2010 伺服器陣列中) 將所擷取的項目批次傳遞至 FAST Search Server 2010 for SharePoint 伺服器陣列中的內容散發者元件
內容散發者將每個項目批次傳送到可用的項目處理元件 (通常位在另一部伺服器上)
處理之後，項目處理元件將每個批次傳遞至索引發送程式，依據索引資料欄的分佈分割批次
索引發送程式將已處理的項目散佈至每個索引資料欄的索引器
如果有多個搜尋資料列，索引器會將二進位索引複製到額外的搜尋資料列

跨所有伺服器及元件所累積的網路流量，會比分散式系統中的內容資料流本身高出五倍以上。您必須要有高效能的網路交換器，才可在這樣的部署中交互連接伺服器。

高查詢輸送量也會產生高網路流量，尤其是當您使用多個索引資料欄時。請務必定義部署設定及網路設定，以避免來自查詢的網路流量與來自內容編目及編製索引的網路流量之間，有太多重疊。

網頁連結分析對效能與容量的影響

網頁分析器元件的效能規劃，取決於索引項目數量，以及項目是否包含超連結。包含超連結 (或連結項目) 的項目代表主要負載。資料庫類型的內容通常不包含超連結。內部網路內容 (包括 SharePoint 網站內容) 常會包含具有超連結的 HTML。外部 Web 內容幾乎是包含許多超連結的 HTML 文件。

雖然對網頁分析器元件的效能規劃而言，CPU 核心數是很重要的，但是在決定什麼時候必須使用錨定文字和排名資料更新索引時，磁碟空間是最重要的。如果有足夠的磁碟空間，網頁分析器元件只會執行連結、錨定文字或點選連結記錄分析。下表指定網頁分析器元件的基本原則規劃建議。

內容類型	每個 CPU 核心的項目數	每一百萬個項目的 GB 磁碟
資料庫	2 千萬	2
SharePoint Server 2010 / 內部網路	1 千萬	6
公用 Web 內容	5 百萬	25

注意

此表格提供適用於整個伺服器陣列的規劃原則。如果您將網頁分析器元件分散至二部伺服器，則每部伺服器的需求為給定值的一半。

針對所有類型的內容，您必須要有的可用記憶體數量都一樣，但需視所使用的核心數而定。建議每一百萬個項目各 30 MB，再加上每個 CPU 核心各 300 MB。如果安裝中包含不同類型的內容，最佳的容量規劃策略，就是將要求最高的內容類型用作規劃的基礎。例如，若系統中混合了資料庫及 SharePoint 網站內容，建議您把系統當作只包含 SharePoint 網站內容進行規劃。