28

WSHttpBinding を使用して HTTP 経由で通信する WCF クライアント/サーバー アプリがあります。

サーバーのセットアップ: 標準の WCF を使用したセルフホスティングServiceHost。私の実際のサービスクラスは次のように分類されます：

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, 
 InstanceContextMode = InstanceContextMode.PerSession, 
 UseSynchronizationContext = false)]

クライアント セットアップ:同期サービス呼び出しを使用してビジュアル スタジオで生成されたクライアント プロキシを使用します (proxy.call_server_methodサーバーが完全に応答するまでブロックします)。

シナリオ: サーバー上で実行するのに 20 秒かかる特定のメソッド呼び出しがあります。クライアントはこのメソッドを別のスレッドで呼び出すため、保留されていないため、ConcurrencyMode.MultipleWCF はサーバー上の別のスレッドでもメソッドを実行する必要があります。

NetTcpBindingこの理論は、アプリを使用するように構成すると、すべてが正常に機能するという事実によって裏付けられています。

問題:
を使用するようにアプリを構成するWSHttpBindingと、この長いメソッド呼び出しによって http 要求が「バックアップ」されます。ログを調べて、フィドラーを使用して HTTP 要求をデバッグすることで、この動作を確認しました。

例：

  • クライアントがバックグラウンド スレッドで 20 秒間のリクエストを開始する
  • クライアントはフォアグラウンド スレッドでリクエスト B と C を開始します
  • リクエスト B と C はサーバーに送信されますが、サーバーは 20 秒間のリクエストが完了するまでそれらを処理しません。

でも時々：

  • リクエスト B と Cは、20 秒のリクエストが返されるまで送信されません(フィドラーにも表示されません) (これはまれです)。
    • 注:<add address="*" maxconnection="100"/>クライアントの app.config を設定すると、この (ように見える) 現象が発生しなくなりました。
  • リクエスト B は送信され、すぐに応答を受け取りますが、リクエスト C は 20 秒のリクエストが完了するまで保留されます (これはまれです)。

問題を示すフィドラーからのタイムラインは次のとおりです：（クリックすると拡大版が表示されます）

ご覧のとおり、リクエストはすべてサーバーにバックアップされています。20 秒のリクエストが完了すると、すべてのレスポンスがフラッディングされますが、一部のリクエストが遅延しないことに注意してください...

だから、質問：

  • ここで一体何が起こっているのですか？NetTcpBindingを使用すると正常に動作し、使用すると動作しないのはなぜWSHttpBindingですか?
  • 一貫性のない動作はなぜですか？
  • 修正するにはどうすればよいですか?

ノート：

  • サーバー上でロックしていません。ブレークポイントを設定して使用!syncblkしましたが、ロックが保持されていないと一貫して報告されます。
  • それは私のスレッドではありません (それ以外の場合、NetTcpBinding は機能しません)。
  • <serviceThrottling maxConcurrentCalls="1000" maxConcurrentInstances="1000" maxConcurrentSessions="1000" />サーバーのapp.configに設定しました
  • 20 秒の呼び出しはタイマーで待機しているだけであり、CPU、ディスク、またはネットワークをスラッシングしていません。
  • 非同期呼び出しを使用するためにアプリケーションを再構築する必要のないソリューションが望ましいと思います...それは大量のレガシー コードであり、理解できないものをいじりたくないのです。
4

8 に答える 8

11

WCF (.Net または Windows のもの) の外側には、最大 2 つの同時送信 HTTP 接続のみを許可するように既定で設定されているスロットルがあります。残念ながら、私は一生、その名前を覚えていません（そして、それをオーバーライドするために app.config またはアプリに何を入力したか）。リクエストがクライアントから送信されていないこと、およびそれが HTTP のみであることを考えると、「そのこと」に当たっていると思います。その名前を探し続けます。

更新:見つかりました-クライアントでこれを試してください(ただし、「2」をより大きな数字に変更してください):

<configuration>
  <system.net>
    <connectionManagement>
      <add address = "*" maxconnection = "2" />
    </connectionManagement>
  </system.net>
</configuration>
于 2009-05-07T04:35:20.633 に答える
4

IIS/ASP.NETでホストされているJSONサービスでもまったく同じ症状が見られました。

根本的な原因は、WCFではなくASP.NETが要求を同期することでした。同時WCFメソッドを取得するには、セッション状態を（アプリケーションレベルで）無効にする必要がありました。

Web.config： <system.web> <sessionState mode="Off" /> </system.web>

私たちのサービスはwsHttpBindingではなくwebHttpBindingを使用していることに注意してください。ですから、これでオリオンの問題も解決するかどうかはわかりません。

于 2011-06-30T08:08:07.777 に答える
2

プロトコルの制限に達したと思います。それを回避するには、クライアント マシンの標準設定を変更する必要があります。

http://support.microsoft.com/kb/183110

http://support.microsoft.com/kb/282402

WSHttpBinding は、リクエストを発行するときに WinINET 設定を使用していると思います。

于 2011-06-30T08:24:54.327 に答える
2

[最終的な解決策が何であったかを他のユーザーに示すための自己回答]

結局、私はこれを解決することができませんでした。私たちの最終的な解決策は、アプリを本番
環境から切り替えて本番環境に切り替えることでした。パフォーマンス上の理由から、最終的にはこれを行うことを計画していました。WSHttpBindingNetTcpBinding

WSHttpBindingただし、これは保証される場合と保証されない場合がある黒いマークを残すため、かなり残念です。誰かが捨てることを伴わない解決策を思いついたらWSHttpBinding、私はそれについて知りたいです

于 2009-09-21T20:56:06.887 に答える
1

BasicHttpBinding に変更すると動作しますか?

そうです、これはあなたの問題、セッションのスロットリング、お尻に噛み付いたものであるように聞こえます。

于 2009-05-08T03:35:27.400 に答える
1

呼び出しごとのサービスで ConcurrencyMode.Multiple を使用して、同時呼び出しを許可することを検討してください。

于 2011-01-09T06:54:14.990 に答える
0

忘れました-注文でしょうか？おそらく RM over http は順序を保持すると思いますが、Tcp セッションは (明示的に要求しない限り) 保持しないのでしょうか? 順序付けられた/順序付けられていないセッションを説明するサービス コントラクトの属性はありますか (忘れました)。

于 2009-05-08T03:25:47.797 に答える