Question

在我的Azure网络角色OnStart()中，我需要部署一个角色所依赖的巨大的非托管程序。该程序先前已压缩为400兆字节的.zip存档，每个文件分为20兆字节，并上传到blob存储容器。该计划不会改变 - 一旦上传，它可以保持这种方式多年。

我的代码执行以下操作：

CloudBlobContainer container = ... ;
String localPath = ...;
using( FileStream writeStream = new FileStream(
             localPath, FileMode.OpenOrCreate, FileAccess.Write ) )
{
     for( int i = 0; i < blobNames.Size(); i++ ) {
         String blobName = blobNames[i];
         container.GetBlobReference( blobName ).DownloadToStream( writeStream );
     }
     writeStream.Close();
}

它只是打开一个文件，然后逐个将部分写入其中。效果很好，除了从单核（超小）实例运行大约需要4分钟。这意味着平均下载速度约为每秒1.7兆字节。

这令我担心 - 看起来太慢了。它应该这么慢吗？我究竟做错了什么？我可以做些什么来解决我的部署问题？

Answer 1

除了理查德·阿斯特伯里（Richard Astbury）所说的内容之外：超小型实例的带宽非常小，即便是小型的。你会看到约。额外的5Mbps，大约小型100Mbps（小型到超大型，每个核心大约需要100Mbps）。

Answer 2

超小型实例的IO性能有限。您是否尝试过中型实例进行比较？

Answer 3

在我过去做过的一些临时测试中，我发现下载1个大文件和尝试并行下载N个较小文件之间没有明显区别。事实证明，无论如何，NIC上的带宽通常都是限制因素，而大文件就像许多较小的文件一样容易使其饱和。反之亦然，顺便说一句。您可以通过并行上传而不是一次上传来获益。

我提到这个的原因是，你似乎应该在这里使用1个大型zip文件，例如Bootstrapper。这将是您下载，解压缩和可能运行的一行代码。更好的是，除非你强迫它，否则它不会在重启时多次执行。

正如其他人已经恰当地提到的那样，XS实例上的NIC带宽远远小于S实例。通过稍微提高VM大小，您将看到更快的下载速度。

为什么从Azure blob下载这么长时间？

3 个答案: