首先确定要缓存的数据。完成该操作的方法是：使用性能分析工具（如 SQL Server Profiler、性能监视器、Visual Studio 测试）以及很多其他工具。这些工具可以确定经常访问的数据库对象或降低调用 Web 服务的速度。从这些后端存储中返回的数据集是缓存的潜在候选项。将该数据临时存储在缓存中可以提高性能并缓解对后端数据存储的压力。

确定潜在的缓存候选项之后，最好将这些对象分为三大类之一：活动数据、参考数据和资源数据。最好使用示例对它们进行解释。

• 活动数据包含与单个用户相关的读取/写入数据。例如，在某个在线商店中，用户的购物车就是活动数据。该数据应用于用户的当前会话并且可能会经常更改。尽管保持购物车的高可用性非常重要，但并不一定需要将该数据永久存储在后端数据库中。由于其暂时的特性，活动数据便成为缓存的逻辑候选项。
• 参考数据是由多个用户或多个应用程序实例共享的只读数据。该数据经常访问，但不经常更改。例如，在在线商店的示例中，产品目录就是参考数据。该目录应该在一天或若干天内有效，但不同的用户可能会访问几千次。这种类型的数据也是缓存的重要候选项。如果没有某些类型的缓存，则查看产品目录的每个用户都需要访问数据库中的数据。使用缓存可以缓解对后端数据库重复请求半静态数据的压力。由于其永久的特性，参考数据便也成为缓存的逻辑候选项。
• 资源数据是在用户之间共享的读取/写入数据。例如，支持论坛就包含这种类型的数据。所有用户都可以阅读对论坛帖子的回复。

由于不同类型的缓存数据将具有不同的使用模式，因此将数据分为这些类别可能会非常有帮助。例如，确定某个对象是否是参考数据会自动建议，该对象更像是只读工作负荷。还可以帮助确定过期策略，对于经常更改的数据来说一般更短一些。对于开发，这些合理的划分可以建议代码中可以封装的区域。

建议您为各个对象创建评估，然后再将该数据合计起来。下表显示了在此阶段收集的信息示例：

确定缓存的候选数据时，不需要您在每个类别中查找要缓存的数据。您可能发现只是缓存应用程序的购物车就可以提高性能和可伸缩性。此步骤最重要的一点是使用可用的信息来确定要缓存的最佳项目。

确定要缓存的适当数据之后，您必须了解应用程序当前访问该数据以及关联的工作负荷模式的方式。在此步骤结束时，您应该能够得出缓存内存要求的粗略估计。您还应该更好地了解访问和使用数据的方式，这在后面的步骤中非常重要。

例如，如果您将产品目录作为缓存的候选项，则您应该探究应用程序检索目录数据的时间以及进行这些请求的频率。基于之前的步骤，您知道这是参考数据，因此主要是只读工作负荷。详细了解不同对象的工作负荷模式将指导将来的容量决策。让我们仔细看看此步骤中涉及的内容。

有很多方法可以更好地了解您的当前数据访问模式：

1. 仔细查看代码，以了解访问数据的位置以及访问的频率。
2. 使用可以提供方法调用频率以及关联的性能数据的代码探查器。
3. 在特定数据访问部分的代码中创建规范。记录数据访问尝试以及数据操作的关联性能。
4. 使用数据库探查器（如 SQL Server Profiler）观察数据库操作的数量以及持续时间。

请注意，在之前的步骤中可能已经使用了很多这种技术，用于确定缓存的目标数据。但是，在此阶段您对可以在将来容量规划计算中使用的更详细数字感兴趣。

此评估部分涉及了解读取与写入的比率。读取/写入工作负荷可能影响以后有关容量的决定。例如，写入百分比较高的工作负荷将触发更多的 .NET 垃圾收集。将在后面的步骤中对此进行讨论。

另一个因素是峰值负载期间读取和写入的频率。下表显示了在此阶段为示例购物车对象收集的示例数据。

此外，还应该对每个对象类型进行这种分析。不同的对象类型将具有不同的访问模式，并且在负载下每秒的最大读取和写入数也不相同。

若要了解缓存要求，您必须在任何给定的时间对缓存中每个类型的最大活动对象数进行估计。此估计涉及平衡对象插入的频率与这些对象的平均寿命。使用示例可以更好地了解此过程。

在 ASP.NET Web 应用程序示例中，操作数据可能显示存在 25000 个并发用户的高峰时段。每个用户都需要会话状态信息，因此是 25000 个缓存对象。但可以将这些对象的过期时间设置为 30 分钟。在高峰时段，操作数据可能显示 1 小时有 5000 个新用户，这意味着在 30 分钟的过期时间内 2500 个新用户可能会到达。此外，一些用户可能会关闭其浏览器，启动一个新会话。尽管他们是相同的用户，但他们现在使用不同的会话。因此，为了解决此问题，需要进行额外的补充。最后，应该计划在接下来的 6-12 个月中的任何预期发展。最终，计算缓存中活动对象的最大数量可能如下所示：

