在我们仍在开发的项目中，我们注意到访问ASP.NET Web API服务时出现突然延迟。使用了很棒的Mini Profiler，我们确认这些延迟是在删除与Azure数据缓存（预览）服务的连接并且必须重新建立时引起的。此过程大约需要3.3秒。重新连接后，从缓存中获取对象需要1.4毫秒。
当我将maxConnectionsToServer从1增加到20时，我注意到了另一件事。如果我没有向Web API请求1或2分钟（通常在连接断开时），然后开始拨打电话，接下来的20个请求会延迟3.3秒，这就是连接方式我认为汇集工作（从池中绕过连接）。
Web API和缓存服务都托管在美国东部地区，我们已禁用本地缓存，禁用SSL，启用自动发现。
所以，我想知道我们的配置是否有问题，或者这是因为Azure Cache仍在预览中？
任何信息都将被重视。
谢谢！
答案 0 :(得分：0)
听起来您的共享缓存由于不活动而被卸载。测试此方法的一种方法是向现有服务（如果可用）添加角色内缓存，并将缓存使用量交换到此新缓存。角色缓存的描述为here。
将缓存移出共享产品后，等待必要的1-2分钟以暂停超时，然后重试连接，不应出现延迟。
假设您希望在隔离问题后坚持使用共享缓存选项，我所知道的唯一当前解决方法是运行后台任务，该任务将定期ping缓存以使其保持活动状态。
如果您正在运行完整的Web角色，则可以在应用程序启动时启动后台任务 如果您通过移动服务进行部署，那么您可以运行＆＃34; ping＆＃34;通过预定的工作。您可能遇到的唯一问题是，预定作业的最短时间是1分钟，这可能不足以使您的缓存在100％的时间内保持活动状态。
答案 1 :(得分：0)
我看到的任何内容都没有指出你本身做错了什么。可能是Azure真正遇到了使缓存连接快速启动和运行的问题。根据几个最佳实践文档和MSDN帖子，您希望增加与缓存的连接数，以允许故障转移到活动连接，您已经有效地完成了配置更改。
尝试确保您的缓存访问者是一个静态对象（另一个MSDN推荐），这可能是一个很长的镜头，但考虑使用Sliding Window选项对象到期，看看是否这不仅告诉对象存储的倒计时重置，但也会提示缓存服务重置连接。