【发布时间】：2011-09-07 19:46:43
【问题描述】：
我正在使用 admin_assistant 并且已经破解了 MongoDB 支持。现在唯一的问题是索引页面查询非常慢。 admin_assistant 将 will_paginate 用于这些查询。我验证了确切的减速点是第一次访问将分页集合的位置（.empty？）。在日志中我看到了查询，然后我看到这些正在慢慢打印：
MONGODB cursor.refresh() 用于游标 3474711247518436755 MONGODB cursor.refresh() 用于游标 3474711247518436755 MONGODB cursor.refresh() 用于游标 3474711247518436755 MONGODB cursor.refresh() 用于游标 3474711247518436755 MONGODB cursor.refresh() 用于游标 3474711247518436755 MONGODB cursor.refresh() 用于游标 3474711247518436755 MONGODB cursor.refresh() 用于游标 3474711247518436755 MONGODB cursor.refresh() 用于游标 3474711247518436755 MONGODB cursor.refresh() 用于游标 3474711247518436755 MONGODB cursor.refresh() 用于游标 3474711247518436755接下来我可能会尝试摆脱 will_paginate，但其余代码现在取决于它。关于什么可能导致光标刷新的任何想法？
【问题讨论】：
-
当从 mongodb 获取的结果过多时，您会看到此消息。默认情况下 mongodb 将在 2 分钟后关闭游标，如果客户端仍然没有在这段时间内获取所有数据。我的猜测是生成的查询最终是一个 mongoid 条件对象，它没有
empty?方法，所以调用空？在它上面触发获取结果并产生文档数组。您应该将其发布到 will_paginate 或 mongoid 列表，同时破解criteria#empty?以测试criteria#count(true) == 0 -
什么时候我摆脱了 .empty？我看到了相同的行为形式.each。我在每个请求上都看到了这个，大约需要 3 秒。我会试试 Mongoid 邮件列表。
-
each将具有与empty?相同的行为，如果我的猜测是正确的，您应该尝试count看看它是否也会导致相同的情况（它不应该）。跨度> -
will_paginate 和 admin_assistant（看起来）都不支持开箱即用的 MongoDB。我看不出这里有什么大惊喜。在某处，mongo 分页以未优化的方式执行。但是，如果 Kaminari 为您工作，则没有必要进一步调查。
-
我也遇到过这个问题；有没有办法让 will_paginate 以合理的性能支持 MongoDB？
标签： mongoid will-paginate