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错误的请求

回答

相关问题