IIS 8.5在使用Post方法調用REST WS時在生產中拋出400錯誤的請求

我有一個奇怪的問題。讓我一步一步詳細解釋：IIS 8.5在使用Post方法調用REST WS時在生產中拋出400錯誤的請求

我有一個供應商開發的REST WS（使用WCF製造）用於與MS CRM同步數據。
我開發了一個windows服務，它從數據庫中提取要同步的批量數據，然後使用Post方法將其作爲JSON對象傳遞給此Web服務。 Windows服務部署在其中一個節點上。
我面臨的問題從未發生在Dev，QA，UAT或分段環境中。它僅適用於生產環境。
在生產中，應用程序有一段時間工作，然後開始拋出400錯誤的請求錯誤。然後，直到我們重新啓動網站或重置應用程序池標識IIS不斷拋出400錯誤的請求錯誤。當我們重新啓動網站或應用程序池時，相同的請求失敗開始獲得成功的響應。它可以在這樣的一段時間內工作，並且再次發生400次啓動。
託管Web服務的環境是Win Server 2012,2節點負載平衡環境。 WS在端口8080上部署在boht節點上，並配置爲在.Net 4.0下運行。
我在我的Windows服務日誌中收到以下錯誤，這是這些WS的客戶端。

System.Net.WebException: The remote server returned an error: (400) Bad Request. at SspToCrmSynchronizationService.Helpers.CrmWrapperWsHelper.CallService(String data, String url, String method, String userName, String password, String contentType) in CrmWrapperWsHelper.cs:line 79 at SspToCrmSynchronizationService.Helpers.CrmWrapperWsHelper.CallDocumentCreateService(String data) in CrmWrapperWsHelper.cs:line 20 at SspToCrmSynchronizationService.Process.CommonOperations.GenerateJsonAndInvokeDocCreateWS(Int64 appRefNo, Application app) in CommonOperations.cs:line 52 at SspToCrmSynchronizationService.Process.SequentialProcess.Process(List`1 appList, DatabaseHelper dbHelperForChildTask, CancellationToken ct) in SequentialProcess.cs:line 88

首先，我們已經檢查了IIS日誌，發現IIS在僅數100 MS返回400錯誤。我們懷疑它沒有到達WS應用程序，因爲應用程序根本沒有記錄任何東西，儘管記錄請求是供應商在WS代碼中做的第一件事情。

其次，我們使用的Fiddler捕獲請求和響應，並獲得以下：

HTTP/1.1 400 Bad Request 
Cache-Control: private 
Content-Length: 1647 
Content-Type: text/html 
Server: Microsoft-IIS/8.5 
X-ASpNet-Version: 4.0.30319 
X-Powered-By: ASP.Net 
Date: Tue, 17 Oct 2017 07:14:26 GMT

比我們檢查了IIS HTTPERR日誌。在日誌中，我們發現了一些請求的以下內容，而不是每個失敗的請求。這似乎沒有。

2017-07-07 03:32:45 10.102.2.52 63726 10.102.2.52 8080 - - - - - Timer_ConnectionIdle -
2017-07-08 22:46:55 10.102.2.52 50916 10.102.2.52 8080 - - - - - Timer_ConnectionIdle - 2017-07-08 22:55:09 10.102.2.52 51004 10.102.2.52 8080 - - - - - Timer_ConnectionIdle -

比我們配置了失敗示蹤登錄IIS 400，得到了在跟蹤日誌一個警告當該400引發錯誤。由於NDA和安全原因，我已從映像中刪除了一些數據。

基本上警告細節如下：

124. MODULE_SET_RESPONSE_ERROR_STATUS 
ModuleName="ManagedPipelineHandler", 
Notification="EXECUTE_REQUEST_HANDLER", 
HttpStatus="400", 
HttpReason="Bad Request", 
HttpSubStatus="0", 
ErrorCode="The operation completed successfully. (0x0)", 
ConfigExceptionInfo=""

此後我比較一個錯誤的情況下，一個成功的情況。以下是圖片。我注意到，如果發生故障，General_Read_Entity_Start和General_Read_Entity_End根本沒有發生。

最大我可以理解的是，不知何故IIS不能解析JSON字符串的一些實體和程序池變得崩潰，然後開始拋400錯誤，直到一個應用程序池或IIS復位不這樣做。我不知道是什麼導致了這種情況（根本原因），以及如何解決這個問題，以及它爲什麼最初工作，並且一段時間後沒有工作。任何幫助將不勝感激。

[編輯]

在服務器上的資源的消耗是小於10％。
對於成功的案例，WS的平均響應時間爲5秒，而對於錯誤情況，它在100毫秒內返回。
我們爲測試中的服務進行了約100次以上的壓力測試，並且一切正常。

來源

2017-10-17 S M Kamran

重新啓動後「停止工作」的時間是否一樣？它是否與服務經歷的假設流量成線性變化？你有壓力/秒殺測試過這項服務嗎？您是否監視了託管服務器的資源？

如果它只出現在Prod上，它不應該與測試服務器不同，那麼預計Prod會被未知數量的源使用。首先，我會確保資源與此無關。（如果不違反用戶權限的話，可以通過請求向具有類似功能的某個測試服務器發送請求，並查看會發生什麼情況）：

來源

2017-10-17 12:44:37 dbencs

這些服務器上的資源消耗少於10％。即使在錯誤發生時也是如此。 –

對於成功的案例，WS的平均響應時間爲5秒，而對於錯誤情況，它在100毫秒內返回。如果這是你問的問題？ –

我們爲測試中的服務進行了約100次以上的壓力測試，並且一切正常。 –

IIS 8.5在使用Post方法調用REST WS時在生產中拋出400錯誤的請求

回答

相關問題