4

コード：

class Controller
{
    Some Action Method()
    {
        ...
        ...
        new Thread(() =>
        {
            //WCF cal- wil execute for around 10 secs.
            var result = service.SubmitAndCreateApp(params);
            sessionModel.IsAppCreated = result; 
        }).Start();

        return jsonresult;
        }
}

WCF 呼び出しに時間がかかりすぎるため、スレッド プールを使用して枯渇させたくありません。

ここでは、クライアントの要求ごとにスレッドが作成されていることが明らかです。.Net 4.0 (VS 2010) でこれを達成するために、これまたは他の代替方法を最適化するにはどうすればよいですか?

4

4 に答える 4

5

簡単に言えば、いいえ、これをしないでください。

そうは言っても、ASP.Net の Task Parallel Library (TPL) を見ると、まさに目的を達成できます。

クイック検索でこの投稿が得られました。私はちらっと見ただけですが、的を得ているようです。

http://vizagtechie.blogspot.com/2013/03/parallel-programming-in-aspnet-mvc.html

于 2013-10-03T18:14:12.710 に答える
4

いいえ、サーバーは完全に DDOS 化されます。少なくとも、手動で独自のスレッドを作成するのではなく、スレッド プールからスレッドを要求してください。スレッド プールが不足している場合は、いずれかが使用可能になるまで待機します。サーバーの残りの部分は引き続き機能します。もちろん、走行距離は多くの要因によって異なる場合があります。

于 2013-10-03T18:09:14.883 に答える
0

コードは への呼び出しを完了し、WCF への呼び出しが完了する前にSome Action Method()戻ることができます(実際には、これが 100% の確率で発生すると仮定します)。それを実現したい場合は、コードは問題ありません。ただし、JSON の結果に対してサービス呼び出しからの応答が必要な場合、コードは非常に壊れています。jsonresultservice.SubmitAndCreateApp(params)sessionModel.IsAppCreated

これを修正するには、作成したスレッドが終了するまでアクション メソッドのスレッドをブロックする必要があります。この事実と、基になる WCF 通信チャネルが既に独自のスレッドを作成して、WCF サービス呼び出しからの応答を待機するという事実 (同期 WCF 呼び出しは、応答が受信されるまでブロックする非同期呼び出しにすぎません) により、新しいスレッドの作成が行われます。無意味。

于 2013-10-03T18:40:38.747 に答える