Windows Server AppFabric 快取容量計劃指南

Jason Roth, Rama Ramani, Jaime Alva Bravo

2011 年 3 月

本白皮書提供 Windows Server AppFabric 快取 容量計劃的指導。

1. 簡介

2. 評估 AppFabric 快取效能

3. 容量計劃方法

   1. 步驟一：瞭解瓶頸和識別快取候選項目

   2. 步驟二：評估目前的工作量模式

   3. 步驟三：瞭解實體基礎結構和硬體資源

   4. 步驟四：完成所有應用程式必要的效能 SLA

   5. 步驟五：識別適當的 AppFabric 功能和組態設定

4. 容量計劃工具

5. 容量計劃工具接下來的步驟

6. 監控目前的快取容量需求

簡介

Windows Server AppFabric 快取提供分散式記憶體內部快取叢集。本文提供「Windows Server AppFabric 快取」內部部署的容量計劃指導。

文件中詳細描述 Windows Server AppFabric 快取的架構。如需詳細資訊，請參閱Windows Server AppFabric 快取功能。簡言之，AppFabric 快取叢集是由一或多部快取伺服器所組成 (又稱為快取主機)。快取分散於各快取主機且儲存在記憶體內部。

注意

請注意，也有在定域機組中使用快取的 Windows Azure AppFabric 快取版本。本文中關於評估記憶體需求的某些步驟適用於雲端解決方案，但本文特別著重於內部部署快取叢集的情況。有關使用 Azure AppFabric 快取功能的詳細資訊，請參閱 Windows Azure AppFabric 快取

本文中的資訊以 Microsoft 與客戶共同完成的計劃工作為基礎。所有 AppFabric 快取客戶通常會提出這個問題：「我的情況需要多少部伺服器？」在這種討論中，我們一開始通常會回答「視情況而定」。接著，我們會很快深入各種細節，最後找到適當的出發點。在此過程中，會浮現其他更具體的問題：

• 我的應用程式需要多少快取記憶體？

• 我在快取叢集中應該使用多少部機器？

• 每一部機器應該有多少記憶體？如何設定？

• 網路頻寬如何影響快取叢集效能？

本白皮書的目標是掌握從這種客戶討論所獲得的經驗，目標是提供適用於容量計劃的方法。

如果您正在閱讀本文，表示您目前可能處於幾種開發階段之一：

1. 您剛開始查看分散式快取，在工作量混合、效能需求或伺服器部署拓撲方面沒有任何向下切入資料。在此情況下，您可能想要先查看 AppFabric 快取的某些效能資料。

2. 或者，您已調查過 AppFabric 快取的功能和效能。現在，您想要審視自己的特殊情況和高階需求。這時可以仔細考慮容量計劃。

3. 最後，您會進入正式運作階段。在此階段，您會想要瞭解如何分析效能資料，以確保有足夠的容量。此外，您也會想要規劃未來增加的工作量，根據 AppFabric 快取的執行階段行為，瞭解重要的指標和最佳作法。

本白皮書的編排會依序說明這些階段。如果您剛好在評估 AppFabric 效能，建議閱讀我們的夥伴 Grid Dynamics 所撰寫的詳盡白皮書。在此，我們以簡潔的方式將此白皮書的資料分類，以協助您評估和瞭解容量計劃處理。

如果您準備進入容量計劃流程，我們提供一套步驟，可根據您的情況決定適當的方法。

如果您在使用或測試快取叢集，您可以查看一組重要的效能指標來驗證容量計劃處理，以確定容量適當。此外，我們也會討論一些最佳作法。

評估 AppFabric 快取效能

我們的夥伴 Grid Dynamics 最近在 AppFabric 快取效能方面完成一系列測試。結果已公佈在下列白皮書中：Windows Server AppFabric 快取：詳細的效能與延展性工作表 (英文)。

每一項測試以特定變數為重點，例如快取叢集中的快取大小和伺服器數量。Grid Dynamics 研究可用來評估 AppFabric 快取的效能和延展性。您可以對照應用程式需求來比較各種測試情節和拓撲的輸送量與延遲數。每一次測試時，只會改變一或兩個參數，以專注於其效能影響。整組參數包括：

負載模式	快取使用模式，例如 'Get'、'Put'、'BulkGet'、'GetAndLock'、'PutAndUnlock' 作業的百分比
快取資料大小	測試期間儲存在快取中的資料量
叢集大小	快取叢集中的伺服器數目
物件大小	快取中儲存的物件在序列化之後的大小
類型複雜度	快取中儲存的不同 .NET 物件類型，例如 byte、string[] 等
安全性	快取叢集的安全性設定

除了驗證 AppFabric 快取的效能和延展性，Grid Dynamics 也提供測試控管，可讓您重複測試自己的資料和工作量。這是針對您的特定情況來評估快取效能的另一種選項。

