解决方法
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：并发,延迟和吞吐量
我意识到我忘了增加一条建议.当您使用用户不等待的后台任务时,您的吞吐量(每单位时间的作业)是您唯一要优化的.不要为个别工作时间优化.这也意味着您无法分析当前(可能无限制)的性能并获得有用的数据,因为瓶颈/约束是目标依赖的.吞吐量存在的约束与单个任务时间的约束不同.
(从技术上讲,您的并发设置是您当前的约束)
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。