哪个更好 - 使用RenderPartial输出缓存6个子操作或6个数据库查询?

时间:2014-05-08 19:22:24

标签: asp.net-mvc outputcache renderpartial renderaction

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

我正在考虑显示这些相关内容的两个选项,我想知道比我更有经验的开发人员会推荐一个比另一个更好吗?

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

选项1 - 输出缓存RenderAction结果

对于每个“类似内容”部分,在相应的控制器上呈现子操作并缓存输出。这更符合MVC的精神,并且对数据库调用很轻松。但是对于5个“类似内容”列表,每个页面请求将等于6个完整的MVC周期。

我已经阅读了RenderAction can still be expensive,即使是it has improved in the last couple of years

选项2 - 每个

的数据库查询的RenderPartials

或者,对于每个“类似内容”部分,我们可以查询数据库并使用RenderPartial来显示输出。虽然这需要对每个部分进行小型数据库查询(5项或更少),但我想知道如何与NOT调用RenderAction所节省的性能相比较。

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

1 个答案:

答案 0 :(得分:1)

基本上你的选择归结为速度更快:RenderAction已经缓存的结果或5个数据库查询?

当你以这种方式看待它时,你真的在​​谈论一个没有网络延迟的解决方案和一个具有网络延迟的解决方案(将查询发送到数据库并接收响应)。任何消除网络延迟的解决方案事实上都比具有网络延迟的替代方案更快。

另外,请记住,纯粹主义者喜欢谈论这样或那样的事情是什么?慢慢地"与其他方式相比。是的,子操作总是总是比部分慢,因为子操作遍历整个路由基础结构,然后最终到达Razor模板引擎,而部分只是直接进入Razor模板引擎。 但是,我们正在讨论在内存中运行的高度优化的编译代码。 "较慢"以毫秒或甚至纳秒为单位测量。当然,随着时间的推移,这些可能会增加,如果你在一个视图中做了像渲染50个孩子的动作那样疯狂的事情,你可能会看到一些明显的性能损失,但这通常不是一个值得担心的问题大约99.9999%的病例。

只需按照对您的应用程序最有意义的方式设计您的应用程序,并在这里或那里停止担心毫秒。