问题是基于2篇文章：
– Basecamp Next 由DHH从37信号
– Advanced Caching in Rails by Adam Hawkins
– Basecamp Next 由DHH从37信号
– Advanced Caching in Rails by Adam Hawkins
我对使用俄罗斯娃娃缓存的性能影响有些困惑,具体来说：
>当使用自动到期键时,似乎每个请求都将导致访问数据库以获取对象时间戳 – 我是否缺少某些东西？ (我明白,在最好的情况下,你只能为层次结构中的顶级键执行,但是…)
>在第一篇文章中,他们缓存一个待办事项列表,以及每个待办事项.缓存列表是非常有意义的,因为它节省了大量的工作(对所有项目的数据库查询).但是为什么要缓存个别项目？您已经访问数据库以获取项目时间戳,所以您正在保存什么？生成几个html行？
>在第二篇文章中,亚当缓存了这样的观点：
缓存[post,’main-content’] …
缓存[post,’comments’]
当添加评论时,会更改帖子的时间戳,从而使两个角色无效.但是,主要内容没有改变 – 你不想重新生成它！如何才能使只有评论无效. (这实际上是一个非常常见的用户案例 – 一个具有逻辑上独立的部分的模型：对象本身,不同的关联,其他商店中的数据等)
对我来说,似乎俄罗斯娃娃缓存只有当你有一个深层层次的嵌套对象时才有意义(在basecamp你有项目 – > todos列表 – > todo – >项目列表).然而,如果你有一个浅层次结构,最好是自己做无效.
任何反馈将不胜感激！
谢谢.
解决方法
>顶层确实需要打数据库.您可以通过将时间戳记存储在一个单独的缓存条目中,通过模型和id键入来避免这种情况.对于第1条(Manuel F.Lara)的评论者之一也提出了这样一个建议：“有没有其他缓存像项目/ 15次,你总是拥有项目列表的最后一个时间戳？
>我认为你对嵌套的“最低”水平是正确的.您可能需要进行一些测试来查看DB访问的相对性能,而不是渲染小部分.
>另一个好点.根据rails文档,如果您传递一个符号：触摸它将更新该属性除了updated_at – 也许有一种方法可以跳过更改Post#updated_at,只更新一个列,如comments_updated_at.那么你可以使用后者进行缓存.但是,如果您尝试避免使用数据库访问,则必须为此时间戳记存储另一个缓存密钥(如上述#1中所示).
>我认为你对嵌套的“最低”水平是正确的.您可能需要进行一些测试来查看DB访问的相对性能,而不是渲染小部分.
>另一个好点.根据rails文档,如果您传递一个符号：触摸它将更新该属性除了updated_at – 也许有一种方法可以跳过更改Post#updated_at,只更新一个列,如comments_updated_at.那么你可以使用后者进行缓存.但是,如果您尝试避免使用数据库访问,则必须为此时间戳记存储另一个缓存密钥(如上述#1中所示).
我想你必须决定这一切是否值得你的麻烦.这两篇文章展示了简单,有创意的教学原理.在具有复杂关联的应用程序中,“代数”缓存方法可能更易于管理.
