4

私の Azure Web ロールOnStart()では、ロールが依存する巨大な管理されていないプログラムをデプロイする必要があります。このプログラムは、事前に 400 メガバイトの .zip アーカイブに圧縮されており、それぞれ 20 メガバイトのファイルに分割され、ブロブ ストレージ コンテナーにアップロードされています。そのプログラムは変更されません。一度アップロードされると、何年もそのままの状態を保つことができます。

私のコードは次のことを行います：

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();
}

ファイルを開き、パーツを 1 つずつ書き込みます。単一のコア (非常に小さい) インスタンスから実行すると約 4 分かかることを除いて、うまく機能します。つまり、平均ダウンロード速度は 1 秒あたり約 1.7 メガバイトです。

これは私を心配しています-遅すぎるようです。そんなにゆっくりするべきですか？私は何を間違っていますか？展開に関する問題を解決するために、代わりに何ができますか?

4

3 に答える 3

6

Richard Asbury の発言に加えて、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 つずつアップロードするのではなく、並行してアップロードすることでメリットが得られます。

これについて言及する理由は、ここで 1 つの大きな zip ファイルとBootstrapperのようなものを使用する必要があるように思われるからです。これは、ダウンロードして解凍し、場合によっては実行する 1 行のコードになります。さらに良いことに、強制しない限り、再起動時に複数回実行されることはありません.

他の人が適切に述べているように、XS インスタンスの NIC 帯域幅は S インスタンスよりもはるかに小さいです。VM のサイズを少し大きくすることで、ダウンロードが大幅に高速化されます。

于 2011-09-08T16:01:32.180 に答える