我正在运行Windows 8.1,我有一个集成测试套件,它利用HostableWebCore来启动孤立的ASP.NET Web服务器进程。出于性能原因,我一次启动其中的8个,一旦启动,我向每个发送一个非常简单的Web请求,由每个加载的MVC应用程序处理。每个实例都在监听不同的端口。
问题是这些请求在HTTP.sys(或者这些天所称的任何东西)中被阻止了(我相信)。如果我看一下fiddler,我可以立即看到所有8个请求(在几毫秒内)达到ServerGotRequest状态。但是,请求在此状态下保持20-100秒,具体取决于我一次并行运行的数量。
我怀疑这是HTTP.sys问题的原因是因为我必须等待其中任何响应的时间量随着我并行启动的托管应用程序的数量而增加。如果我只启动一个托管应用程序,它将在约20秒内开始响应。如果我旋转2,他们都会在约30秒内开始响应。如果我旋转4,~40秒。如果我旋转8,~100秒(这是默认的WebClient请求超时)。
由于这个长时间的延迟,我有足够的时间来附加调试器并在我的控制器操作中放置一个断点,并且该断点将在20-100秒延迟后被命中,这表明我的进程尚未收到请求。在冷启动CPU冷却约5-10秒后,所有主机都在闲置20-100秒。所有主机似乎同时收到请求,好像有什么东西阻止任何请求通过,然后突然让一切通过。
我的问题是,我无法找到任何有关如何调试HTTP.sys的信息。我怎么才能看到它在做什么?是什么导致阻止?为什么要等待向工人提出要求?为什么他们都在一起?
或者,如果有人知道如何解决这个问题并立即得到请求(没有等待),我将非常感激。
另一个注意事项:我可以看到系统(PID 4)立即注册,以便在托管应用程序启动时立即监听我指定的端口。
其他信息:
这是我的托管应用程序在netsh http show servicestate
Server session ID: FD0000012000004C
Version: 2.0
State: Active
Properties:
Max bandwidth: 4294967295
Timeouts:
Entity body timeout (secs): 120
Drain entity body timeout (secs): 120
Request queue timeout (secs): 120
Idle connection timeout (secs): 120
Header wait timeout (secs): 120
Minimum send rate (bytes/sec): 150
URL groups:
URL group ID: FB00000140000018
State: Active
Request queue name: IntegrationTestAppPool10451{974E3BB1-7774-432B-98DB-99850825B023}
Properties:
Max bandwidth: inherited
Max connections: inherited
Timeouts:
Timeout values inherited
Logging information:
Log directory: C:\inetpub\logs\LogFiles\W3SVC1
Log format: 0
Number of registered URLs: 2
Registered URLs:
HTTP://LOCALHOST:10451/
HTTP://*:10451/
Request queue name: IntegrationTestAppPool10451{974E3BB1-7774-432B-98DB-99850825B023}
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Controller process ID: 12812
Process IDs:
12812
答案 0 :(得分:0)
主要为后人回答这个问题。事实证明我的问题不是HTTP.sys,而是ASP.NET。它在尝试编译文件时打开共享锁。此共享锁由System.Web.HttpRuntime.AppDomainAppId
标识。我相信,由于我的所有应用程序都是使用通用applicationHost.config
文件动态构建的,因此它们都具有相同的AppDomainAppId(/LM/W3SVC/1/ROOT
)。这意味着它们共享一个锁,并且有效地为所有应用程序顺序地进行所有页面编译。但是,由于来自锁定的性质,所有页面都倾向于同时完成,因为它们中的任何一个都不可能及时到达流程的最后,导致它们全部完成大约在同一时间。一旦其中一个人通过,其他人可能会紧随其后并在之后完成。