雖然非常建議您檢視整個研究及其結論，但這裡提供一些研究成果的摘要，指出本文接下來要討論的最佳作法：

• 隨著越多機器加入快取叢集中，AppFabric 快取會以線性形態延展。

• 除非是寫入百分比很高的大型快取，快取大小的影響很小。除了其他因素，當受管理的堆積很大時，寫入工作量越高會對 .NET 記憶體回收造成越大的壓力。

• 由於序列化，類型複雜度高只會影響用戶端效能。

• 大量 get 呼叫可獲得較佳的網路使用率。直接快取存取比 Proxy 快很多 (ASP.NET、WCF)，但這是因為中繼層的效能，而非快取效能。

• 悲觀和樂觀鎖定的運作方式類似，您應該使用最適合應用程式設計的技巧。當衝突比例降低時，延遲和輸送量會改善。

• 快取叢集安全性會降低效能，依預設會啟用。關閉安全性時可達到最高輸送量和最低延遲，但由於資料敏感性和商業需求，可能無法接受這樣的設定。

• 在應用程式伺服器與快取伺服器之間使用專用網路時，可降低網路瓶頸。

請注意，Grid Dynamics 文章很適合當做評估 AppFabric 快取的出發點，此外，它也包含可用來瞭解容量計劃處理的原始資料和觀察模式。

容量計劃方法

一旦您確定應用程式可以利用分散式內部記憶體快取時，例如 AppFabric 快取，您就可以進入容量計劃階段。雖然可以直接測試 AppFabric 快取叢集來執行某些容量計劃步驟，但您可能需要在缺少這種測試的情況下建立估計。這是本節的重點。下列步驟以系統化思維說明 AppFabric 快取需求：

1. 瞭解瓶頸和識別快取候選項目

2. 評估目前的工作量模式

3. 瞭解實體基礎結構和硬體資源

4. 完成所有應用程式必要的效能 SLA

5. 識別適當的 AppFabric 功能和組態設定

本文檢查一個線上商店範例應用程式的需求，以提供這些步驟的範例。不過，任何類型的 .NET 應用程式都可以使用快取，且多個應用程式可以存取相同的快取叢集。在此情況下，您應該對每一個應用程式執行下列步驟，並彙總結果來取得容量的精確估計。

步驟一：瞭解瓶頸和識別快取候選項目

首先識別您要快取的資料。這可利用效能分析工具來獲得，例如 SQL Server Profiler、效能監視器、Visual Studio 測試，以及其他許多工具。這些工具可以識別經常存取的資料庫物件或 Web 服務的緩慢呼叫。從這些後端存放區傳回的資料集是快取的潛在候選項目。將此資料暫存於快取中可改進效能，並減輕後端資料存放區的壓力。

當您識別快取的潛在候選項目之後，最好將這些物件分成三個主要類別：活動資料、參考資料及資源資料。這些最好透過範例來解說。

• 活動資料包含個別使用者相關的讀寫資料。例如，在線上商店中，使用者的購物車就是活動資料。它套用至使用者目前的工作階段，可能經常變更。雖然購物車必須維持高可用性，但資料不一定需要永久儲存在後端資料庫。活動資料具有暫存特性，所以是快取的邏輯候選項目。

• 參考資料是多個使用者或多個應用程式例項共用的唯讀資料。經常存取，但很少變更。例如，在線上商店範例中，產品類別目錄就是參考資料。類別目錄的有效性可維持一天以上，但可能由不同的使用者存取數千次。這種資料也很適合成為快取的候選項目。缺少某種快取時，每一個檢視產品類別目錄的使用者就需要存取資料庫中的資料。使用快取可以減輕對後端資料庫重複要求半靜態資料的壓力。由於具有永久特性，所以也是快取的邏輯候選項目。

• 資源資料是使用者之間共用的讀寫資料。例如，支援論壇就包含這種資料。所有使用者都可以讀取論壇文章的回覆。

因為不同類型的快取資料會有不同的使用模式，將資料分成這些類別會很有用。例如，將物件識別為參考資料就自動表示它可能是唯讀工作量。也有助於決定到期原則，愈經常變更的資料，期限愈短。以開發而言，這些邏輯分割可以建議可封裝在程式碼中的區域。

建議為個別物件建立估計，再彙總該資料。下表顯示此階段收集的資訊範例：

快取的物件	快取分類	永久儲存位置
購物車物件	活動資料	無
使用者喜好設定物件	活動資料	後端資料庫
產品類別目錄	參考資料	後端資料庫
使用者論壇執行緒	資源資料	後端資料庫

在識別快取的候選資料時，您不需要在每一個類別中尋找要快取的資料。您可能發現只要快取應用程式的購物車，就可以改善效能和延展性。此步驟的重點是使用可用的資訊來識別最適合快取的項目。

