15

データベースを必要とせず、このアプリケーションの外部への IO がないアプリケーションで、Azure App Service と .NET Core 3.1 で長時間実行される計算に適したソリューションはどれですか? 計算作業です。

具体的には、以下は信頼性が低く、解決策が必要です。

[Route("service")]
[HttpPost]
public Outbound Post(Inbound inbound)
{
    Debug.Assert(inbound.Message.Equals("Hello server."));
    Outbound outbound = new Outbound();
    long Billion = 1000000000;
    for (long i = 0; i < 33 * Billion; i++) // 230 seconds
        ;
    outbound.Message = String.Format("The server processed inbound object.");
    return outbound;
}

これにより、null オブジェクトが に返されることがありますHttpClient(表示されていません)。より小さなワークロードは常に成功します。たとえば、30 億回の反復は常に成功します。2,400億が必要です

2020 年には、.NET Core を使用した Azure App Service の合理的な目標は、8 つの子スレッドを使用して親スレッドの数を 2,400 億にすることであると思います。これにより、各子は 300 億になり、親は 8 M バイトを分割します。インバウンド オブジェクトを、各子にインバウンドする小さなオブジェクトに変換します。各子は 1M バイトのインバウンドを受け取り、親に 1M バイトのアウトバウンドを返します。親は、結果を 8 M バイトのアウトバウンドに再アセンブルします。

明らかに、経過時間は 12.5%、つまり 1/8、つまりシングル スレッドの実装に必要な時間の 1/8 になります。オブジェクトを切断して再組み立てする時間は、計算時間に比べてわずかです。オブジェクトを送信する時間は計算時間に比べて非常に短いと想定しているため、12.5% の期待値はおおよそ正確です。

4つか8つのコアを手に入れることができれば、それは良いことです. コアのサイクルの 50% を提供するスレッドを取得できる場合、8 または 16 スレッドが必要になる可能性があります。各スレッドがコアのサイクルの 33% を提供する場合、12 または 24 のスレッドが必要になります。

クラスを検討してBackgroundServiceいますが、これが正しいアプローチであるという確認を探しています。マイクロソフトは言う...

BackgroundService is a base class for implementing a long running IHostedService.

明らかに、何かが長時間実行されている場合は、経由で複数のコアを使用してより早く終了させる方がよいでしょうがSystem.Threading、このドキュメントSystem.Threadingでは、経由でタスクを開始するコンテキストでのみ言及しているようSystem.Threading.Timerです。私のコード例は、アプリケーションにタイマーが必要ないことを示しています。HTTP POST は、作業を行う機会として機能します。通常System.Threading.Thread、複数のコアを使用するために複数のオブジェクトをインスタンス化するために使用します。複数のコアについて言及されていないことは、時間がかかる作業のソリューションのコンテキストでは明らかな省略であると思いますが、Azure App Service がこの問題に対処しない何らかの理由がある可能性があります。おそらく、チュートリアルやドキュメントで見つけることができないだけです。

タスクの開始は、図示された HTTP POST コントローラーです。最長のジョブに 10 分かかるとします。HTTP クライアント (図示されていません) は、タイムアウト制限を 10 分 (600 秒) よりもはるかに長い 1000 秒に設定して、安全マージンを確保します。HttpClient.Timeout該当するプロパティです。現時点では、HTTP タイムアウトが実際の制限であると推測しています。ユーザーが 9 分間待機してエラー メッセージが表示されるような、何らかの拘束力のない (偽の制限) ではありません。実際のバインド制限は、「このタイムアウトでは成功しただろう」と言える制限です。HTTP タイムアウトが実際のバインド制限ではなく、システムを制約する何かがある場合は、代わりに 3 つの POST メソッドを使用するように HTTP コントローラーを調整できます。したがって、POST1 は受信オブジェクトでタスクを開始することを意味します。POST2 は、完了したら教えてくださいという意味です。POST3 は、アウトバウンド オブジェクトを渡すことを意味します。

データベースを必要とせず、このアプリケーションの外部への IO がないアプリケーションで、Azure App Service と .NET Core 3.1 で長時間実行される計算に適したソリューションはどれですか? 計算作業です。

4

5 に答える 5

0

実行する必要がある実際の作業は、何もしないループを繰り返すこと以外の何かだと思います。そのため、並列化の可能性に関しては、今のところあまり役に立ちません。作業は CPU 集中型ですか、それとも IO 関連ですか?

Azure App Service で長時間実行される作業に関しては、オプションの 1 つはWeb ジョブを使用することです。考えられる解決策は、計算の要求をキュー (ストレージ キューまたはAzure メッセージ バス キュー) にポストすることです。次に、Web ジョブはこれらのメッセージを処理し、場合によっては、リクエスターが結果を処理するために使用できる別のキューに新しいメッセージを配置します。

処理に必要な時間が 10 分未満であることが保証されている場合は、Web ジョブをQueue Triggered Azure Functionに置き換えることができます。これは、優れたスケーリングの可能性を備えた Azure 上のサーバーレス サービスです。

もう 1 つのオプションは、Service WorkerまたはIHostingServiceのインスタンスを使用して、そこでキュー処理を行うことです。

于 2020-08-12T11:10:07.927 に答える