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编写自己的任务分配器，这样切换后会更容易