какая разница в производительности между драгоценными камнями pagy и kaminari, и кто лучше? - PullRequest
Новая
       74

какая разница в производительности между драгоценными камнями pagy и kaminari, и кто лучше?

1 голос
/ 04 апреля 2019
  • в нашем проекте мы используем Kaminari для нумерации страниц, и он работает довольно хорошо
  • есть новый гем под названием 'pagy', и в своем репозитории на Github они заявили, что их производительность лучше, чем у kaminari и will-paginate, но я не знаю, действительно ли лучше для нашего проекта тратить время на конвертацию от каминари до пагы

поэтому я попробовал сравнить его с каминари:

  • Я запустил один и тот же запрос, который загрузит все ящики с 1 полем на страницу, и страницу: 2, проверил запросы, которые выполнялись каждым драгоценным камнем, и проверил время, которое требуется 
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

1 Ответ

3 голосов
/ 10 апреля 2019

Уровень преимуществ зависит от того, как вы используете нумерацию страниц в своем API.Чем больше информации о нумерации страниц вы добавляете в ответ API, тем удобнее будет Pagy.

С точки зрения БД, если вы используете классическую нумерацию страниц, для которой необходимо рассчитать количество сборов, разницы нетво время запроса.И этого не может быть, так как все гемы нумерации страниц должны всегда выполнять одни и те же 2 запроса: один для получения количества и другой для получения страницы результатов.

Так что в этом случае улучшение не взапросы ... ЕСЛИ вашему API не нужно добавлять общее количество результатов в ответ, например, если вам просто нужно получить страницу результатов и ссылки для предыдущего, следующего и т. д., тогда вы можете полностью избежатьподсчитать запрос, используя pagy бесчисленное количество дополнительных , и это может быть огромным улучшением.

Большое преимущество использования Pagy перед другими драгоценными камнями состоит в том, что он не только во много раз быстрее выполняет свои вычисления (выможет легко тратить 20 мс на рендеринг с Kaminari, в зависимости от настроек), но также из-за того, что он использует небольшую долю памяти, необходимую для других драгоценных камней.Это означает, что это значительно облегчает нагрузку на сервер, особенно если в вашем приложении большой трафик.Его эффективность в сотни раз выше, чем у Kaminari в нормальных условиях пользовательского интерфейса, и в условиях API она должна быть еще в десятки раз больше, даже при минимальной информации о разбиении на страницы в ответе.

Существует миграция руководство , которое должно сделать переход с устаревших самоцветов довольно простым.Если ваше использование Kaminari является стандартным, это займет всего несколько минут (в основном поиск и замена).Если вы запатентовали Kaminari или использовали его странным образом (вероятно, не с помощью API), вам, возможно, придется прочитать еще несколько документов на Pagy или попросить live support .

для вашего APIВы также можете взглянуть на дополнительные заголовки , которые включают в себя потребности API для разбивки на страницы.

К вашему сведению: Pagy v3 (который скоро выйдет) улучшит скорость и легкость дажебольше (заметно больше), если вы используете ruby ​​2.0+ с помощниками пользовательского интерфейса.По-прежнему отсутствуют эталонные тесты для API, но это, безусловно, улучшит заголовки.

...