为什么不经常访问的Azure blob存储缓慢？

Question

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

现在我承认我没有设置适当的测试来展示上述所有内容 - 我只是按照我的日志文件，因此我访问blob的方式可能会有一些细微差别。如果情况确实如此，请道歉。

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

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

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

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

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 Storage通过Storage Analytics（Windows Azure Storage Logging: Using Logs to Track Storage Requests）简化了这一过程 - 只需比较端到端延迟和服务器延迟。我怀疑你会看到两件事之一：

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