Python RQ令人不满意的作业推送性能

Question

试图用来python-rq支持我们的Web应用程序的后端,但推动新的工作需要很长时间 - 最多12秒.

执行enqueue_call函数调用时会发生性能损失,特别是当连接到系统的工作进程数增加(超过200)时.

系统工作原理如下:

1. 前端将作业推送到任务队列服务器.enqueue_call除了要执行的函数的实际参数之外,它还使用函数将参数传递给作业(例如timeout和ttl).
2. 多个进程(分布在多台机器上)正在运行工作程序,每个进程都在UNIX下运行screen.工作人员遵循文档中提供的模式,执行Worker.work()无限循环函数来侦听队列.
3. 在处理过程中,一些任务会产生新的任务,通常在它们运行的​​同一队列上.

关于基础设施:

• 运行此任务队列的Redis服务器专用于它.此外,禁用持久性.它运行在4 GB Rackspace服务器中.
• 在redis-benchmark具有任务队列的服务器上运行时,对于大多数基准测试,我们得到的结果平均超过20000 r/s.

在这种情况下,我们如何才能提高新工作的推动绩效？我们应该使用更好的模式吗？

Answer 1

12秒？疯了吧。

你考虑过用芹菜吗？
从未使用过 redis-rq，但从我根据文档看到的情况来看，这对于大量工作人员来说并不是很好
Redis 队列通常基于 BLPOP 命令，它可以与多个客户端一起工作，但谁知道它可以真正为一个客户端处理多少钥匙。

所以我建议你切换到 Celery 或为 python-rq 编写自己的任务分配器，这不会比切换更容易