我有一个ASP.NETMVC应用程序运行在使用. NETFramework 4.7.2的IIS上。有一个端点需要5分钟才能返回响应。响应是成功的，代码或IIS日志中没有错误。
我已经使用System.Diagnostic.Stopwatch对控制器操作中的几乎每一行进行了计时，整个操作在100毫秒内完成。
更有趣的是，我们在AWS中同时使用登台环境和生产环境帐户运行此应用程序。此问题仅发生在生产环境中，并且只有一台服务器。实际上，我们有两台服务器在运行此应用程序的副本，并且只有一台服务器出现此问题。虽然出现问题的服务器接收的流量比其他服务器多得多，它每天仅接收大约25，000次页面浏览，并且没有其它端点花费这么长的时间来完成该请求。
该应用程序是使用Elastic Beanstalk和 .NET在Windows Server 平台上部署的。我们已多次重建应用程序环境和服务器，并且在服务器之间保持一致。
我还直接连接到服务器并安装了IIS失败请求跟踪。根据IIS失败请求跟踪，步骤206。GENERAL_SET_RESPONSE_HEADER，其中HeaderName=X-Frame-Options和HeaderValue=SAMEORIGIN花费了362，063毫秒（约6分钟）。这在ManagedPipelineHeader模块中，通知为EXECUTE_REQUEST_HANDLER。
参见图片：IIS Failed Request Tracing
1条答案
按热度按时间cuxqih211#
哎呀，6分钟。我很惊讶它没有超时。我注意到this other post，但它没有看到直接相关的，因为他们使用的是Sping Boot ，而您的应用程序是ASP.NET MVC 4x。这确实让我想知道，尽管没有共同的潜在原因。所以在他们的情况下，他们在Spring Boot 时禁用了frameoptions（http. header（）.frameOptions（）.disable（）），这样它就不会再尝试写入请求头。
在这两种情况下，很难判断，但我想知道，如果CloudFront和特定的框架在每个例子中没有争夺这个特定的头部主导地位，但你没有提到CloudFront，所以我可能完全错了。有没有可能CloudFront被用于您的prod端（与问题），而不是开发端？