用于分页的 Memcache
这在实施上感觉是一个非常糟糕的主意，考虑到潜在的内存成本，我不确定是否可以节省速度。
使用 Dalli 和 Memecache 存储一组数据，这些数据在每个需要分页的页面请求上提取。它有很多数据，所以如果可能的话，我真的不想继续访问数据库，但我也不知道这个操作对于内存来说有多昂贵，无论是在内存缓存中还是在系统内存中。为了分页，我基本上执行以下操作：
- 调用 memcache 以查看给定数据是否存在
- 如果找到，则获取数据并转到 4。
- 如果未找到，则从数据库获取并缓存
- Dup 对象，因为对象已冻结。 ?? <-- 似乎是一个非常糟糕的主意...
- 返回分页数据进行显示。
WillPaginate 必须对来自数据库的数据集执行操作，但它会抛出“无法修改冻结”对象”错误。
这有多糟糕？ dup-ing 一个大对象（它被缓存以节省调用数据库的时间）似乎最终会消耗大量额外的内存并运行 GC 比需要的更多。有人建议一些解决这个问题的方法吗？
This feels like a really bad idea on implementation and I'm not sure of the speed savings given the potential cost in memory.
Using Dalli and Memecache to store a set of data that gets pulled on every page request that needs to be paginated. Its a lot of data so I'd really rather not keep hitting the database if possible, but I also don't know how expensive this operation is for memory, both in memcache as well as just in system memory. To paginate, I do basically the following:
- Call to memcache to see if given data exists
- If found, get data and go to 4.
- If not found, get from database and cache
- Dup object because object is frozen. ?? <-- seems like a really bad idea...
- Return paginated data for display.
WillPaginate has to perform actions on the dataset coming out of the DB but it throws a "can't modify frozen object" error.
How much bad is this? dup-ing a large object (which is cached to save time in calls to the db) seems like it will end up chewing up a lot of extra memory and run the GC a lot more than needs be. Anyone suggest some ways around this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您还可以缓存渲染的 html，而不是在模型/列表视图中处理对象。您甚至可以预先缓存内容以获得额外的提升:)
Instead of working with the objects at a Model / List view, you can also cache the rendered html. You can even pre-cache the contents for an extra boost :)