ビルドしなかったアプリケーションで、負荷がかかった状態でのパフォーマンスの問題を突き止めようとしていますが、の動作に非常に精通しています。
アーキテクチャは次のとおりです。モバイルアプリはASP.NETMVC3 Webサイトを呼び出して、表示するデータを取得します。ASP.NETサイトは、WCFクライアント（basicHttpBinding）を使用してサードパーティのSOAP APIを呼び出し、そのサードパーティの負荷を最小限に抑えるために、結果を可能な限りキャッシュします。
モバイルアプリからの負荷は、ピーク時に1秒あたり200以上のリクエストのオーダーであり、キャッシュ後、サードパーティへの1秒あたり20のSOAPリクエストのオーダーに変換されます。
通常は正常に実行されますが、APIへのすべてのリクエストに5秒かかるというカスケードの速度低下が発生します。その後、10 .. 15 .. 20 .. 25 .. 30 ..その時点でタイムアウトになります（WCFを設定します）クライアントのタイムアウトは30秒）。明らかにどこかにボトルネックがあり、30秒以内にリクエストを処理できなくなるまでキューがますます長くなります。
現在、サードパーティのAPIは私の制御不能ですが、1秒あたり20のリクエストで問題が発生することはないはずだと彼らは誓っています。そのため、私は自分の側でボトルネックの可能性を調査してきました。
私はServicePointManager.DefaultConnectionLimitとconnectionManagementに関するStackOverflowの質問を読みましたが、ソースを掘り下げると、問題はやや根本的なものだと思います。WCFクライアントオブジェクト（System.ServiceModel.ClientBase<T>「サービス参照の追加」によって自動生成される標準）がキャッシュに格納されているようです。したがって、複数の要求がASP.NETサイトに同時に着信すると、それらは単一のクライアントを共有します。物体。
いくつかのコンソールアプリを使った簡単な実験と、共有クライアントオブジェクトを使用して意図的に低速なWCFサービスを呼び出すために複数のスレッドを生成することから、複数のスレッドが単一のClientBaseを使用する場合、一度に1つの呼び出しのみが発生するようです。これは、たとえば1秒間に20回の呼び出しを行う必要があり、それぞれが完了するまでに50ミリ秒以上かかる場合のボトルネックを説明します。
誰かがこれが実際に当てはまることを確認できますか？
もしそうなら、そしてそれ自身のWCFクライアントオブジェクトを作成するすべてのリクエストに切り替えた場合ServicePointManager.DefaultConnectionLimit、クライアントオブジェクトを作成する前に、デフォルト（2だと思いますか？）よりも大きいものに変更する必要があります。同時接続の数？
（冗長な質問で申し訳ありませんが、情報が多すぎる方が少なすぎるよりはましだと思いました）