-1

最大 32 MB の大量のデータ チャンクがアップロードされる可能性のある MVC アプリが関係する状況があります。各チャンクがアップロードされた後、クライアント ブラウザが次のチャンクをアップロードする前に、チャンクを処理して応答を送信する必要があります。

最終的には、データとその処理結果を Azure ストレージに保存する必要があります。データ処理は CPU を集中的に使用します。この量のデータの転送にはかなりの時間がかかることを考えると、データがマシン間で行う必要がある移動の回数を減らし、Web サーバー スレッドから作業を移動することを検討しています。

現在、これは、単一のワーカー スレッドによって消費されるジョブをキューに入れることによって行われます。

ただし、このプロセスは、実行可能ファイルを重い作業に実行するようにアップグレードする必要があります。

処理の最後に、データは Azure Blob Storage にアップロードされます。そのため、データは、応答が送信される前にネットワーク経由で 2 回転送される必要があります (AFAIK)。理想的ではありません。

Azure でさまざまなキュー オプションがあることは認識していますが、状況を改善するどころか悪化させてしまうのではないかと心配しています。この問題をやり過ぎたくはありませんが、プロセス全体をできるだけ迅速かつ効率的に実行する必要があります。

a) クラウド サービスの Azure Web ロールと Worker ロールの間でどのようなデータ転送速度を期待できますか?

b) データを Azure ストレージに直接転送し、再度転送せずにそこで処理する方法はありますか?

c) worker ロールと web ロールは実際に同じマシンで実行できますか?

d) Web アプリ内から .​​exe を実行することはできますか? パスを取得するには？

4

1 に答える 1

1

次のようなワークフローをお勧めします。

  • クライアントはデータを BLOB ストレージに直接アップロードします (このガイドに従って小さなチャンクで)
  • アップロードが完了すると、クライアントは Web サービスに通知し、Web サービスはサービス バス キュー (jobQueue) にメッセージを投稿します。メッセージには、一意のセッション識別子と、アップロードされたデータの BLOB URL が含まれています。次に、Web サービスは、指定された sessionId を持つ応答メッセージをブロックし、別のサービス バス キュー (replyQueue) でリッスンします。
  • マルチスレッドの Worker ロールは、サービス バスの jobQueue をロング ポーリングし、メッセージを受信するたびに処理されます。処理されたデータはどこかに保存されます。その後、応答メッセージが作成され、sessionId が設定された replyQueue にポストされます。
  • その後、Web サービスは (指定された sessionId に対する) 応答メッセージを受信し、クライアントに結果を返すことができます。

これと同様のアーキテクチャを使用すると、より大きなマシンを worker ロールに使用して垂直方向にスケーリングしたり、worker ロールのインスタンスを追加して水平方向にスケーリングしたりできます。

プロセスの回復力をもう少し高めるには、クライアントがアップロードされたデータを Web サービスに通知した直後にクライアントに戻り、データが処理されたときに Signalr を使用してワーカー ロールからクライアントに直接通知することができます。 .

あなたの質問の他の部分に対する私の答えは次のとおりです。

a) 役割間のデータ転送速度の保証がどのようなものかわかりません

b) はい、データを Blob Storage に直接転送してから、Blob から Worker ロールに転送できます

c) Web ロールでワーカー ロール スタイルの処理を実行し、WebRole.OnRoleStart および WebRole.Run からワーカー ロール スタイル コードを呼び出すことができます。その後、このコードをスケーリングする必要がある場合は、専用のワーカー ロールに移動できます。

于 2013-07-08T22:37:12.273 に答える