MVC 4应用程序渲染时间与Visual Studio 2012

当我在Chrome上使用Visual Studio 2012运行我的mvc应用程序时，我的页面需要36s渲染 - 使用mini-profiler看到了这一点。当我将该项目托管在远程服务器上并点击该页面的服务器时，第一次命中需要36秒。但在后续命中时，它会显着减少到1秒或更少。任何想法为什么这可能是？在远程服务器上，当我们重新启动应用程序池时，我们看到它需要36秒。MVC 4应用程序渲染时间与Visual Studio 2012

所以问题是，是否花了很长的时间，因为IIS分配资源到网站或者我们的安装有什么问题吗？每次我们调试项目时，我们的开发时间都会受到影响。生成，然后每次需要36s渲染我们正在调试的页面。

来源

2013-03-05 safriss

几个可能性浮现在脑海中：

查看编译

通过当你在Visual Studio中的项目工作默认情况下，视图点播编译。虽然36秒似乎很长时间来编译第一页的视图，但这可能是一个促成因素。如果您的页面发生更改，则必须重新编译。进行测量时，为了消除这个作为一个因素，你可以用文本编辑器编辑您的.csproj文件，并更改线路

<MvcBuildViews>false</MvcBuildViews>

到

<MvcBuildViews>true</MvcBuildViews>

（也可以是一般的一个有用的设置）。

其他初始化开销

如果你是做多的初始化当你的应用程序启动（可能是预加载从文件或数据库中的一些数据），即初始化必须发生的每一次网络服务器启动或应用程序域回收。在Visual Studio中，我发现Web服务器可以在令人吃惊的时间重新启动（对我来说）。添加一些日志记录，以查看您是否在特定的基准测试运行期间运行启动代码，并查看有多少开销。

实体框架

出于某种原因，实体框架运行调试时多慢。如果您通过EF执行大量数据访问，则可能会导致一些差异。

来源

2013-03-05 20:51:49

我做的第一件事是改变MVCBuildViews =“true”，但没有改变任何东西。关于预加载数据，是捆绑吗？那是automapper配置吗？ – safriss 2013-03-05 21:07:04

捆绑应该不会超过几个甚至几百毫秒。在DEBUG模式下（基于web.config设置，而不是VS中的构建设置），捆绑实际上并未完成，而是捆绑中的文件通过未改变的方式传递。所以如果有什么DEV会更快。对于预加载数据，我的意思是你可能会从你的数据库加载数据或者在'Application_Start（）'中加载类似的数据。无论如何，我会测量在Application_Start（）中花了多少时间。 – 2013-03-05 21:37:51

当我们直接在页面上放置脚本而不是在调试模式下使用绑定功能时，我们的启动似乎要快得多。这个链接（http://todd-carter.com/post/2012/06/10/mini-me-fication-in-system-web-optimization-rc-is-evil/）似乎说同样的事情，但它似乎微软已经更新了这个，但我不太确定。我们没有使用rc版本。 – safriss 2013-03-05 21:56:21

当你说“跑”时，我假设你的意思是调试。调试重建项目，然后一旦它加载浏览器，首次加载的所有标准初始化必须每次完成。事实上，需要与服务器上的应用程序池旋转时间相同的时间（36秒）似乎证明了这一点。

FWIW，你只需要需要在每个Visual Studio会话中调试一次你的项目，让IIS Express启动。之后，您可以简单地重建项目并在（不使用Visual Studio中的调试）之后直接刷新浏览器以测试更改。而且，如果您对任何* .cs文件进行了更改，则只需重新构建。 Razor视图，web.config等将反映它们在下一页加载时的更改，而无需重建。以这种方式失去唯一的东西就是调试能力，显然是这样。你只会得到一个标准的死亡黄页，而不是自动跳到Visual Studio中有害的代码。但是，我发现除非真的需要调试，否则这种方法开发起来要快得多。

来源

2013-03-05 21:18:18

MVC 4应用程序渲染时间与Visual Studio 2012

回答

相关问题