步驟二：評估目前的工作量模式

一旦您決定適合快取的資料，您就必須瞭解應用程式目前如何存取資料及相關聯的工作量模式。此步驟結束時，您應該可以獲得快取記憶體需求的原始估計。您也應該會更加瞭解如何存取和使用資料，這在後續步驟中很重要。

例如，若您以產品類別目錄為快取的候選項目，則應該探索應用程式何時擷取目錄資料和提出這些要求的頻率。根據先前的步驟，您知道這是參考資料，因此是主要的唯讀工作量。徹底瞭解不同物件的工作量模式有助於規劃未來的容量決策。讓我們仔細查看此步驟。

有幾種方法可以更充分瞭解目前的資料存取模式：

1. 徹底檢閱程式碼來查看存取資料的地方和存取的頻率。

2. 使用程式碼分析工具，此工具提供方法呼叫頻率及相關聯的效能資料。

3. 在程式碼中的特定資料存取區段附近建立檢測。記錄資料存取嘗試和資料作業的相關效能。

4. 使用資料庫分析工具 (例如 SQL Server Profiler) 來觀察資料庫操作的次數和持續時間。

請注意，先前的步驟可能已使用其中許多技巧來決定要快取的目標資料。不過，在此階段，您比較想要瞭解未來容量計劃計算時可用的詳細數目。

此評估包括瞭解讀取比例。讀取工作量會影響後續的容量決策。例如，寫入百分比高的工作量會觸發更多次 .NET 記憶體回收。這會在後續步驟中討論。

另一項因素是尖峰負載期間的讀取和寫入頻率。下表顯示範例購物車物件在此階段收集的範例資料。

分析的物件	購物車
讀取 %	50%
寫入 %	50%
每秒讀取操作 (最大)	250
每秒寫入操作 (最大)	250

同樣地，應該對每一種物件類型執行這種分析。不同的物件類型有不同的存取模式，在低負載時也有不同的每秒讀取和寫入次數上限。

若要瞭解快取需求，您必須估計在任何時間快取中各種使用中物件的數目上限。此估計需要在物件插入頻率與這些物件的預期壽命之間取得平衡。這需要舉例才能充分瞭解。

在 ASP.NET Web 應用程式範例中，操作資料可能指出尖峰時間同時有 25000 個使用者。每一個使用者都需要工作階段狀態資訊，所以有 25000 個快取物件。但這些物件可以設為 30 分鐘到期。在尖峰時段，操作資料可能指出每小時有 5000 個新使用者，這表示在 30 分鐘的期限內會出現 2500 個新使用者。此外，有些使用者可能會關閉瀏覽器，然後啟動新的工作階段。雖然是相同的使用者，但現在使用不同的工作階段。所以應該納入額外的填補值。最後，應該計劃未來 6-12 個月的任何預期成長。結果，快取中的使用中物件數目上限的計算如下：

分析的物件：	購物車
尖峰並行使用者	25000
有效期間的新使用者 (30 分鐘)	2500
啟動新瀏覽器工作階段的現有使用者	250
未來成長估計 (25%)	6940
使用中物件總數 (最大)：	~35000 使用中物件數目上限

如果變更輸入，例如到期期間，則會變更尖峰負載期間在快取中有多少未到期物件。這只是思考過程的範例。其他物件類型可能有不同的模式和不同的變數需要計算。例如，若共用的產品類別目錄持續整天有效，則當天在快取中的產品類別目錄物件數目以 1 個為上限。

不過，唯有當您也知道平均物件大小時，知道快取中的物件數目上限才有意義。這原本就是一個難題。在購物車範例中，有一位使用者可能將單一項目放入購物車，而另一位使用者可能有 10 個或 20 個項目。目標是瞭解平均值。就像此程序中的大部分數字一樣，雖然不是很完美，但最後結果卻是經過深思熟慮的快取叢集發出點，而非單純猜測。

物件以序列化形式儲存在快取中。若要瞭解平均物件大小，您必須計算平均序列化物件大小。將項目儲存到快取之前，AppFabric 會使用 NetDataContractSerializer 類別進行序列化。若要決定平均物件大小，請在應用程式中加入檢測程式碼來序列化物件並記錄其序列化大小。

下列程式碼範例嘗試估計單一物件的平均大小。序列化的物件稱為 obj。length 用來記錄長度。如果使用 NetDataContractSerializer 取得大小時發生任何問題，則會改用 BinaryFormatter。您可以將此程式碼包裝在方法中，方便使用。在此情況下，以參數形式傳入 obj，從方法傳回 length。

// requires following assembly references:
//
//using System.Xml;
//using System.IO;
//using System.Runtime.Serialization;
//using System.Runtime.Serialization.Formatters.Binary;
//
// Target object “obj”
//
long length = 0;

