如何优化rails上的计算密集型请求响应[重复]答案

【问题标题】：How to optimise computation intensive request response on rails [duplicate]如何优化rails上的计算密集型请求响应[重复]
【发布时间】：2016-07-31 12:20:58
【问题描述】：

我有一个应用程序，它在几个页面（请求）上进行大量计算。 Web 界面发送 AJAX 请求。计算有时需要大约 2-5 分钟。问题是，此时 AJAX 请求超时。

我们当然可以增加门户网站的超时时间，但这听起来不是正确的解决方案。此外，为了提高性能：

删除了 N+1/重复查询
实现缓存

这里还可以做些什么来减少计算时间？

另外，如果还需要更长的时间，我正在考虑以下解决方案：

预先进行计算并将其存储在数据库中。所以当实际请求来的时候，就不需要计算了。（对这种方法感到担忧。因为我们将不得不修改/擦除并重新计算这些数据，只要有一些应用程序逻辑发生变化。）
当应用程序启动/数据被修改时，将整个数据加载到缓存中。但是第一次必须进行计算。此外，当应用程序启动时，不能将整个数据保存在缓存中。所以需要根据需要将其存储在缓存中。
也许，做一些像 Angular promise 这样的事情，当响应来自服务器时，promise 就会得到满足。

我们有没有其他方法可以有效地做到这一点？

更新：根据用户输入，计算可能会在几秒钟内发生。而且可能需要2-5分钟。场景是，用户导入一个 excel。 excel已被解析并保存在数据库中。现在在另一个页面上，用户希望查看对导入数据（已通过后台作业保存到数据库）进行少量计算得出的报告/分析图。计算必须与许多因素一起完成，因此不想将其保存在 DB 中（如上所述）。此外，当用户请求报告/分析图表时，告诉他图表将在某个时间后显示是不好的体验。您将收到电子邮件/通知等。

【问题讨论】：

可以并行处理任何计算吗？ Ruby 的并发 gem 比较容易使用，并且可以使用并发线程来提高性能。
必须检查一下。但是整个计算结果必须合并然后作为响应发送。另一件事是，我们如何优化查询，因为我们必须从许多表中获取数据。每个并行进程会单独查询吗？

标签： ruby-on-rails performance ruby-on-rails-4 caching elasticsearch

【解决方案1】：

非常典型的解决方案是将作业入队进行后台处理，并将作业ID返回给前端。然后，您的前端可以使用该作业 ID 轮询是否完成，或者您可以触发通知，例如在作业完成时向用户发送电子邮件。

这方面有很多优点，而且它是如此受欢迎和被接受的解决方案，Rails 专门为此目的推出了自己的ActiveJob。

【讨论】：

谢谢。我知道后台工作。但是我们需要实时显示数据。 :( 另一种选择是，基于轮询，一旦成功，使用另一个请求获取数据。
您现在没有显示“实时”数据，如果您的请求需要 5 分钟然后超时。延迟作业是正确的解决方案。
谢谢。反正我以为你会明白的！我的意思是“实时”，我需要向用户显示数据。不能依赖电子邮件/通知。更新问题！
@Indyarocks 是的，您可以为此使用延迟作业：“然后您的前端可以轮询完成”。
elasticsearch 能帮上忙吗？

【解决方案2】：

以下是一些可能的解决方案：

使用索引优化表以减少数据提取时间。
在开始时预加载您将要处理的所有行，因此您不会在每次计算时都进行查询...@things.select { |r| 更快/更容易r.blah } 比 Thing.where(conditions)
除了所有这些，只需在数据库端使用 PLSQL 进行计算。当然，这与编写 Ruby 代码不同，但它可以更快。
是的，将整个结果集缓存到 memcache 或 redis 或其他东西中（并在发生变化时过期）
在后台运行计算（crontab？）并将结果以 JSON 格式存储在某处，或者缓存整个 HTML 文件（如果您没有进行本地化或其他任何操作）

PS：我正在为大约 12 个表中的几 M 条记录执行 1、2、3 和 5（将 JSON 结果缓存到内存缓存中，然后拉出数组并格式化/本地化）......主要是体育数据。

【讨论】：