Performance 为什么很少访问的Azure blob存储速度慢？

我的Azure云服务使用.Net存储库（1.7）读取和写入Blob。BLOB与服务位于同一数据中心。在我的第一个容器中，操作速度很快（大约10毫秒）。在我的第二个容器中，它们非常慢（通常大约2秒或14秒，中间不多）。两者都使用CloudBlob.DownloadToStream（）将数据传输到MemoryStream中。文件大小通常小于100kB

现在我承认我还没有设置一个合适的测试来演示上述所有内容——我只是查看我的日志文件，所以我访问blob的方式可能会有一些细微的差别。如果事实证明是这样，我会道歉

无论如何，这两个容器之间唯一相关的区别似乎是：

• 快速容器经常被访问（每天有上万个请求），而慢速容器很少被访问（每天可能有200个请求）
• fast容器通常存储不久后提取的项目。缓慢的容器经常装载可能在几天前储存的东西

问题：哪些因素会影响不常访问的blob的blob性能？我能做些什么使它更快

---

（我不知道Azure blob存储是如何实现的，但基于上述情况，我猜测数据会保存到存储阵列中，并通过动态缩放的虚拟机集合进行访问，每个虚拟机都实现了blob的内存缓存。因此，当Azure发现需要启动虚拟机时，会出现~14s延迟。当n虚拟机是可用的，但它需要查找物理磁盘上的数据（看起来相当慢），当项目存储在内存缓存或类似的东西中时，会出现10毫秒的延迟。）

Windows Azure存储的体系结构不符合您的描述（缓存虚拟机数量不断增加），因此在Azure存储服务器端缓存某些数据和未缓存其他数据不会产生任何影响。请参阅，以获得良好的概述或更深入的了解

要确定blob请求较慢的原因，首先要确定性能较慢的是服务器端还是客户端。幸运的是，Azure Storage通过Storage Analytics（）简化了这一过程-只需比较端到端延迟和服务器延迟。我想您会看到以下两种情况之一：

低E2E和低服务器。这表明从客户端发送的请求被延迟（即，没有足够的工作线程），或者您的日志记录提供了不正确的数据

高E2E和低服务器。这表明客户端在处理请求时出现问题（没有足够的工作线程来处理响应，内存流处理缓慢，等等）

---

日志显示E2E低（端到端，包括网络时间）和服务器时间低。因此，我需要更仔细地查看我的代码。我使用了smarx的工具（）在不需要构建新程序的情况下打开日志记录。Oliver，您可能还需要查看存储客户机库的新2.1版本，它添加了SCL本身的跟踪输出-。我在调用DownloadToStream（）时放了一个秒表我仍然看到客户端的缓慢。我注意到，缓慢的调用是在刚启动的流程中进行的。这会造成影响吗？不幸的是，我无法使用新的存储客户端库，因为所讨论的流程由于依赖关系而卡在.Net 2.0中，而新库需要.Net 4。如果存储分析显示E2E时间较短，则b但是您的代码显示调用DownloadToStream的延迟，那么延迟必须在尝试通过网络发送请求的客户端上。通常，当进程中没有足够的工作线程时，我会看到这种情况。另一个常见原因是没有为ServicePointManager.DefaultConnectionLimit设置足够高的值。请尝试以下操作：1.设置ServicePointManager.DefaultConnectionLimit设置为12或更高。2.将minworker线程设置为12或更高。在2015年，这里也是一样。比如2秒或14秒，有时降到45秒。但我与任何东西都没有关联。