asp.net-mvc - RenderAction 与 RenderPartial 性能

Question

根据 Brad Wilson 的说法，RenderAction 比 RenderPartial 慢。

但是，有没有人得到任何显示性能差异的统计数据？

我正在开发一个应用程序，其中页面由“小部件”组成。

我有两个选择:

View 级别的合成

为每个小部件调用 RenderAction。这是迄今为止最简单的方法，但确实意味着我们正在为每个小部件执行一个完整的 MVC 循环。

Controller 级别的组合

为包含每个小部件所需数据的页面构建一个 ViewModel。为每个小部件调用 RenderPartial。这实现起来要复杂得多，但确实意味着我们只会制作一个 MVC 循环。

我在一个页面上用 3 个不同的小部件测试了上述方法，渲染时间的差异是十分之一秒(几乎不值得担心)。

但是，有没有人得到比这更具体的测试结果，或者是否有尝试过这两种方法的经验？

Answer 1

我最近研究了一个遇到性能问题的应用程序，并发现一个 View 对 RenderAction 进行了四次调用，另外还有一个在布局中。我发现对 RenderAction 的每次调用——即使我添加了一个返回空 View 的虚拟 Action ——花费了大约 200-300 毫秒(在我的本地机器上)。乘以调用次数，您就会在页面上获得巨大的性能提升。在我的例子中，有四次调用导致了大约一秒钟的不必要的服务器端开销。相比之下，对 RenderPartial 的调用大约在 0-10 毫秒的范围内。

我会尽可能避免使用 RenderAction 以支持 RenderPartial。控制者应负责返回所有必要的信息。在小部件的情况下，如果您需要多个小部件的多个 Action ，我会尝试将它们组合成一个 Action ，这样 RenderAction 开销只会发生一次，但如果您的网站性能良好，我会将它们分开以实现更简洁的设计。

编辑:我使用 MiniProfiler 收集了这些信息并访问了该站点。它不是非常准确，但它确实清楚地显示了差异。

编辑:正如 Oskar 在下面指出的那样，有问题的应用程序可能有一些密集的代码，这些代码针对 global.asax 中的每个请求运行。此命中的大小将取决于应用程序代码，但 RenderPartial 将完全避免执行另一个 MVC 循环。