如何在将shoryuken用于后台作业时确定并发(线程)?

Tar*_*ani 13 concurrency multithreading ruby-on-rails background-process shoryuken

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

Ric*_*ora 6

并发默认为25,但可以通过更改shoryuken.yml配置(见下文)或通过添加并发参数来更改: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]
Run Code Online (Sandbox Code Playgroud)

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

如果瓶颈存在于您的数据库或其他资源上,则需要相应地进行调整.(不太可能是这种情况,但为了彻底而包括在内)

编辑:优化性能

在回答有关优化线程数的问题时,确定最佳并发值的最快/最佳方法是更改​​并发性并测量实际吞吐量.还有其他方法,但性能的黄金法则总是在实时生产环境中进行衡量.合成基准仅在它们反映实时性能的范围内有所帮助.(另见:过早优化).

在这种情况下,你可以很容易地结束过度思考(然后再次,过度思考事物是一个长期存在的问题).只需使用适当的指标(CPU利用率,内存利用率,每分钟完成的作业数)进行测量,然后更改线程数,直到最大化吞吐量或遇到瓶颈为止.

如果您的任务受CPU限制,您将看到最大的CPU利用率.如果你的任务是I/O绑定的,你会发现,在某些时候,并发线程的增加并没有转化为吞吐量的增加,即使你的CPU利用率没有上升.

当您正在读/写的任何资源无法满足您的CPU需求时,就会发生I/O瓶颈.这包括系统资源(内存,磁盘空间),数据库性能(DB CPU利用率,读/写限制)以及您要连接的其他API.网络容量也是一个理论上的瓶颈,但如果它足够大,你就可以聘请有这方面经验的人.因为有很多不同的方法可以实现这一点,所以找出瓶颈的唯一真正方法就是让您的监控到位.

Re:公式,简短的回答是,在这种情况下你没有可以使用的公式.很长的答案可能是肯定的,但是在收集计算它所需的所有值的过程中,你会得到最佳值.

编辑2:并发,延迟和吞吐量

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

(从技术上讲,你的并发设置是你当前的约束)