如果对输入（如过期时间）进行更改，则将更改峰值负载期间缓存中存在的未过期对象数。这仅仅是思考过程的一个示例。其他对象类型可能有不同的模式，并且参与计算的变量也不同。例如，如果某个共享的产品目录一整天都有效，则在这一天内缓存中的产品目录对象的最大数量应该为 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. 这些结果合计起来便可以获得缓存内存要求。

在此过程中，请注意每个对象大约有 0.5 KB 的开销，您应该将此添加到大小估计中。此外，缓存中还有其他需要内存的内部数据结构。区域、标记和通知所有这些都需要额外的内存进行管理。在我们的示例计算中，我们增加了总数的 5% 来计算这些内部结构，但对于您来说这个值可能大了或小了，具体情况取决于您使用这些缓存功能的程度。

此时，您应该考虑一个特定的 AppFabric 缓存功能，即高可用性的影响。该功能会在辅助服务器上创建缓存项目的副本。这意味着如果一个缓存服务器出现故障，辅助缓存服务器将接管并且数据不会丢失。如果您选择使用高可用性，则您必须使内存估计加倍。您还必须使用 Windows Server 2008 Enterprise Edition 或更高版本。请注意，高可用性功能是在命名缓存级别获得的。这意味着如果您想在同一群集中创建两个命名缓存，则不一定对每个缓存都使用高可用性。应用程序可以在具有高可用性的命名缓存中放置一些项目，将另一些项目放置在没有高可用性的缓存中。这样可以帮助您充分利用您的内存资源。因此了解有关高可用性的决定非常重要，因为它会使使用它的缓存的内存要求加倍。

作为一个示例，下面是我们评估同一应用程序中活动数据和参考数据要求的表格。根据您的方案，您可以选择在对象级别或应用程序级别进行此估计。我们刚刚向该示例中添加了多个列并且相应地对这些列进行了标记。

这些估计合计起来就构成了缓存群集的初始内存要求。在本例中，总计为 21.7 GB。有了这个估计，您现在就可以开始查看其他考虑事项，包括物理基础结构、SLA 要求以及 AppFabric 缓存配置设置。

了解您的物理基础结构以及资源的可用性非常重要。下面是一些常见的问题：

1. 您能够设置物理计算机或虚拟计算机吗？
2. 如果您有现成的硬件，那么计算机配置都有哪些内容（例如，8 GB RAM，双核）？
3. 缓存群集将与应用程序服务器位于相同的数据中心吗？
4. 网络功能都哪些？

如果您考虑使用虚拟机作为缓存服务器，则有很多考虑事项。例如，您必须考虑在同一物理计算机上拥有多个虚拟机所带来的影响。多个虚拟机可以共享同一网卡，但却增加了网络瓶颈的可能性。还可以在都是同一物理计算机上的虚拟机的主要缓存主机和辅助缓存主机之间设置高可用性。如果物理计算机出现故障，则不会留下任何数据副本。有关详细信息，请参阅在虚拟机中运行 AppFabric 缓存的指南。

对于现有的计算机，不建议这些规范。但是，对于大型缓存群集，我们曾经看到过 16GB RAM 双核的计算机工作出色。通常，计划正确的物理内存和网络负载数量是最重要的考虑事项。

对于物理计算机和虚拟机，您应该记住使用缓存的应用程序或 Web 服务器的缓存群集的位置。如果它们位于各自的数据中心，则确保这些数据中心之间的延迟不会对性能产生不利影响。在此阶段，可以尝试使用应用程序或 Web 服务器作为缓存服务器。尽管可以，但不支持这样做。首先，这些计算机上由服务（如 IIS） 带来的任何资源使用峰值都可能会影响缓存群集。其次，缓存服务假定自己位于专用服务器上并且可能会使用多于您指定的内存数量。

对于网络功能，您应该评估预期的网络负载并将其与您的基础结构进行比较。首先，您必须知道每个缓存服务器预期处理的数据数量以及网卡功能是否足够。如果不够，则可能需要更多缓存服务器。例如，考虑一个方案，其中平均缓存对象大小为 500.5 KB 并且在缓存群集上每秒有 240 个操作。如果使用一个缓存主机，则结果将如下所示：

如果每台计算机都拥有一个 1Gbps 的网卡，则最大吞吐量大约为 119 MBps。计算的值为 117.3 MBps 可能会压倒那台服务器。更有可能的是该网络将成为一个瓶颈。但是，如果在缓存群集中使用三台计算机，则平均分布缓存请求会导致每台服务器获得该负载的 1/3。