MemoryStream stream1 = new MemoryStream();
using (XmlDictionaryWriter writer = 
    XmlDictionaryWriter.CreateBinaryWriter(stream1))
{
    NetDataContractSerializer serializer = new NetDataContractSerializer();
    serializer.WriteObject(writer, obj);
    length = stream1.Length; 
}

if (length == 0)
{
    MemoryStream stream2 = new MemoryStream();
    BinaryFormatter bf = new BinaryFormatter();
    bf.Serialize(stream2, obj);
    length = stream2.Length;
}

注意

請注意，如果您有測試快取叢集設定，您可以將項目加入快取中，並使用 Windows PowerShell 命令 Get-CacheStatistics，以尋找加入快取中的一或多個物件的大小。或者，您可以將快取中多個物件的大小除以快取中的物件計數。您可以選擇透過程式碼或透過測試來收集估計值。

如果您計劃使用 AppFabric 快取來保存工作階段狀態，則心須瞭解 ASP.NET 工作階段狀態的 SQL Server 提供者永遠都使用 BinaryFormatter，而非 NetDataContractSerializer。以 NetDataContractSerializer 類別所序列化的物件，有時會比使用 BinaryFormatter 的物件的序列化大小還大上數倍。如果您在 SQL Server 中查看工作階段狀態物件的大小，則這一點很重要，因為您無法使用該大小並假設在快取中也一定相同。您可以將該大小乘以 6，求得粗略估計。若要求得更準確的估計，請對儲存於工作階段狀態中的物件使用上述程式碼。利用目前為止收集的資料，您可以開始將記憶體需求總計公式化。此步驟包含下列子任務：

1. 專注於物件類型 (例如購物車物件)。

2. 針對該物件，首先取得平均序列化物件大小。

3. 接著，考量快取額外負荷，將平均大小加上 500 位元組。

4. 將該大小乘以使用中物件的數目上限。這樣就求出該物件大小的快取記憶體需求總計。

5. 加上內部快取結構的估計額外負荷 (5%)。

6. 對每一個識別的物件類型重複這些步驟。

7. 將結果加總，求出快取記憶體需求總計。

在此過程中，請注意，大小估計應該加上每一個物件大約 .5 KB 的額外負荷。另外，還有其他內部資料結構需要快取中的記憶體。管理區域、標籤和通知都需要額外的記憶體。在範例計算中，我們加上總計的 5% 來考量這些內部結構，但根據您使用這些快取功能的程度，此百分比會有所增減。

此時，您應該考慮一個特定 AppFabric 快取功能的影響，也就是高可用性。此功能會在次要伺服器上建立快取項目的複本。這表示如果單一快取伺服器關閉，則由次要快取伺服器接管，不會遺失資料。如果您選擇使用高可用性，則必須將記憶體估計加倍。您也必須使用 Windows Server 2008 Enterprise Edition 或更高的版本。請注意，高可用性功能是以具名快取層級為基礎。這表示如果您在相同叢集中建立兩個具名快取，則不必對每一個快取使用高可用性。應用程式可以將某些項目放入具有高可性的具名快取中，而將某些項目放入沒有高可用性的快取中。這樣可以幫助您充分利用記憶體資源。因此，必須瞭解高可用性的決策，因為使用高可用性的快取會使記憶體需求加倍。

舉例來說，下表評估相同應用程式中的活動資料和參考資料的需求。視您的情況而定，您可以選擇在物件層級或應用程式層級上執行此估計。您可以在此範例中增加其他欄位，再適當地加上標籤。

分析的物件：	活動資料	參考資料
平均序列化物件大小：	250 KB	60 KB
每一個物件的快取叢集額外負荷：	0.5 KB	0.5 KB
調整的平均序列化物件大小：	250.5 KB	60.5 KB
使用中物件數目上限：	~35000	~68000
快取記憶體需求：	8.4 GB	3.9 GB
啟用高可用性？	16.8 GB	否
內部資料結構額外負荷 (5%)：	0.8 GB	0.2 GB
記憶體需求總計：	17.6 GB	4.1 GB

加總這些估計可求得快取叢集的初始記憶體需求。在此範例中，總計是 21.7 GB。利用此估計，您現在可以開始查看其他考量，包括實體基礎結構、SLA 需求，以及 AppFabric 快取組態設定。

步驟三：瞭解實體基礎結構和硬體資源

必須瞭解實體基礎結構和資源的可用性。以下是一些常見問題：

1. 您可以佈建實體機器或虛擬機器嗎？

2. 如果您目前有硬體，則是什麼機器組態 (例如，8 GB RAM，四核心)？

3. 快取叢集將位在與應用程式伺服器相同的資料中心嗎？

4. 有什麼網路功能？

