神秘的ASP.NET MVC操作高延迟问题？

问题描述

| 使用Firebug和Chrome开发人员工具，我可以看到通过操作加载一些javascript和CSS文件可能会在我的开发计算机上花费额外的500毫秒。这发生在不同的文件上，在不同的调用上并不重要，按我的顺序排列也没关系。如果我直接链接到这些文件，则不会发生500毫秒的延迟。我可以一遍又一遍地刷新页面并获得不同的值，但是它们看起来总是像在请求时间中添加了500ms。如果我不断刷新页面，则额外的500ms会显示在不同的单个文件或有时是两个文件上，其中一个文件会延迟1000ms，如下图所示。 编辑 将Monitor.Enter放入我的HttpModule \的BeginRequest中，将Monitor.Exit放入EndRequest中，导致延迟消失，所以我猜想这与线程化多个请求有关。 我在这里使用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);
}

这是我的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\",path = \"~/Scripts/debug/FBINFO.js\",contentType = \"application/x-javascript\" })\" type=\"text/javascript\"></script>
<script src=\"@Url.Action(\"RawFile\",path = \"~/Scripts/jquery-1.4.1.min.js\",contentType = \"application/x-javascript\" })\" type=\"text/javascript\"></script>

这似乎并没有在我的生产服务器上发生，至少没有那么频繁，但是由于延迟通常较高，因此很难说出来。这件事不用担心吗？是什么原因造成的？在Cassini和Windows 7 Home Ultimate 64位上的本地IIS服务器上均会发生这种情况。 我已经添加了一个自定义属性来为调用计时，OnAction / OnResult Executing和Executed之间的时间通常不到毫秒。我在动作方法周围使用了秒表（ZipController写入响应流，并且不返回结果），时间同样总是很小，平均1.5毫秒且总是在10毫秒以下。 我在Fiddler标头中看到的唯一真正的区别是X-AspNetMvc-Version标头，因此我将其设置为不附加，甚至删除了X-AspNet-Version标头也无济于事。我已经尝试启用和禁用压缩以及其他所有我能想到的东西。这是在我添加了自己的无效的Cache-Control和ETag标头之后。有趣的是，即使在未发送正文的“ 304未修改”响应的情况下，也会发生500毫秒的延迟。有时其中两个文件会有延迟，一个是500毫秒，另一个是1000毫秒。 直接文件：

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

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。

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.Enter，在EndRequest中称为Monitor.Exit。延迟消失了。 Chrome显示一个呼叫大约需要15-20毫秒，而另一个呼叫大约需要30-40毫秒，因为它必须等待第一个呼叫结束，但是500毫秒的延迟已经消失了。显然，这种解决方案不是最佳的。     

解决方法

        尝试禁用会话（

SessionStateAttribute

）。     ,        Cassini存在一个已知问题，而与IPv4上的IPv6主机文件映射相关的性能问题，以及Cassini在Windows 7下使用的端口号解析。它已经在Stack Overflow上得到了解决，并解决了Firefox和Chrome中出现的问题。