2

これはよくある質問/問題のようですが、提案された解決策をいくつか確認したにもかかわらず、これまでのところ何も機能しませんでした。

アプリ

これはシンプルなチャットアプリであり、既存のアプリのJSONライブラリに新しいインターフェースを配置します。xドメインの制限（IE8）を回避するために、すべての呼び出しをアプリにプロキシします。ASP.netMVC3アプリ;

IIS6、W2K3SP2でホストされています。DEVsvrには1gigramがあり、TESTsvrには4gigramがあります。

問題

20人の同時ユーザーに近づくと、リクエストが遅れ始めます。イベントビューアに問題は見つかりません。通話がキューに入れられているようです。503は返品されません。

私たちが試したこと

  • AsyncControllerを使用して、IIS6でホストされている結果のサードパーティWebサービスをロングポーリングしています
  • TPLを使用して、AsyncControllerメソッドでサービスを呼び出しています
  • processModelを変更し、maxWorkerThreads=100に設定しました。
  • このハウツーを見てきましたが、HTTP.SYS構成は無限の数のスレッドを処理するように見えるので、regキーを追加する必要はありません。
  • サードパーティのサービスは、多数の同時リクエストを処理できます（Webファーム内にあるため、最も弱いリンクであると確信しています）。

何が欠けていますか？-助けていただければ幸いです

4

1 に答える 1

2

ええと...ほぼ4週間後、これらの制限を克服するのに何が役立ったかを誰かが知りたい場合に備えて、これを更新すると思いました（DEVサーバーである1gig Xeonに約100の同時接続を詰め込んでいます）。

AsyncControllers

  • 待機時間が長くなる可能性のあるリクエスト（つまり、長いポーリング）がある場合は、それらを使用します。
  • TaskFactoryを自由に使用できますが、スレッドで例外が発生する可能性がある場合は、必ずContinueWithを使用して操作をデクリメントし、呼び出し元にエラーを返すことができるように、長時間実行プロセスとしてマークしてください。

ServicePointManager

  • ダウンストリーム呼び出し（つまり、WebService / 3rdパーティAPI）を行う場合は、デフォルトの2つの同時接続からDefaultConnectionLimitを増やしていることを確認してください。
  • 大まかなガイドは8*Numコアであるため、発信接続リソースが不足することはありません。
  • 詳細については、DefaultConnectionLimitに関するこのMSDNの記事を参照してください。

IOCPとRestSharp

結局、私たちの問題は着信リクエストではなく、リクエストがサードパーティにプロキシされることであり、十分な接続を提供していなかったため、システム全体に遅れをとってキューに入れられました。たくさんの読書、調査、コーディングを経て、私たちはそれを解決しました。

于 2012-05-15T13:07:44.647 に答える