还要考虑访问缓存群集的应用程序服务器的网络利用率。如果它们与其他系统交换大量数据，则您应该考虑在应用程序服务器和缓存群集之间创建一个专用网络。这需要在每台应用程序服务器上安装一个附加的网卡，以便用于此目的。

最后一个网络考虑事项为网络是否可以沿着整个路径处理所需的负载。每台缓存服务器上只拥有一个 1Gbps 的网卡是不够的。网络上的交换机和其他位置也必须能够处理负载。使用操作来满足此要求。

决定最后一项配置之前，您还必须了解所有业务要求，包括性能和可靠性服务级别协议 (SLA)。在实际意义上，此步骤影响对缓存群集数量以及每个群集中缓存主机数量的决定。

例如，如果您拥有一个使用缓存群集的关键任务应用程序，则您可能希望将该缓存群集与其他优先级较低的应用程序隔离。这些优先级较低的应用程序可能会使用更多内存、网络或 CPU 资源，这将对关键任务应用程序产生不利影响。

下面是影响此决定的具体因素：

• 安全性保持在缓存群集级别。如果某个用户具有对缓存群集的访问权限，则该用户可能会访问缓存群集上的任何数据（假定该用户知道缓存名称以及要请求的密钥）。如果您需要对不同类型的数据进行不同的安全设置，则分离缓存群集可能比较有意义。有关详细信息，请参阅管理安全。
• 当内存达到高水印级别时会逐出未过期的项目。低估一个缓存所必需的内存数量可能会影响群集上的所有缓存。当由于内存压力而发生逐出时，即使只有一个缓存负责内存压力，也会在所有缓存上发生逐出。创建不可逐出的缓存可能会有所缓解，但必须谨慎执行此操作。有关详细信息，请参阅过期和逐出。
• 通过将缓存群集分离到某个点上可以更容易进行管理。您可能不希望为 100 个不同的缓存管理各自的群集。但让两个不同的大型缓存拥有各自的缓存群集可能非常有用，因为您可以分别管理、缩放和监视它们。

最后，某些要求可能涉及考虑延迟和吞吐量。若要获悉此决定，请参阅 Grid Dynamics 白皮书以便获得指导和测试结果。例如，您可以将缓存群集的吞吐量要求与 Grid Dynamics 白皮书中发布的测试结果进行对比。他们的研究可能指出，对于您的吞吐量目标来说，您拥有的服务器太少了。重要的是，要认识到该研究可能并不能与您的对象类型、对象大小以及物理和逻辑基础结构完全匹配，但它仍然可以为您提供经过证实的测试结果，这些结果可以帮助您作出明智的决定。

此过程的这个部分考虑 AppFabric 缓存的特定配置设置以及 AppFabric 缓存群集的体系结构。即使拥有所收集到的所有合适的经验和业务数据，但如果忽略这些 AppFabric 缓存设置，您仍然可能会制订错误的规划。

下表列出了各种 AppFabric 缓存功能以及关联的容量规划考虑事项。

毫无疑问，要了解的最重要的设置之一是每个缓存主机上的内存设置。可以使用 Windows PowerShell 命令 Get-CacheHostConfig 查看每个缓存主机上的默认内存设置。

注意
有关如何使用缓存 Windows PowerShell 命令的信息，请参阅常规缓存群集管理任务。

以下屏幕截图显示了 RAM 为 4 GB 的计算机上 Get-CacheHostConfig 的输出。

默认情况下，在给定服务器上为缓存预留的内存数量为总 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 或更少的内存。RAM 大于 16 GB 的计算机对于完整的垃圾收集循环可能经历更长的暂停。根据这种说话，对于每个缓存主机使用更多内存没有任何限制。大部分为只读的工作负荷可能无法经常经历完整的垃圾收集循环。您可以通过负载测试来更好地确定此内容。

在之前的示例中，我们为总缓存内存要求计算的估计为 21.7 GB。由于我们希望高可用性，因此必须至少有三台服务器。假定每台服务器都有 16 GB 的 RAM。在本例中，我们将每台服务器上的默认缓存大小设置保留为 8 GB。如前所述，LowWatermark (70%) 应该是每台服务器上可用的目标内存。这意味着每台服务器的估计内存为 5.6 GB。由于这些因素，下表显示了四台服务器将提供 22.4 GB 的缓存内存并且将满足 21.7 GB 的要求。

此外，请记住，您还可以使用 Grid Dynamics 白皮书中发布的结果来验证与吞吐量和延迟目标有关的这个估计。这些测试结果可能会使您稍微更改此初始估计，如通过添加额外的缓存服务器。此处比较重要的一点是使用像这样的可用资源来作出明智的决定。