通过 Rails API 响应大量对象

Question

我目前有一个用于我的一个项目的 API 和一项服务，该服务负责将导出文件生成为 CSV、存档并将它们存储在云中的某个位置。

由于我的 API 是用 Rails 编写的，而我的服务是用纯 Ruby 编写的，所以我在服务中使用 Her gem 与 A​​PI 进行交互。但是我发现我当前的实现性能较差，因为我在我的服务中做了一个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 的调用量，因此可能会在本地存储旧记录并仅轮询更新，而不是每次都转储整个记录集。