爲什麼從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下載這麼久？

回答

相關問題