7

私の Azure クラウド サービスは、.Net ストレージ ライブラリ (1.7) を使用して BLOB の読み取りと書き込みを行います。BLOB は、サービスと同じデータ センターにあります。私の最初のコンテナーでは、操作は高速です (10 ミリ秒のオーダー)。私の 2 番目のコンテナーでは、それらは非常に低速です (通常は約 2 秒または 14 秒で、その間にはほとんどありません)。どちらも CloudBlob.DownloadToStream() を使用してデータを MemoryStream に転送しています。通常、ファイル サイズは 100kB 未満です。

ここで、上記のすべてを実証できる適切なテストをセットアップしていないことを認めます。ログ ファイルを参照しているだけなので、ブロブへのアクセス方法に微妙な違いがある可能性があります。これが事実であることが判明した場合はお詫び申し上げます。

とにかく、これら2つのコンテナの唯一の関連する違いは次のようです:

  • 高速のコンテナは頻繁にアクセスされ (1 日あたり数万のリクエスト)、低速のコンテナはほとんどアクセスされません (おそらく 1 日あたり 200 リクエスト)。
  • 通常、高速コンテナーには、その後すぐにフェッチされるアイテムが格納されます。遅いコンテナーは、数日前に保存された可能性のあるものをロードしていることがよくあります。

質問:アクセス頻度の低い BLOB のパフォーマンスに影響を与える要因は何ですか? 高速化するにはどうすればよいですか?

(Azure BLOB ストレージがどのように実装されているかはわかりませんが、上記に基づいて、データはストレージ アレイに保存され、動的にスケーリングする VM のコレクションを介してアクセスされると推測します。VM のそれぞれはインメモリを実装します。したがって、Azure が VM をスピンアップする必要があることを検出すると、~14 秒の遅延が発生します.~2 秒の遅延は、VM が利用可能であるが、物理ディスク上のデータを探し出す必要がある場合に発生します (かなり遅いようです)。 10 ミリ秒の遅延は、アイテムがメモリ内キャッシュなどに格納されるときに発生します。)

4

1 に答える 1

8

Windows Azure Storage は、説明されているように (キャッシュ VM の数が増加して) 設計されていないため、Azure Storage サーバー側で一部のデータがキャッシュされ、他のデータがキャッシュされないという影響はありません。概要については、 Windows Azure ストレージ アーキテクチャの概要を参照してください。詳細については、SOSP ペーパー - Windows Azure ストレージ: 強力な一貫性を備えた高可用性クラウド ストレージ サービスを参照してください。

BLOB 要求が遅い理由を判断するには、最初に、パフォーマンスの低下がサーバー側にあるのかクライアント側にあるのかを判断する必要があります。さいわい、Azure Storage では Storage Analytics ( Windows Azure Storage Logging: Using Logs to Track Storage Request ) を使用してこれを簡単に行うことができます。エンド ツー エンドの待機時間とサーバーの待機時間を比較するだけです。次の 2 つのいずれかが表示されると思います。

  1. 低 E2E と低サーバー。これは、クライアントからのリクエストの送信が遅れている (つまり、ワーカー スレッドが不足している) か、ログが正しくないデータを提供していることを示しています。
  2. 高 E2E と低サーバー。これは、リクエストの処理におけるクライアント側の問題を示しています (レスポンスを処理するための十分なワーカー スレッドがない、メモリ ストリームの処理が遅いなど)。
于 2013-09-03T16:13:21.290 に答える