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瓶颈.达到实例的最佳值后,您需要增加运行此作业的实例数量或升级实例.

如果您的数据库或其他资源存在瓶颈,则需要相应调整. (不太可能是这样,但为了彻底的包含)

编辑：优化性能

为了回应您关于优化线程数量的问题,确定最优并发值的最快/最佳方法是更改​​并发性并测量实际吞吐量.还有其他的方法,但性能的黄金规则总是在现场生产环境中进行测量.合成的基准测试只能在镜像实时性能方面有所帮助. (参见：premature optimization).

这是一个你可以很容易地最终反思事情的情况(再次,反思是事物是发展中的常年问题).只需使用适当的度量标准(cpu利用率,内存利用率,每分钟完成的作业数量),并更改线程数,直到最大化吞吐量或遇到瓶颈.

如果您的任务是cpu限制,您将看到您的cpu利用率最大化.如果您的任务是I / O绑定,您将看到,即使您的cpu利用率不高,并发线程的增加也不会转化为吞吐量的增加.

当您读/写的任何资源无法跟上您的cpu需求时,就会发生I / O瓶颈.这包括系统资源(内存,磁盘空间),数据库性能(DB cpu利用率,读/写限制)以及您连接的其他API.网络容量也是一个理论上的瓶颈,但如果你是足够大的雇佣了这方面的经验的人.因为有这么多不同的方法可以实现,唯一真正的方法来确定瓶颈是什么是使您的监控到位.

Re：公式,简单的答案是在这种情况下没有一个可以使用的公式.很长一段时间的答案可能是肯定的,但是在收集您需要计算的所有值的过程中,您将达到最佳值.

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

我意识到我忘了增加一条建议.当您使用用户不等待的后台任务时,您的吞吐量(每单位时间的作业)是您唯一要优化的.不要为个别工作时间优化.这也意味着您无法分析当前(可能无限制)的性能并获得有用的数据,因为瓶颈/约束是目标依赖的.吞吐量存在的约束与单个任务时间的约束不同.

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