我的Azure云服务使用.Net存储库(1.7)读取和写入blob. blob与服务位于同一数据中心.在我的第一个容器中,操作很快(10ms的顺序).在我的第二个容器中,它们非常慢(通常大约2s或14s,介于两者之间
现在我承认我没有设置一个适当的测试来展示上述所有内容 – 我只是通过我的日志文件,因此我访问blob的方式可能会有一些细微差别.如果情况确实如此,请道歉.
无论如何,这两个容器之间唯一的相关区别似乎是：
>经常访问快速容器(每天数万个请求),慢速容器很少(每天可能有200个请求).
>快速容器通常存储之后很快获取的项目.慢速容器通常会加载几天前可能存储的东西.
问题：哪些因素会影响不经常访问的blob的blob性能？我该怎么做才能让它更快？
(我不知道如何实现Azure blob存储,但基于上面我猜测数据会被保存到存储阵列中并通过动态扩展的VM集合进行访问,每个VM都在内存中实现因此,当Azure发现需要启动虚拟机时,会出现~14s的延迟.当虚拟机可用时会发生~2s延迟,但它需要搜索物理磁盘上的数据(似乎相当慢),当项目存储在内存缓存中或类似的东西时,会发生10ms延迟.)
Windows Azure存储的架构不是您所描述的(缓存虚拟机数量不断增加),因此缓存的某些数据和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)简化了这一过程 – 只需比较端到端延迟和服务器延迟.我怀疑你会看到两件事之一：
>低E2E和低服务器.这表示请求从客户端发送延迟(即没有足够的工作线程),或者您的日志记录提供的数据不正确.>高E2E和低服务器.这将指示客户端处理请求时的问题(没有足够的工作线程来处理响应,缓慢处理内存流等).