如果您考慮使用虛擬機器作為快取伺服器，則需要考慮幾個事項。例如，您必須考量在相同實體機器上有多個虛擬機器的影響。多個虛擬機器可能共用相同的網路卡，導致網路瓶頸的可能性上升。此外，主要和次要快取主機 (相同實體機器上的虛擬機器) 之間可能設定高可用性。如果該實體機器關閉，則不會留下資料的複本。如需相關資訊，請參閱在虛擬機器中執行 AppFabric 快取的指導 (英文)。

對於現有的機器，沒有建議的規格。不過，以大型快取叢集而言，16GB RAM 四核心機器的效能較好。一般而言，計劃正確數目的實體記憶體和網路負載是最重要的考量。

以實體和虛擬機器兩者而言，您應該注意快取叢集相對於使用快取的應用程式或 Web 伺服器的位置。如果位於不同的資料中心，請確定這些資料中心的延遲不會對效能造成負面影響。在此階段，可能會想要使用應用程式或 Web 伺服器作為快取伺服器。雖然有可能，但並不支援。首先，這些機器上的服務 (例如 IIS) 有任何資源使用量爆增情形時，可能會影響快取叢集。其次，快取服務會假設位於專用伺服器上，使用的記憶體可能比您指定的數量更多。

對於網路功能，您應該評估預期網路負載，並與您的基礎結構進行比較。首先，您必須瞭解每一部快取伺服器將處理多少資料，以及網路卡功能是否足夠。如果不足，您可能需要更多快取伺服器。例如，假設平均快取物件大小為 500.5 KB，且快取叢集上每秒有 240 個作業。如果使用單一快取主機，則結果如下所示：

每秒物件讀寫次數：	240
快取叢集中的機器數目：	1
每一部機器每秒快取作業數目：	240
平均物件大小：	500.5 KB
每秒傳送的資料大小：	240 * 500.5 = 117.3 MBps

如果每一部機器有一張 1Gbps 網路卡，則最大輸送量約為 119 MBps。計算值 117.3 MBps 會超出該單一伺服器的負荷。這會造成網路極可能發生瓶頸。不過，如果快取叢集中使用三部機器，則平均分散快取要求可讓每一部伺服器只處理該負載的 1/3。

另外，考慮會存取快取叢集的應用程式伺服器的網路使用率。如果應用程式伺服器與其他系統之間會交換大量資料，您應該考慮在應用程式伺服器與快取叢集之間建立專用網路。這需要在每一部應用程式伺服器上再掛接一張網路卡。

最後的網路考量在於網路是否能夠處理整個路徑上的必要負載。每一部快取伺服器上只有一張 1Gbps 網路卡並不夠。網路上的交換器及其他端點也必須能夠處理負載。使用作業來符合此需求。

步驟四：完成所有應用程式必要的效能 SLA

在決定最終組態之前，您也必須瞭解任何商業需求，包括效能和可靠性服務等級協定 (SLA)。就實際意義來說，此步驟會影響快取叢集的數目和每一個叢集中的快取主機數目。

例如，若您有關鍵性應用程式使用快取叢集，您可能會想要隔離該快取叢集與其他優先順序較低的應用程式。這些優先順序較低的應用程式可能使用較多記憶體、網路或 CPU 資源，導致對關鍵性應用程式造成負面影響。

以下是會影響此決策的具體因素：

• 在快取叢集層級上維護安全性。如果使用者可存取快取叢集，該使用者可能會存取快取伺服器上的任何資料 (假設該使用者知道要求的快取名稱和索引鍵)。如果不同類型的資料需要不同的安全性設定，則隔開快取叢集很合理。如需詳細資訊，請參閱管理安全性 (Windows Server AppFabric 快取)。

• 當記憶體達到上限標準時，就會開始收回未到期項目。低估一個快取所需的記憶體數量會影響叢集上的所有快取。由於記憶體壓力而開始收回時，即使只有一個快取造成記憶體壓力，也會在所有快取上收回。建立不可收回的快取可稍微減輕這種壓力，但必須小心進行。如需詳細資訊，請參閱到期與收回。

• 將快取叢集隔開到某種程度時，管理會更輕鬆。您不會想要為 100 個不同快取來管理不同的叢集。但 2 個不同的大型快取有各自的快取叢集可能很有用，因為您可以個別地管理、調整和監控它們。

最後，有些需求可能考量延遲和輸送量。若要瞭解此決策，請參閱 Grid Dynamics 白皮書中的指導和測試結果。例如，您可以比較快取叢集的輸送量需求與 Grid Dynamics 文件中發佈的測試結果。他們的研究可能指出您的伺服器太少，不足以達成輪送量目標。必須瞭解此研究不見得完全符合您的物件類型、物件大小及實體與邏輯基礎結構。但是，仍然提供實證的測試結果，可協助您做出明智的決定。

