我有一个 tinder 风格的应用程序，允许用户对事件进行评分。在用户对某个事件进行评分后，会运行一个后台 resque 作业，该作业会根据用户的反馈对其他事件进行重新排序。
此后台作业大约需要 10 秒，每个用户每分钟运行大约 20 次。
使用一个简单的例子。如果我有 10 位用户在任何给定时间使用该应用，并且我不想让工作等待，那么执行此操作的最佳方法是什么？
我对 Dynos、resque 池和 redis 连接感到困惑。有人可以帮我理解其中的区别吗？有没有办法计算这个？
【问题讨论】：
标签： ruby-on-rails heroku resque
Dynos：这些是单独的虚拟/物理服务器。将它们视为与 EC2 实例相同。
Redis 连接：与 Redis 实例的单独连接。
Resque Pool：一个允许您在同一个测功机/实例上同时运行工作人员的 gem。
【讨论】：
首先，有必要寻找可以提高工作本身绩效的方法。通过使用低级模型缓存或优化算法，您可能能够将其缩短到 10 秒以内。
要计算出您需要多少工作人员，您需要计算每分钟的运行次数 (20) 乘以运行所需的秒数 (10) 乘以用户数 (10)。这将为您提供在一名工作人员上运行所需的每分钟秒数。 20 * 10 * 10 = 2000。将其除以 60，得到每分钟的分钟数，33.3。因此，如果您有 34 名工人，并且这些数字都是一致的，那么他们应该能够掌控一切。
也就是说，对于排名算法，您不应该只需要为 10 个并发用户运行 36 个或更多测功机。这很快就会变得昂贵。
优化您的算法，尝试添加更多缓存，并尝试使用 Sidekiq。根据我的经验，Sidekiq 处理队列的速度比 Resque 快 10 倍。这取决于您的工作是什么，以及您如何使用每个工具，但值得一试。见Sidekiq vs Resque。
【讨论】：
不确定您提出的问题是否正确。您真正的问题是“我怎样才能获得更好的性能？”不是“有多少测功机？”仅添加测功机不一定会给您带来更好的性能。更多的测功机给你更多的内存......所以如果你的应用程序运行缓慢，因为你的可用内存不足（即你正在交换运行），那么更多的测功机可能是答案。如果这些作业每次运行需要 10 秒，但是……内存可能不是您的实际问题。如果您想监控内存使用情况，请查看 New Relic 等可视化工具。
有很多方法可以解决您的问题。但我将从您编写的代码开始。在 SO 上发布一些代码可能有助于理解为什么这项工作需要 10 秒（发布一些代码！）。 10秒是很长的时间。因此，优化该作业中的查询几乎肯定会有所帮助。
另一个低调的果实...从 resque 切换到 sidekiq 以完成您的后台工作。真的很容易使用。您将使用更少的内存，并且应该会立即看到性能提升。
【讨论】：
对其他事件重新排名是个坏主意。
您应该考虑为 events 表设置 total_points 和 average_points 列，并让排名由查询的顺序决定。像这样。
class Event
has_many :feedbacks
scope :rank_by_total, -> { order(:total_points) }
scope :rank_by_average, -> { order(:average_points) }
end
class Feedback
belongs_to :event
after_create :update_points
def update_points
total = event.feedbacks.sum(:points)
avg = event.feedbacks.average(:points)
event.update(total_points: total, average_points: avg)
end
end
那么，您需要多少工人/测功机？
您无需为这个问题担心测功机或工作人员。无论您使用多少具有更高处理能力的测功机，当您的事件表变得庞大时，您的解决方案都将花费大量时间。因此，请尝试按照我描述的方式更改您的解决方案。
【讨论】：