为什么不经常访问的 Azure Blob 存储速度很慢？

Question

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

现在我承认我还没有设置适当的测试来证明以上所有内容 - 我只是查看我的日志文件，因此我访问 blob 的方式可能存在一些细微差别。如果结果是这样，我们深表歉意。

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

• 快速容器被频繁访问（每天数万个请求），而慢速容器则很少被访问（可能每天 200 个请求）。
• 快速容器通常存储之后很快获取的项目。缓慢的容器通常会加载几天前可能存储的东西。

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

（我不知道 Azure blob 存储是如何实现的，但基于以上我猜测数据是保存到存储阵列中并通过动态扩展的 VM 集合访问的，每个 VM 都实现内存中的 blob 缓存。因此，当 Azure 发现它需要启动 VM 时会发生约 14 秒的延迟。当 VM 可用时会发生约 2 秒的延迟，但它需要在物理磁盘上搜索数据（似乎慢），当项目存储在内存缓存或类似的东西时会发生 10 毫秒的延迟。）

Answer 1

Windows Azure 存储的架构并非您所描述的那样（随着缓存 VM 的数量不断增加），因此在 Azure 存储服务器端缓存某些数据和未缓存其他数据不会产生影响。请参阅Windows Azure Storage Architecture Overview 以获得良好的概述，或查看SOSP Paper - Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency 以获得更深入的了解。

要确定为什么您的 blob 请求较慢，首先要做的是确定性能缓慢是服务器端还是客户端。幸运的是，Azure 存储通过存储分析 (Windows Azure Storage Logging: Using Logs to Track Storage Requests) 使这变得简单 - 只需比较端到端延迟和服务器延迟即可。我怀疑您会看到以下两种情况之一：

1. 低端 E2E 和低端服务器。这表明请求从客户端发送延迟（即没有足够的工作线程），或者您的日志记录提供的数据不正确。
2. 高 E2E 和低服务器。这表明客户端在处理请求时出现问题（没有足够的工作线程来处理响应、内存流处理速度慢等）。