步驟五：識別適當的 AppFabric 功能和組態設定

這部分的處理需要考量 AppFabric 快取的特定組態設定，以及 AppFabric 快取叢集的架構。即使收集到所有正確的實證和商業資料，您仍然可能因為忽略這些 AppFabric 快取設定而規劃錯誤。

下表列出各種 AppFabric 快取功能及容量計劃的相關考量。

區域	您可以建立多區域，但每一個區域只能存在於一部快取主機上。若要利用分散式快取，應用程式必須使用多個區域。請注意，未指定區域的所有呼叫會內部自動使用預設區域。快取叢集中的每一部快取主機必須能夠裝載最大區域的大小上限。
通知	快取可以啟用通知，而快取用戶端可以接收這些通知。這樣會在伺服器端增加額外的網路流量和處理器使用率。結果根據通知間隔和傳送的通知數目而有所不同。在極短間隔內出現大量通知會影響效能和延展性。沒有明確的指導可估計此影響，必須在測試期間觀察。
本機快取	本機快取會在用戶端和伺服器上快取物件來改善效能。使用本機快取時，請考量用戶端機器上的記憶體影響。此功能不影響伺服器端的記憶體容量計劃，因為所有本機快取的項目也存在於伺服器上。不過，如果使用通知來判定本機快取無效，則通知處理會影響伺服器端。
用戶端應用程式設計與組態	用戶端應用程式設計可能影響整體效能。例如，您應該儲存您建立的任何 DataCacheFactory 物件以重複使用，而非在每一次呼叫時重新建立這些物件。為每一個執行緒建立一個 DataCacheFactory 物件也可能很有用。或者，如果多個執行緒共用單一 DataCacheFactory 物件，請考慮提高 MaxConnectionsToServer 設定。這樣會增加每一個 DataCacheFactory 的快取伺服器連線數目。
高可用性	如上所述，使用「高可用性」的快取需要將計算的記憶體需求加倍。但此功能最少也需要三部伺服器。如果一部伺服器關閉，必須還剩下兩部伺服器可在失敗後支援每一個項目的主要和次要複本。請注意，此功能也需要所有伺服器上都有 Windows Server 2008 Enterprise Edition 或更高的版本。
具名快取	目前，以 128 個具名快取為限。當您的應用程式需要的數目大於此設定數目時，這會成為容量計劃決策。在此情況下，您需要多個快取叢集，或是應用程式必須設計為使用較少的快取。另一種策略是以程式設計方式在具名快取內建立區域。
XML 組態儲存區	當您使用共用網路位置作為快取叢集組態儲存區時，您在叢集中至少應該有三部伺服器都指定為主要主機。如需理由的相關資訊，請參閱更新快取伺服器 (Windows Server AppFabric 快取)。

很明確地，需要瞭解的其中一個最重要設定，就是每一部快取主機上的記憶體設定。您可以使用 Windows PowerShell 命令 Get-CacheHostConfig 來檢視每一部快取主機上的預設記憶體設定。

注意

如需有關如何使用快取 Windows PowerShell 命令的資訊，請參閱常見快取叢集管理工作 (Windows Server AppFabric 快取)。

下列螢幕擷取畫面顯示 Get-CacheHostConfig 在 4 GB RAM 機器上的輸出。

根據預設，在指定的伺服器上，保留給快取的記憶體數量是 RAM 總數的 50%。在此範例中，RAM 的一半是 2 GB。所以，剩餘記憶體可供作業系統和服務使用。即使在記憶體很多的機器上，仍建議保留此預設值。如前所述，快取服務假設在專用伺服器上執行，使用的記憶體可能比您快取配置的數量更多。雖然此記憶體使用量有一部分是因為快取服務的內部設計，但有一部分也與 .NET 記憶體管理和記憶體回收有關。即使在 .NET 應用程式中釋放記憶體，仍然必須等待從處理程序記憶體中釋放記憶體回收。考量記憶體回收的不具決定性本質，此處理需要實體記憶體的緩衝區。

一旦您瞭解記憶體回收的影響，您會發現為了考量記憶體回收週期，寫入百分比和頻率都很高的工作量需要更大的記憶體緩衝區。幾乎唯讀的工作量不需要此考量。在此情況下，您應該提高某些情況下保留給快取的記憶體數量。例如，在 16 GB 的機器上，您可以考慮保留 12 GB 做為快取大小設定 (而非預設的 8 GB)，其中額外提供 4 GB 給作業系統和服務。這假設機器專供快取服務使用，而這是目前唯一支援的組態。在此範例中，您應該使用預期負載來測試此記憶體組態。如果記憶體配置太過急躁，測試會透過記憶體相關問題 (例如收回或節流) 來透露此錯誤。如需詳細資訊，請參閱疑難排解伺服器問題 (Windows Server AppFabric 快取)。下列範例使用 Set-CacheHostConfig 命令，在名為 Server1 的伺服器上將快取大小設定為 12 GB。

