通過Rails API響應大量對象

Question

我目前有一個用於我的項目的API和一個負責將導出文件生成為CSV的服務，存檔並將它們存儲在雲中的某個位置。

由於我的API是用Rails編寫的，而我的服務是用純Ruby編寫的，因此我在服務中使用Her gem來與API進行交互。 但我發現我當前的實現性能較差，因為我在我的服務中執行了一個Model.all ，這反過來觸發了一個請求，該請求可能包含響應中太多的對象。

我很好奇如何改進這項整個任務。 這就是我的想法：

• 在API級別實現分頁並從我的服務調用Model.where(page: xxx) ;
• 在API級別生成實際CSV並將CSV發送回服務（這可以完成同步或異步）。

如果我使用第一種方法，每頁應該檢索多少個對象？ 回復應該有多大？

如果我使用第二種方法，這將給請求帶來相當大的開銷（我猜API請求不應該花那么長時間），我也想知道這是否真的是API的工作。

我應該遵循什么方法？ 或者，有什么比我更缺的東西？

Answer 1

你需要通過ruby過程傳遞大量信息，這總是不簡單，我不認為你在這里遺漏任何東西。

如果您決定在API級別生成CSV，那么維護服務會得到什么？ 您可以放棄服務，因為用nginx代理替換您的服務會更好地做同樣的事情（如果您只是從API主機傳輸響應）？

如果您決定分頁，肯定會有性能降低，但是沒有人可以准確地告訴您應該分頁多少 - 更大的頁面會更快並消耗更多內存（通過減少工作量來減少吞吐量），較小的頁面由於IO等待時間過長，速度會降低，內存消耗更少，但需要更多工作人員，

確切的數字將取決於您的API應用程序以及雲和您的基礎架構的IO響應時間，我擔心沒有人可以給您一個簡單的答案，您可以在沒有實驗壓力測試的情況下遵循，並且一旦您設置了壓力測試，無論如何，你會得到一些你自己的 - 比任何人估計的要好。

一個建議，寫一些關於你的問題，你正在努力的約束等等，也許有人可以幫助你一些更激進的解決方案。 出於某種原因，我覺得你真正想要的是像sidekiq或延遲工作這樣的后台處理器，或者如果你想要解耦你的應用程序或nginx，可以直接通過數據庫視圖將你的服務連接到數據庫API響應的代理，或者根本沒有...但是如果沒有更多信息，我真的無法分辨。

Answer 2

我認為這取決於您希望如何定義“效果”以及您的API目標。 您是否希望確保對API的請求響應時間不超過20毫秒，而添加分頁將是一種合理的方法。 特別是如果CSV生成只是一個邊緣情況，並且API實際上是為其他服務構建的。 然后，每頁的項目數量將受到您提供這些項目的速度的限制。 您的服務性能不會特別高（甚至更低），因為它需要多次調用服務。

如果您認為它是轉儲整個記錄集的服務的有效用例，那么創建異步調用（可能使用webhook作為回調）將值得添加到您的API。

話雖如此，我認為嚴格來說，API的工作是快速響應。 所以也許試着弄清楚緩存如何能夠改善響應時間，因此遍歷所有記錄是合理的。 另一方面，服務的工作是要注意對API的調用量，因此可能在本地存儲舊記錄並且僅輪詢更新而不是每次都轉儲整組記錄。