15

在我的 Ruby on Rails 应用程序中，我使用shoryouken进行后台处理。我的应用程序中有很多 sqs 队列（6-7）。其中一个队列有 2000-3000 个作业，worker 处理这 2-3k 个作业大约需要 3 个小时，默认并发为 25。所以我们可以根据哪些因素决定增加并发数（即线程来处理作业）。如果问题中有任何不清楚的地方，请发表评论。

4

2 回答 2

7

Concurrency 默认为 25，但可以通过更改shoryuken.yml配置（见下文）或添加 concurrency 参数来更改：shoryuken -c {desiredCount}

concurrency: 25  # Update with your desired value.
delay: 25        # The delay in seconds to pause a queue when it's empty. Default 0
queues:
  - [high_priority, 6]
  - [default, 2]
  - [low_priority, 1]

您将需要测试性能的最佳值，因为随着并发线程数量的增加，您将遇到 I/O 和 CPU 瓶颈。达到实例的最佳值后，您需要增加运行此作业的实例数量或升级实例。

如果瓶颈存在于您的数据库或其他资源上，则需要相应地对其进行调整。（不太可能是这种情况，但为了彻底起见包括在内）

编辑：优化性能

针对您关于优化线程数的问题，确定最佳并发值的最快/最佳方法是更改​​并发并测量实际吞吐量。还有其他方法，但性能的黄金法则始终是在实时生产环境中进行测量。综合基准​​仅在反映实时性能的情况下才有用。（另请参阅：过早优化）。

在这种情况下，您很容易最终过度思考事物（再说一遍，过度思考事物是开发中的一个长期问题）。只需使用适当的指标（CPU 利用率、内存利用率、每分钟完成的作业数）进行测量，然后更改线程数，直到您最大化吞吐量或遇到瓶颈。

如果您的任务受 CPU 限制，您会看到 CPU 利用率达到最大值。如果您的任务受 I/O 限制，您会发现在某个时间点之后，并发线程的增加不会转化为吞吐量的增加，即使您的 CPU 利用率没有上升。

当您正在读取/写入的任何资源无法满足您的 CPU 需求时，就会发生 I/O 瓶颈。这包括系统资源（内存、磁盘空间）、您的数据库性能（数据库 CPU 利用率、读/写限制）以及您正在连接的其他 API。网络容量也是一个理论上的瓶颈，但如果是这样，你就足够大，可以聘请在这方面有经验的人。因为发生这种情况有很多不同的方法，所以找出瓶颈所在的唯一真正方法是进行监控。

回复：公式，简短的回答是在这种情况下没有一个公式可以使用。长答案可能是肯定的，但是在收集计算它所需的所有值的过程中，您会达到最佳值。

编辑 2：并发、延迟和吞吐量

我意识到我忘了再补充一条建议。当您处理用户没有等待的后台任务时，您的吞吐量（每单位时间的作业）是您想要优化的唯一内容。不要针对个人工作时间进行优化。这也意味着您无法分析当前（并且可能是未绑定的）性能并获得有用的数据，因为瓶颈/约束取决于目标。吞吐量存在的约束与单个任务时间存在的约束不同。

（从技术上讲，您的并发设置是您当前的约束）

于 2017-02-18T23:07:18.147 回答
1

三个主要因素是

  1. 核心数
  2. 作业类型 - I/O 或 CPU 限制
  3. 服务器上是否有另一个应用程序或进程正在运行

理想情况下，对于 cpu 绑定任务，保持线程数到 cpu 内核数。

对于 I/O 绑定任务，它需要基准测试和计算 I/O 的等待时间，然后您可以确定最佳值。如果您有 4 个内核而不是 I/O 绑定任务，则粗略估计您必须保持最多 8 个线程。

如果您的 Rails 应用程序在同一台上运行，那么您将需要减少内核数量。

如果您的系统不支持，增加核心数量不会提高您的性能。

参考：http ://baddotrobot.com/blog/2013/06/01/optimum-number-of-threads/

于 2017-02-14T07:49:47.297 回答