Set-CacheHostConfig -HostName Server1 -CachePort 22233 -CacheSize 12288

Get-CacheHostConfig 輸出中需要觀察的另一個項目就是標準值。LowWatermark 值的預設值是快取大小設定的 70%。當快取的記憶體達到 LowWatermark 時，快取服務會開始收回已過期的物件。這沒有問題，因為反正無法存取這些物件。

HighWatermark 值的預設值是快取大小設定的 90%。在 HighWatermark 水準時，不論物件是否過期都會收回物件，直到記憶體降到 LowWatermark 水準為止。很明顯，這可能損害效能，也可能導致不適當的使用者經驗。

建議將快取使用量規劃為 LowWatermark 水準，以避免可能達到 HighWatermark。如需更詳細的說明，請參閱「到期與收回」。

提示

完整記憶體回收週期可能造成短暫延遲，這通常在重試錯誤中發生。因此，建議每一部快取主機的記憶體為 16 GB 或更少。超過 16 GB RAM 的機器在完整記憶體回收週期內可能暫停較久。可知，不會限制每一部快取主機使用更多記憶體。通常是唯讀的工作量可能不會經常經歷完整記憶體回收週期。您可以透過負載測試來做最佳判斷。

在先前的範例中，我們計算快取記憶體需求總計的估計為 21.7 GB。因為我們想要高可用性，所以至少需要三部伺服器。假設每一部伺服器有 16 GB 的 RAM。在此範例中，我們在每一部伺服器上維持預設快取大小設定 8 GB。如前所述，LowWatermark (70%) 應該是每一部伺服器上可用的目標記憶體。這表示每一部快取伺服器的記憶體估計是 5.6 GB。根據這些因素，下表顯示四部伺服器提供 22.4 GB 的快取記憶體，符合 21.7 GB 需求。

記憶體需求總計	21.7 GB
初始記憶體 (快取主機)	16 GB
快取大小設定 (快取主機)	8 GB
下限標準 (快取主機)	70%
每一部快取主機調整的記憶體目標	5.6 GB
快取叢集的記憶體總數 (3 部機器)	5.6 GB * 4 部伺服器 = 22.4

同樣地，記住，您也可以使用 Grid Dynamics 白皮書中發佈的結果，針對輸送量和延遲目標來驗證此估計。這些測試結果可能會使您稍微修改此初始估計，例如再增加一部快取伺服器。此處的重點是使用此種可用的資源來做出明智的決定。

容量計劃工具

試算表是先前幾節中容量計劃步驟的邏輯工具。我們已組合範例試算表，請從這裡下載。具有星號的項目是指您應該根據計劃和資源來修改的項目。其餘計算由試算表完成。

試算表的第一部分指定每一部快取主機的伺服器組態。請注意，您可以在計劃處理中變更此設定，然後在最終計算中觀察差異。下列螢幕擷取畫面顯示這個第一區段。

重要

除非您使用預設安裝值，否則您必須在每一部快取主機上使用 Set-CacheHostConfig 命令來套用 CacheSize 和 LowWatermark 設定。

第二個區段可讓您填寫不同類型的物件的估計。在範例試算表中，只有兩個區段用於「活動資料」和「參考資料」。然後，提供一連串空白欄位。您可以根據在計劃中使用的細微程度 (物件、類別、應用程式等)，重新命名這些欄位。下列螢幕擷取畫面顯示這個第二區段。

第三個區段估計網路需求。您需要填寫平均讀寫物件大小和每秒讀寫作業上限。此區段計算該物件類型的網路頻寬需求上限。這可讓您概略瞭解機器和網路卡組合是否能夠處理負載。如先前各節所述，您也會想要查看網路路徑上的頻寬。下列螢幕擷取畫面顯示這個第三區段。

最終區段彙總記憶體和網路區段中的需求。然後，使用第一個區段中指定的機器組態來計算伺服器數目。「其他伺服器」欄位可讓您視情況提高此計算總合。例如，若計算指出只需要兩部伺服器，您可以在總數中再增加一部伺服器，以充分支援高可用性。下列螢幕擷取畫面顯示這個最終區段。

注意

以上螢幕擷取畫面使用類似本文中範例的數字，但估計的伺服器是三部，而非四部。原因是試算表將 Cache Size Setting(Set-CacheHostConfig) 值設定為 12 GB，以示範此自訂設定。將此值變更為 8 GB 會產生本文前幾節中類似的結果。

容量計劃工具接下來的步驟

在上一節中，提出方法來決定快取叢集數目的初始估計、每一個叢集中的快取主機數目，以及這些快取主機的組態。但您應該瞭解這只是估計，可能隨著測試及持續監控而變更。

