ruby-on-rails - 通过Rails API响应大量对象

Question

我目前有一个项目的API，以及一个负责将导出文件生成为CSV，将其归档并存储在云中的服务。

因为我的API是用Rails编写的，而我的服务是用纯Ruby编写的，所以我在服务中使用了Her来与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分离，也许可以通过数据库 View 将服务直接连接到数据库。代理API响应，或者根本不做任何事情……但是，如果没有更多信息，我真的无法分辨。