2017-01-04 37 views
0

我在WCF服務中有一個間歇掛起。在服務恢復之前,通常需要幾毫秒才能完成的通話需要30秒或更長時間才能完成。但是,所有呼叫都能成功完成。 New Relic報告說,請求中的所有時間都用在了ExecuteRequestHandler中。在GENERAL_SET_RESPONSE_HEADER期間WCF服務間歇掛起

我啓用了服務器上所有請求的失敗請求跟蹤,並觀察和等待。當網站開始掛我拉的痕跡來,我看這是典型的情況如下:

136 - GENERAL_SET_RESPONSE_HEADER

HeaderName:Content-Length的 HeaderValue:2237 替換:假

信息化

273281毫秒

日誌中的所有其他步驟都以0ms爲時間間隔。懸掛功能各不相同,當服務正常運行時,具有完全相同參數和響應有效載荷的完全相同的功能表現完美。看起來,當網站開始掛起時,所有請求都會被阻止,直到恢復。

任何人都可以建議我從哪裏去。

謝謝

回答

0

這是在那裏的方式,從我的角度來看非常惱人。 New Relic說這個服務掛在了ExecuteRequestHandler上,我試圖進入一個試圖診斷這個掛起的兔子洞。

分辨率竟然是調整節流配置WCF服務:

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

原來,WCF服務默認情況下,節流,即使沒有此項目存在,最近MS增加的默認值。我的服務以大約200轉的速度下降(我認爲這不是過度)。我使用的值是新的默認值的8倍,現在一切都很好用。

爲什麼服務被扼殺,但沒有跡象表明這是發生在默認配置條目我不知道。 WCF已經配置了地獄,我決定永遠不要再使用它。 Web API從這裏開始。

希望這可以幫助別人有一天:)