如果您決定繼續依照計劃來使用 AppFabric 快取，您可以建立概念證明，以瞭解 AppFabric 快取在解決方案中的運作方式。之後，您可以設定測試快取叢集，在環境中執行測試。視測試結果而定，您可以進一步變更組態來達到容量、效能及延展性需求。下節涵蓋您在測試與正式階段可以查看的特定持續度量。

監控目前的快取容量需求

快取容量計劃絕對不是精密科學。進入結論的許多數字本身就是估計。此外，應用程式使用方式和模式會隨著時間而改變。因此，您應該監視效能指標，以確定快取叢集滿足容量需求。成功的容量計劃是持續過程，在測試與正式環境中不斷進行。

效能監視器工具持續監控容量的最佳方式。在每一部快取主機上，建議您監控下列計數器：

監控類別	效能監視器計數器
記憶體	AppFabric 快取: 主機\資料大小位元組總數 AppFabric 快取: 主機\已收回物件總數 AppFabric 快取: 主機\收回的執行作業總數 AppFabric 快取: 主機\已收回記憶體總數 AppFabric 快取: 主機\物件計數總數 .NET CLR Memory(DistributedCacheService)\# Gen 0 Collections .NET CLR Memory(DistributedCacheService)\# Gen 1 Collections .NET CLR Memory(DistributedCacheService)\# Gen 2 Collections .NET CLR Memory(DistributedCacheService)\# of Pinned Objects .NET CLR Memory(DistributedCacheService)\% Time in GC .NET CLR Memory(DistributedCacheService)\Large Object Heap size .NET CLR Memory(DistributedCacheService)\Gen 0 heap size .NET CLR Memory(DistributedCacheService)\Gen 1 heap size .NET CLR Memory(DistributedCacheService)\Gen 2 heap size Memory\Available MBytes
Network	Network Interface(*)\Bytes Received/sec Network Interface(*)\Bytes Sent/sec Network Interface(*)\Current Bandwidth
CPU	Process(DistributedCacheService)\% Processor Time Process(DistributedCacheService)\Thread Count Process(DistributedCacheService)\Working Set Processor(_Total)\% Processor Time
輸送量	AppFabric 快取: 主機\用戶端要求總數 AppFabric 快取: 主機\用戶端要求總數/秒 AppFabric 快取: 主機\Get 要求總數 AppFabric 快取: 主機\Get 要求總數/秒 AppFabric 快取: 主機\Get 要求總數 AppFabric 快取: 主機\Get 要求總數/秒 AppFabric 快取: 主機\GetAndLock 要求總數 AppFabric 快取: 主機\GetAndLock 要求總數/秒 AppFabric 快取: 主機\讀取要求總數 AppFabric 快取: 主機\讀取要求總數/秒 AppFabric 快取: 主機\寫入操作總數 AppFabric 快取: 主機\寫入操作總數/秒
雜項	AppFabric 快取: 主機\快取遺漏百分比 AppFabric 快取: 主機\過期物件總數 AppFabric 快取: 主機\傳遞的通知總數

這裡列出的許多計數器直接連接至容量計劃處理。例如，有數個記憶體計數器。“Memory\Available Mbytes” 顯示機器上剩餘多少可用的實體記憶體 (MB)。如果此計數器降到實體記憶體總數的 10% 以下，則很可能開始節流。如需相關資訊，請參閱節流疑難排解 (Windows Server AppFabric 快取)。其他計數器為快取功能專用。「AppFabric 快取: 主機\收回的執行作業總數」指出收回記憶體的頻率。當記憶體層級超過上限標準時，此計數器會隨著記憶體降到下限標準而指向這些收回執行作業。同樣地，其他計數器與本文先前幾節中的容量計劃思考處理相關。

請注意，另外也會擷取服務 DistributedCacheService 的處理計數器和機器的 Processor 計數器。處理器使用率偏高會對快取叢集效能造成負面影響。如果您未偵測到處理器使用率偏高的時段，則必須識別是否與快取服務 (DistributedCacheService.exe) 或機器中的其他處理有關。

除了效能監視器工具，您還可以使用隨著 AppFabric 一起安裝的 Windows PowerShell 命令。其中許多命令可用來監控快取叢集的健康情況和狀態。如需詳細資訊，請參閱健康情況監控工具 (Windows Server AppFabric 快取) 和 AppFabric 快取中的記錄和記數器 (英文)。

另請參閱

其他資源

安裝 Windows Server AppFabric
Windows Server AppFabric 快取功能
開發快取用戶端
設定 ASP.NET 工作階段狀態提供者
叢集組態儲存選項 (Windows Server AppFabric 快取)
Windows Server AppFabric 快取部署與管理指南
Windows Server AppFabric 和 Windows Azure AppFabric 連結與資源

  2011-12-05