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