神秘的ASP.NET MVC行动的高延迟问题？ [英] Mysterious ASP.NET MVC Action High latency issue?

问题描述

用Firebug和Chrome开发者工具，我可以看到通过一个动作加载一些JavaScript和CSS文件可以把我的开发机器上额外的500毫秒。这种情况在不同的调用不同的文件，并不要紧，我把什么样的顺序它们。如果我直接链接到文件时不会永远出现此500ms的延迟。我可以一遍遍刷新页面，并得到不同的价值观，但他们总是看起来像500ms的加入请求时间。如果我继续刷新页面，额外的500毫秒显示了在不同的单个文件或有时两个文件，​​其中一个是像下面的图片在1000毫秒的延迟。

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.

修改

把Monitor.Enter在我的HttpModule的的BeginRequest和Monitor.Exit在EndRequest造成的延迟消失，所以我的猜测是它是与线程处理多个请求。

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.

我用埃文格尔的这里缓存，但是当我打到我自己的控制器，仅仅通过传递一个原始文件的操作更换环节同样的事情发生了：

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:

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);
}

这里的code我在我的HTML的头部分：

Here's the code I have in the head section of my 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>

这似乎并没有发生我的生产服务器上，至少不是经常，但是这是很难说，因为延迟较高正常。这是不是不担心？什么会导致呢？它发生都与卡西尼号，并与Windows 7家庭旗舰版64位我的本地IIS服务器。

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.

我添加了一个自定义属性来一次电话和执行的OnAction / OnResult之间的时间和执行的一般都是亚毫秒级。我用周围的操作方法秒表（该ZipController写入响应流，不返回的结果）和时代同样是老是少，平均1.5ms的，总是在10毫秒。

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.

唯一的区别我可以在提琴手头看到的是在X-AspNetMvc-版本头，所以我将它设置为没有追加，甚至拆除的X ASPNET-版本头无济于事。我试着启用和禁用COM pression约一切我能想到的了。这是在我加入我自己的Cache-Control和ETag头而没有效果。有趣的是，500ms的延迟发生，即使在没有发送体304未修改响应的情况下。有时候，两个文件将有延误，一是500毫秒和其他1000毫秒。

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.

直接文件：

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动作：

RawFile action:

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

继IanT8的评论，我增加了一个HttpModule来跟踪开始/结束请求，以及添加日志调用为我的行为方式的第一个和最后陈述。长话短说这两个请求在同一时间进来，并执行第二个呼叫的操作方法之前，首先EndRequest后发生500ms的延迟。该延迟通常是499ms，但它是497ms一次，498ms一次和492ms一次。

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.

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

现在的真正有趣的部分。我创建了我的HttpModule静态对象和的BeginRequest和Monitor.Exit在EndRequest称为Monitor.Enter。延迟dissappeared。 Chrome会显示一个电话取约15-20ms，另取约30-40ms，因为它必须等待第一次调用结束，但500ms的延迟了。显然，这个解决方案不是最佳的。

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.

推荐答案

尝试禁用会话（ SessionStateAttribute ）。

这篇关于神秘的ASP.NET MVC行动的高延迟问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！