2017-01-04 22 views
0

WCFサービスで断続的なハングアップが発生しました。一般にミリ秒かかるコールは、サービスが回復する前に完了するまでに30秒以上かかることがあります。しかし、すべての呼び出しは正常に完了します。 New Relicは、リクエスト内のすべての時間がExecuteRequestHandlerで費やされたことを報告します。GENERAL_SET_RESPONSE_HEADER中にWCFサービスが断続的にハングアップする

私は、すべての要求に対してサーバー上で要求トレースを失敗し、監視して待機しました。サイトがぶら下がって始めたとき、私がダウンしてトレースを引っ張って、私は典型的なもので、以下を参照してください - 置き換え2237 :偽

情報を

136 GENERAL_SET_RESPONSE_HEADER

HeaderNameは:コンテンツ長 headerValueのを

273281ミリ秒

ログ内の他のすべてのステップは0msでタイムアウトします。ハンギング機能は異なり、サービスが正常に実行されている場合、まったく同じパラメータと応答ペイロードを持つ同じ機能が完全に動作します。サイトがハングアップすると、すべてのリクエストが回復するまでブロックされているように見えます。

私はここからどこに行くのか誰にでも提案できます。

ありがとうございました

答えて

0

これは私の視点からはかなり迷惑なものでした。 New Relicは、このサービスがExecuteRequestHandlerにぶら下がっていると言っていましたが、私はハングを診断しようとしているウサギの穴に溺れました。

解像度は、WCFサービスのスロットル設定を調整することが判明:

<system.serviceModel> 
    <behaviors> 
     <serviceBehaviors> 
     <behavior name="..."> 
      <serviceThrottling maxConcurrentCalls="512" maxConcurrentSessions="3200" maxConcurrentInstances="3712" /> 

は、WCFサービスが存在し、最近MSは、デフォルト値を増加させたことも、このエントリせずにデフォルトで絞られていることがわかります。私のサービスは約200rpmで落ちていた(これは私が過度だとは思わない)。私が行った値は新しいデフォルト値の8倍であり、今はすばらしく機能しています。

デフォルトの設定エントリでこれが起こっていることを知らずにサービスが抑制される理由は分かりません。 WCFは設定地獄だったので、私は再びそれを使用する決心をしました。ここからのWeb API

これは誰かを助けることを願っています:)

関連する問題