Using Firebug and Chrome developer tools, I can see loading some javascript and css files through an action can take an extra 500ms on my development machine. This happens to different files on different calls and doesn't matter what order I put them in. If I link directly to the files this 500ms delay doesn't ever occur. I can refresh the page over and over and get different values, but they always look like 500ms was added to the request time. If I keep refreshing the page, the extra 500ms shows up on different single files or sometimes two files where one is a 1000ms delay like in the image below.
通过使用Firebug和Chrome开发工具，我可以看到通过一个操作加载一些javascript和css文件可以在我的开发机器上增加500ms。在不同的调用中，不同的文件会发生这种情况，而不管我以什么顺序将它们放入。如果我直接链接到文件，这个500ms延迟不会发生。我可以反复刷新页面并获得不同的值，但它们看起来总是像在请求时间中添加了500ms。如果我继续刷新页面，额外的500ms会显示在不同的单个文件上，有时会显示两个文件，其中一个文件的延迟为1000ms，如下图所示。
EDIT
编辑
Putting Monitor.Enter in my HttpModule's BeginRequest and Monitor.Exit in the EndRequest caused the delay to go away, so my guess is it has something to do with threading multiple requests.
把监控。输入我的HttpModule的BeginRequest和Monitor。在EndRequest中退出会导致延迟消失，因此我猜测这与线程化多个请求有关。
I use the method descibed by Evan Nagel here for caching, but the same thing happens when I replace the links with calls to my own controller with an action that just passes a raw file through:
我在这里使用Evan Nagel的方法来进行缓存，但是当我用调用我自己的控制器来替换链接时，也会发生同样的情况:
public FileResult RawFile(string path, string contentType)
{
var server = HttpContext.Server;
string decodedPath = server.UrlDecode(path);
string mappedPath = server.MapPath(decodedPath);
return File(mappedPath, contentType);
}
Here's the code I have in the head section of my html:
下面是我在html首页上的代码:
<link rel="stylesheet" href="@Url.Action("RawFile", new { controller = "Content", path = "~/Content/Site.css", contentType = "text/css" })" type="text/css" />
<script src="@Url.Action("RawFile", new { controller = "Content", path = "~/Scripts/debug/FBINFO.js", contentType = "application/x-javascript" })" type="text/javascript"></script>
<script src="@Url.Action("RawFile", new { controller = "Content", path = "~/Scripts/jquery-1.4.1.min.js", contentType = "application/x-javascript" })" type="text/javascript"></script>
This doesn't seem to happen on my production server, at least not as often but it is harder to tell because the latency is higher normally. Is this something not to worry about? What would cause it? It happens both with Cassini and with my local IIS server on Windows 7 Home Ultimate 64 bit.
这在我的生产服务器上似乎不会发生，至少不会经常发生，但是很难判断，因为延迟通常更高。这是不需要担心的吗?它会导致什么?卡西尼和我在Windows 7 Home Ultimate 64位上的本地IIS服务器都会出现这种情况。
I've added a custom attribute to time the calls and the times between OnAction/OnResult Executing and Executed are generally sub-millisecond. I've used a stopwatch around the action method (the ZipController writes to the response stream and doesn't return a result) and the times are likewise always small, average 1.5ms and always under 10ms.
我已经添加了一个自定义属性来设置调用的时间，并且OnAction/OnResult执行和执行之间的时间通常都小于毫秒。我在操作方法周围使用了一个秒表(ZipController向响应流写入，但不返回结果)，时间也同样很小，平均为1.5ms，总是在10ms以下。
The only real difference I can see in the Fiddler headers is the X-AspNetMvc-Version header, so I set it to not be appended and even removed the X-AspNet-Version header to no avail. I've tried enabling and disabling compression and about everything else I can think of too. This is after I added my own Cache-Control and ETag headers which had no effect. Interestingly the 500ms delay happens even in the case of a 304 Not Modified response where the body is not sent. Sometimes two of the files will have delays, one 500ms and the other 1000ms.
我在Fiddler头文件中看到的唯一真正的区别是X-AspNetMvc-Version头文件，所以我将它设置为不追加，甚至删除了x - aspnet版本头文件。我已经尝试过启用和禁用压缩以及我能想到的其他所有东西。这是在我添加了自己的Cache-Control和ETag头之后，它们没有任何效果。有趣的是，即使在没有发送正文的304没有修改响应的情况下，500ms的延迟也会发生。有时两个文件会有延迟，一个是500ms，另一个是1000ms。
Direct file:
直接文件:
HTTP/1.1 200 OK
Content-Type: application/x-javascript
Last-Modified: Sun, 29 May 2011 22:42:27 GMT
Accept-Ranges: bytes
ETag: "b57a84af511ecc1:0"
Server: Microsoft-IIS/7.5
Date: Mon, 30 May 2011 04:38:20 GMT
Content-Length: 1336
RawFile action:
RawFile行动:
HTTP/1.1 200 OK
Cache-Control: public
Content-Type: application/x-javascript
ETag: "CD9F383D0537373C6D2DC8F60D6519A6"
Server: Microsoft-IIS/7.5
Date: Mon, 30 May 2011 04:34:37 GMT
Content-Length: 1336
Following IanT8's comment, I added an HttpModule to track begin/end request, as well as adding log calls as the first and last statements of my action methods. Long story short both requests come in at the same time and the 500ms delay occurs after the first EndRequest, before the action method of the second call is executed. This delay is usually 499ms, but it was 497ms once, 498ms once and 492ms once.
在IanT8的评论之后，我添加了一个HttpModule来跟踪开始/结束请求，并添加日志调用作为操作方法的第一个和最后一个语句。长话短说两个请求同时出现，500ms延迟发生在第一个EndRequest之后，在第二个调用的操作方法执行之前。这个延迟通常是499ms，但它是497ms一次，498ms一次，492ms一次。
2011-05-31 00:55:19.1874|INFO|20110531 00:55:19.196 BeginRequest: http://localhost:51042/Zip/Style?Path=~/Content/Site.css
2011-05-31 00:55:19.1874|INFO|20110531 00:55:19.197 BeginRequest: http://localhost:51042/Zip/Script?Path=~/Scripts/jquery-1.4.1.min.js|~/Scripts/debug/FBINFO.js
2011-05-31 00:55:19.2034|INFO|20110531 00:55:19.203 Style() Start
2011-05-31 00:55:19.2034|INFO|20110531 00:55:19.208 Style() End
2011-05-31 00:55:19.2034|INFO|20110531 00:55:19.212 EndRequest: http://localhost:51042/Zip/Style?Path=~/Content/Site.css
2011-05-31 00:55:19.7044|INFO|20110531 00:55:19.704 Script() Start
2011-05-31 00:55:19.7044|INFO|20110531 00:55:19.712 Script() End
2011-05-31 00:55:19.7044|INFO|20110531 00:55:19.713 EndRequest: http://localhost:51042/Zip/Script?Path=~/Scripts/jquery-1.4.1.min.js|~/Scripts/debug/FBINFO.js
Now for the really interesting part. I created a static object on my HttpModule and called Monitor.Enter in the BeginRequest and Monitor.Exit in the EndRequest. The delay dissappeared. Chrome shows one call taking about 15-20ms and the other taking about 30-40ms because it has to wait for the first call to end, but the 500ms delay is gone. Obviously this solution is not optimal.
现在是真正有趣的部分。我在我的HttpModule上创建了一个静态对象，并调用了Monitor。输入BeginRequest和Monitor。EndRequest退出。随后的延迟。Chrome显示一个调用需要15-20ms，另一个需要30-40ms，因为它必须等待第一个调用结束，但是500ms的延迟消失了。显然这个解不是最优的。
2 个解决方案
#1
5
Try to disable session (SessionStateAttribute).
尝试禁用会话(sessionstate属性)。
#2
0
There is a known issue with Cassini and performance related issues to IPv6 host file mapping over IPv4, and the port number resolution that Cassini uses under Windows 7. It is already answered on Stack Overflow and solves issues seen in Firefox and Chrome.
卡西尼存在一个已知的问题，以及与IPv4上的IPv6主机文件映射相关的性能问题，以及卡西尼在Windows 7下使用的端口号解析。它已经在Stack Overflow上被回答，并且解决了在Firefox和Chrome中看到的问题。
#1
5
Try to disable session (SessionStateAttribute).
尝试禁用会话(sessionstate属性)。
#2
0
There is a known issue with Cassini and performance related issues to IPv6 host file mapping over IPv4, and the port number resolution that Cassini uses under Windows 7. It is already answered on Stack Overflow and solves issues seen in Firefox and Chrome.
卡西尼存在一个已知的问题，以及与IPv4上的IPv6主机文件映射相关的性能问题，以及卡西尼在Windows 7下使用的端口号解析。它已经在Stack Overflow上被回答，并且解决了在Firefox和Chrome中看到的问题。