现在这可能是一个简单的问题，但我有点困惑。
我将我的MVC3 C＃.NET Web应用程序发布到IIS文件夹。我选择了预编译选项并取消选中“允许站点可更新”以确保编译视图，并且它们是bin中的“.compiled”文件，即：
_createoredit.cshtml.1c32bb75.compiled
“cs”文件被编译到主项目dll即。
myApp.dll
在第一次通话时，页面可能需要30-60秒才能加载然后＆lt; 1秒
如果我刷新应用程序池页面，则需要30-60秒。
我目前的理解是这个时间延迟是由抖动将dll中的字节代码编译成二进制代码引起的？
我曾希望通过预编译视图来显着增加应用程序池刷新后的响应时间。然而不是这样，但也许这是因为我的项目文件是字节代码，我需要做更多的事情呢？
我确实知道您可以通过重新访问网站来保持网络应用程序的温暖，但实际情况是应用程序池因为奇怪的原因而得到刷新。我也在使用Azure。所以我真的想使用部署的代码单元，它们会在刷新后尽快运行。
非常感谢您的任何帮助。
修改
预编译了视图并使用共享或标准实例部署到Azure网站后，我仍然得到了初始的负载延迟，这是由AppPool刷新引发的，这是我故意通过重新保存Web.config引起的。老实说，我没有看到预编译视图有任何明显的好处，因为当.NET似乎在第一次加载时进一步编译“.compiled”视图时，我仍然会受到时间的惩罚。
EDIT2
有关@ Yishal帖子的更多信息。
我在开发时使用Basic和测试标准。我启用了“Always on”，这实际上是一个autoping。我也有“Uptime-robot”autopinging。我还测试了一个单独的共享站点，其中包含所有预编译的视图。 autopinging有助于保持应用程序池温暖。但是，如果应用程序池刷新，即通过web.config重新保存（用于测试），那么再次获得较长的初始等待。可以长达一分钟，然后＆lt;相同页面1秒。我唯一想到的是，将project.dll（.net p-code）编译成二进制并保存在RAM中大约需要60秒。
答案 0 :(得分：1)
当你预编译一个应用程序然后将它部署在服务器上时，应用程序池将重新启动并稍微重新加载自己。之后在aspnet中有了新功能，它仍然会在下一个请求中显示无用的下一个请求毫秒。这是iis 8的新功能。
但是，如果您在重新启动应用程序池时未使用iis 8，请花一些时间完成所有主机进程并卸载，重新加载并重新编译该站点，以便在下一个请求中提供它。这是正常的行为。你可以做到thosand次，它总是一样的:)）
希望有所帮助
答案 1 :(得分：1)
您可能想看一下IIS 8上的Azure应用程序初始化模块上的这篇文章：http://fabriccontroller.net/blog/posts/iis-8-0-application-initialization-module-in-a-windows-azure-web-role/（最初链接自：Does Windows Azure support the Application Warm-Up module or something similar?）。
答案 2 :(得分：1)
如果您使用网站免费套餐，这是预期的。如果你不是，请告诉我，我们可以更多地了解它。
另请注意，预编译视图根本无助于您的方案的启动时间，特别是如果您尝试单个页面。这个单页将动态编译，其成本相当小。