2

この 1 年間、私たちは会社の既存のサービス レイヤーを呼び出す新しい Web アプリに取り組んできました。

サービス指向のすべての呼び出しを独自のサービス レイヤー (Web サービス レイヤーと呼びます) にまとめることにしました。これにより、使用するサービスの詳細 (新しい API に移行します)将来のある時点で) は、Web レイヤー自体から隠されます。

また、ほとんどの Web サービス レイヤー メソッドが を返すことも決定しましたTask<T>。

現状では、私たちが呼び出す基礎となるサービスは非同期ではないため、大量のユーザーがいる場合、Web サービス レイヤーが使用可能なスレッドを使い果たし、問題が発生するという懸念があります。

Task<T>返品の決定がサイトにどのように影響するか、および返品タイプの変更を検討する必要があるかどうかをさらに理解するために、何らかの方法で情報を探しています.

ある時点で VS2012 に移行する予定ですが、現在は VS2010 を使用しており、 and は使用していませasyncんawait。

4

1 に答える 1

1

現状では、私たちが呼び出す基礎となるサービスは非同期ではないため、大量のユーザーがいる場合、Web サービス レイヤーが使用可能なスレッドを使い果たし、問題が発生するという懸念があります。

はい、それはあなたが気にするべきことです。実際の非同期メソッドがある場合にのみ、これを行うことをお勧めします。しかし、ブロックしている同期メソッドを非同期 API に単純にラップするのは、消費するコードから同期メソッドを直接呼び出すよりも悪いことです。ASP.NET アプリケーションでは、基になる API が I/O Completion Ports に依存している場合にのみ、非同期呼び出しの利点を得ることができます。そうでなければ、それは単なるリソースの無駄です。

これを行うことができる唯一の有用なシナリオは、メソッドを順次ではなく並行して呼び出すことができる場合です。これは、異なるメソッドがそれらの間に接続されていない場合にのみ可能です。この場合、非同期タスクで同期メソッドを実際にラップできます。

于 2013-02-18T15:11:40.507 に答える