pagy 和 kaminari gems 在性能上到底有什么区别，谁更好？

Question

• 在我们的项目中，我们使用 Kaminari 对所有内容进行分页，并且效果很好
• 有一个名为“pagy”的新 gem，在他们在 Github 上的 gem 存储库中，他们表示他们的性能比 kaminari 和 will-paginate 更好，但我不知道我们的项目是否真的更好地投入时间进行转换从 kaminari 到 pagy

所以我试着比较一下它和kaminari：

• 我运行了相同的查询，该查询将加载所有框，每页 1 个框和 page: 2 ，并检查了每个 gem 运行的查询，并检查了所需的时间

2.5.1 :043 > pagy(Box.all, items: 1, page: 2)
   (2.0ms)  SELECT COUNT(*) FROM "boxes"
  Box Load (1.0ms)  SELECT  "boxes".* FROM "boxes" LIMIT $1 OFFSET $2  [["LIMIT", 1], ["OFFSET", 1]]
 => [#<Pagy:0x00007fd7e88073a8 @vars={:page=>2, :items=>1, :outset=>0, :size=>[1, 4, 4, 1], :page_param=>:page, :params=>{}, :anchor=>"", :link_extra=>"", :item_path=>"pagy.info.item_name", :cycle=>false, :count=>106}, @count=106, @items=1, @outset=0, @page=2, @last=106, @pages=106, @offset=1, @from=2, @to=2, @prev=1, @next=3>, #<ActiveRecord::Relation [#<Box id: "2fbf947f-c0d8-4c02-9c71-22d7deaaff2e", shipping_request_id: "7dab8aba-961a-4d28-80c8-20b2fb9a63b7", created_at: "2019-03-14 18:22:33", updated_at: "2019-03-14 18:22:33", external_uuid: "b44f08ec-ccbc-424c-b0aa-4cbcbe94cd74", inventory_id: 78, dimension: {"length"=>4.5, "width"=>5.5, "height"=>5.6, "unit"=>"cm"}, weight: 56.6, label_url: nil, warehouse_state: "processing", proforma_url: nil, barcode: "EXOBOX-B44F08EC", proforma_name: nil, tracking_url: "", private_tracking: true, external_shipment_id: nil, state: "preparing", tracking_history: [{"status"=>"preparing", "datetime"=>"2019-03-14 20:22:33 +0200", "active"=>true, "order"=>0}, {"status"=>"pending_pick_up", "datetime"=>"", "active"=>false, "order"=>1}, {"status"=>"picked_up", "datetime"=>"", "active"=>false, "order"=>2}, {"status"=>"en_route_to_destination", "datetime"=>"", "active"=>false, "order"=>3}, {"status"=>"delivered", "datetime"=>"", "active"=>false, "order"=>4}], parent_id: nil, tracking_number: "EXOTRACK-B44F08EC">]>] 
2.5.1 :044 > Box.all.page(2).per(1)
  Box Load (1.0ms)  SELECT  "boxes".* FROM "boxes" LIMIT $1 OFFSET $2  [["LIMIT", 1], ["OFFSET", 1]]
 => #<ActiveRecord::Relation [#<Box id: "2fbf947f-c0d8-4c02-9c71-22d7deaaff2e", shipping_request_id: "7dab8aba-961a-4d28-80c8-20b2fb9a63b7", created_at: "2019-03-14 18:22:33", updated_at: "2019-03-14 18:22:33", external_uuid: "b44f08ec-ccbc-424c-b0aa-4cbcbe94cd74", inventory_id: 78, dimension: {"length"=>4.5, "width"=>5.5, "height"=>5.6, "unit"=>"cm"}, weight: 56.6, label_url: nil, warehouse_state: "processing", proforma_url: nil, barcode: "EXOBOX-B44F08EC", proforma_name: nil, tracking_url: "", private_tracking: true, external_shipment_id: nil, state: "preparing", tracking_history: [{"status"=>"preparing", "datetime"=>"2019-03-14 20:22:33 +0200", "active"=>true, "order"=>0}, {"status"=>"pending_pick_up", "datetime"=>"", "active"=>false, "order"=>1}, {"status"=>"picked_up", "datetime"=>"", "active"=>false, "order"=>2}, {"status"=>"en_route_to_destination", "datetime"=>"", "active"=>false, "order"=>3}, {"status"=>"delivered", "datetime"=>"", "active"=>false, "order"=>4}], parent_id: nil, tracking_number: "EXOTRACK-B44F08EC">]> 
2.5.1 :045 > 

他们也在运行相同的查询（无论从框查询中选择计数），所以我怎样才能发现它们之间的区别，以及谁更好，感觉它们都是一样的，知道我们正在使用他们在一个 API 项目中

Answer 1

优势程度取决于您在 API 中使用分页的方式。您在 API 响应中打包的分页信息越多，Pagy 就越方便。

从DB的角度来看，如果使用需要计算集合计数的经典分页，在查询时间上是没有区别的。不可能，因为所有分页 gem 都需要执行相同的 2 个查询：一个用于获取计数，另一个用于获取结果页面。

所以在这种情况下，改进不在查询中...除非您的 API 不需要在响应中添加结果总数，例如如果您只需要获取结果页面以及上一个、下一个等的链接，那么您可以使用 pagy countless extra 完全避免计数查询，这可能是一个巨大的改进。

与其他 gem 相比，使用 Pagy 的一大优势在于，它不仅计算速度快了很多倍（使用 Kaminari，每次渲染很容易浪费 20 毫秒，具体取决于设置），而且它使用了一小部分其他宝石所需的内存。这意味着它对服务器来说是一个很大的负载缓解，尤其是在您的应用程序流量很大的情况下。在正常的 UI 条件下，它的效率比 Kaminari 高出数百倍，在 API 条件下，即使响应中的分页信息很少，它也应该比 Kaminari 高出数十倍。

有一个migration guide 应该使从遗留 gem 的迁移变得非常简单。如果您的 Kaminari 使用是标准的，则只需几分钟（主要是搜索和替换）。如果您对 Kaminari 进行了猴子补丁或以奇怪的方式使用它（可能没有使用 API），您可能需要阅读更多 Pagy 文档或请求 live support。

对于你的API，你也可以看看headers extra，它封装了分页需要的API。

仅供参考：如果您使用带有 UI 助手的 ruby​​ 2.0+，Pagy v3（即将推出）将进一步提高速度和亮度（明显更多）。它仍然缺少 API 的基准测试，但它肯定会额外改进标头。