哪个更好 - 输出缓存6个子操作或使用RenderPartial的6个DB查询？

Question

我正在尝试开发一个使用标签来显示类似内容的cms系统。例如，在新闻栏目下面会有文章，博客，新闻和论坛问题共享相同的标签。每个列表中不会超过5个项目。

我正在考虑显示这个相关内容的2个选项，并且想知道比我有更多经验的开发人员会推荐一个吗？

速度是主要目标，因为我们拥有同样可维护的方式来执行这两个选项。

选项1 - 输出缓存结果的RenderAction

对于每个“类似的内容”部分，使得相应的控制器上的儿童动作并缓存输出。这种感觉更像MVC的精神，对数据库调用会很轻松。但是对于5个“相似内容”列表，对于每个页面请求，这将等于6个完整的MVC周期。

我读过RenderAction can still be expensive，即使it has improved in the last couple of years。

选择2 - 用DB查询RenderPartials为每个

可替代地，对于每个“类似的内容”部分中，我们可以查询数据库，并使用的RenderPartial以显示输出。虽然这将需要每个部分的小数据库查询（5个或更少），但我想知道如何与通过不调用RenderAction保存的性能进行比较。

我经常阅读how much faster RenderPartial is compared to RenderAction。

Answer 1

本质上你的选择归结为哪一个更快：RenderAction已经缓存结果或5个数据库查询？当你这样看的时候，你确实在谈论一个没有网络延迟的解决方案和一个带有网络延迟的解决方案（发送查询到数据库并接收响应）。消除网络延迟的任何解决方案实际上比网络延迟的替代方案更快。

另外，请记住，纯粹主义者喜欢谈论某个方面或另一个方面比其他方式“慢”。是的，子动作总是会比分支慢，因为子动作遍历整个路由基础结构，然后到达Razor模板引擎，而部分则直接进入Razor模板引擎。 但是，我们正在讨论在内存中运行的高度优化的编译代码。 “较慢”以毫秒或甚至纳秒为单位进行测量。当然，这些可以随着时间的推移累加起来，如果你做了一些疯狂的事情，比如在一个视图中呈现50个子动作，你可能会看到一些明显的性能损失，但这通常不是一个值得担心的问题，在99.9999％的案例。

只需以最适合您应用程序的方式设计您的应用程序，并且不必担心这里或那里有毫秒。