使用Firebug和Chrome開發者工具，我可以看到通過一個動作加載一些javascript和css文件可以在我的開發機器上多花500ms。這發生在不同的電話上的不同文件，並且無論我將它們放入什麼順序都無關緊要。如果我直接鏈接到這些文件，這種500毫秒的延遲不會發生。我可以一遍又一遍刷新頁面並獲得不同的值，但它們總是看起來像500ms被添加到請求時間。如果我一直刷新頁面，額外的500毫秒會顯示在不同的單個文件中，有時也會顯示兩個文件，其中一個延遲1000毫秒，如下圖所示。神祕的ASP.NET MVC動作高延遲問題？
編輯
把Monitor.Enter在我的HttpModule的的BeginRequest和Monitor.Exit在EndRequest造成的延遲消失，所以我的猜測是它有事情做與線程的多個請求。
我用埃文格爾here緩存descibed的方法，但是當我打到我自己的控制器與剛剛經歷通過一個原始文件的操作更換鏈接同樣的事情發生了：
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", 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>
這似乎並沒有發生我的生產服務器上，至少不經常，但它是更難以分辨，因爲通常延遲較高。這件事不用擔心嗎？什麼會導致它？它發生在Cassini和Windows 7 Home Ultimate 64位本地IIS服務器上。
我已經添加了一個自定義屬性來調用OnAction/OnResult執行和執行之間的時間通常是毫秒。我已經在動作方法中使用了一個秒錶（ZipController寫入響應流並且不返回結果），並且時間也總是很短，平均爲1.5ms，總是在10ms以下。
我可以在Fiddler頭文件中看到的唯一真正區別是X-AspNetMvc-Version頭文件，所以我將它設置爲不被附加，甚至無法將X-AspNet-Version頭文件移除。我試過啓用和禁用壓縮以及其他所有我能想到的內容。這是我添加了自己的緩存控制和ETag頭後沒有效果。有趣的是，即使在沒有發送正文的304 Not Modified響應的情況下，500ms延遲也會發生。有時兩個文件會有延遲，一個是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之後發生500毫秒的延遲。這個延遲通常是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上創建了一個靜態對象，並在EndRequest的BeginRequest和Monitor.Exit中調用了Monitor.Enter。延遲消失了。 Chrome顯示一個通話需要大約15-20ms，另一個通話需要大約30-40ms，因爲它必須等待第一個通話結束，但500ms的延遲沒有了。顯然，這個解決方案並不是最優的。
你有沒有考慮採取的行動的編譯時間？您可以通過檢查後續調用來測試這一點。 – Buildstarted 2011-05-30 05:50:07
是的，我會爲問題添加註釋。 – 2011-05-30 06:01:33
難道它與服務器故障中提到的這個限制有關嗎？ MS真的想讓我們的開發機器幾乎無用於這種測試嗎？每個電話添加的精確500ms使我認爲它可能是這樣的。 http://serverfault.com/questions/133772/what-about-windows-7-as-a-web-server – 2011-05-30 06:46:52