Azure blob存储流性能问题

Question

直到今天，我的应用程序还在处理本地zip文件，这意味着我在应用程序中使用了一个直接返回的new FileStream()，以及位于SDD/Network驱动器路径上的本地zip文件(压缩文件可以是数百GB)。

我将应用程序配置为使用Azure Blob存储，这意味着现在返回的每个FileStream都是Azure Blob方法：

GetBlobStreamAsync(ContainerName, BlobName).ConfigureAwait(false).GetAwaiter().GetResult()

我将一些zip文件上传到blob存储中的容器中，并将应用程序中的连接字符串设置为使用该存储帐户。

应用程序是在位于Azure Storage相同区域的虚拟windows机器上部署和运行的。

注意:这是一个私有云网络。

当应用程序在Azure blob存储上传输zip文件时，性能似乎下降了至少8-9倍(数百GB存在问题)。

速度比较是本地C:驱动器与应用程序运行在相同区域的Azure存储帐户上运行的相同windows虚拟机上的驱动器。

注: NW带宽-在蔚蓝上的VM上是50 GB。

我尝试过的解决方案：

performance

• .Net

• Azure Blob高级性能存储-没有改进blob核心-性能增强的优势(我们使用.Net框架，所以这是Azure blob存储中的irrelevant).

• Network文件系统(NFS) 3.0性能考虑事项)(不使用私有云)。blob数据的

• 热、Cool和归档访问层--默认是热的，所以我们已经用no improvements.

尝试了这个场景。

我想尝试的解决方案：

作为缓存solution

• .Net框架配置共享存储的

1. Azure文件-列出几个快速配置设置，您可以使用这些设置来实现显着的性能improvements

问题：

有人对我如何在Azure Storage前优化流有任何建议吗？

Answer 1

Azure Files (共享)或Storage服务很可能不适合在此场景中使用。有两种可能的途径：

1. 将单个文件分解为多个文件，并利用Storage服务，该服务比Azure文件处理吞吐量更好。对于用户文档(PDF、Word、Excel等)典型的小文件(Er)，Azure文件的性能更好，
2. 切换到了专门为大型数据传输专门设计的服务，如果将单个文件分解成多个blobs不是一种选择。

每个备选方案的建议将在很大程度上取决于系统的实施细节、要求和制约因素。