4

在我的 Azure Web 角色中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 兆字节。

这让我很担心——它似乎太慢了。应该这么慢吗？我究竟做错了什么？我可以做些什么来解决我的部署问题？

4

3 回答 3

6

补充一下 Richard Astbury 所说的：一个 Extra Small 实例的带宽非常小，即使是 Small 也能提供给您。你会看到大约。5Mbps 超小号，大约。Small 100Mbps（对于 Small 到 Extra Large，每个内核将获得大约 100Mbps）。

于 2011-09-08T14:30:19.843 回答
3

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

于 2011-09-08T12:27:59.673 回答
0

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

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

正如其他人已经恰当地提到的那样，XS 实例上的 NIC 带宽甚至比 S 实例要小得多。通过稍微增加 VM 大小，您将看到更快的下载。

于 2011-09-08T16:01:32.180 回答