我正在为危机情况做一些计划（上次我们从每天 4k 访问者增加到 130 万），我注意到 Azure AppFabric 缓存的低端有一些相当低的同时连接限制
例如 128Mb 和 256Mb 缓存 =10 个并发连接。
我正在为 webrole 会话状态使用缓存 - 但仅在非常有限的情况下将内容放入其中（实时站点上个月达到 0.03MB 的峰值！）我如何计算最大连接数 - 是那将等于我指向它的服务器数量吗？ CPU的数量？
我还没有尝试过，但扩展缓存看起来可能是 24 小时操作？？？
在一些指导方针帮助我选择和初始缓存大小并合理扩展之后。
【问题讨论】：
您拥有的缓存连接数基本上就是您拥有的DataCacheFactory 实例数。出于这个原因，最好的做法是尽可能少地使用这些实例。您还需要确保当任何已初始化 DataCacheFactory 的 Azure 实例在停止时应处置该实例，这有助于清除它已打开到服务的连接。
但是您说您将缓存用作会话提供程序。这将为角色的每个实例创建自己的DataCacheFactory。所以基本上每个角色一个连接。话虽如此，会话提供者在清理不使用的连接方面似乎有些松懈，因此最好过度配置连接数。
您需要注意的另一件事是缓存的“每小时事务数”限制。如果对页面的每个请求都需要访问会话信息，那么这就是您在一小时内可以处理的页面请求数。
调整缓存大小实际上非常快，通常只需要一分钟左右。但是您每 24 小时只能更改一次。因此，如果您增加了负载，您可以使缓存更大，但如果负载对于即使增加的缓存来说也太大了，那么您需要等待 24 小时才能再次更改它。因此，您最好在第一次调整缓存大小时将缓存设置得更大，然后在第二天将其缩小。
编辑：
虽然此信息在撰写本文时是正确的，但 SDK 的 2011 年 11 月 (1.6) 更新引入了缓存连接池，如果您未通过代码配置缓存，则默认情况下会启用缓存连接池。这使得只有一个静态DataCacheFactory 变得不那么重要，这意味着如果您想对会话和应用程序数据使用相同的连接信息，这可能都是一个连接。更多details can be found on MSDN。
【讨论】：