为什么从Azure blob下载这么久？

在我的Azure web角色OnStart()我需要部署角色依赖的巨大的非托管程序。该程序先前被压缩成一个400兆字节的.zip压缩文件，分割成20 MB的文件并上传到一个Blob存储容器。该程序不会改变 - 一旦上传，它可以保持这种方式多年。为什么从Azure 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兆字节。

这让我很担心 - 它似乎太慢了。它应该如此缓慢？我究竟做错了什么？我能做些什么来解决部署中的问题？

来源

2011-09-08 sharptooth

显而易见的一个检查：确保您的Web角色和您的存储位于相同的关联组。否则，你可能会发现一个Web角色（比如说）都柏林正试图从新加坡（比如说）获取数据。 –

添加到Richard Astbury所说的内容：一个额外的小实例只有一小部分带宽，甚至一个小的带给你。你会看到约。 5Mbps的超小型，约。一个小的100Mbps（对于小到特大，你将得到每个核心约100Mbps）。

来源

2011-09-08 14:30:19

它甚至比你正在放的更好。小有100Mbps的保证带宽。根据你的邻居虚拟机在做什么，你可以很容易地获得250Mbps +。您保留的芯越多，它就越好。 :) – dunnry

超小型实例IO性能有限。你有没有试过用于比较中型实例？

来源

2011-09-08 12:27:59

+1 - 即使是Small也具有显着更高的带宽。 –

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

我提到这个的原因是，你应该在这里使用1个大的zip文件和类似Bootstrapper的东西。这将是1行代码，供您下载，解压并可能运行。更好的是，除非你强制重启，否则它不会在重启时重复多次。

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

来源

2011-09-08 16:01:32 dunnry

为什么从Azure blob下载这么久？

回答

相关问题