Python RQ 的作业推送性能不理想答案

【问题标题】：Unsatisfactory job push performance with Python RQPython RQ 的作业推送性能不理想
【发布时间】：2013-03-11 21:57:18
【问题描述】：

尝试使用python-rq 支持我们的 Web 应用程序的后端，但推送新作业需要很长时间 - 最多 12 秒。

执行enqueue_call 函数调用时会出现性能下降，尤其是当连接到系统的工作进程数量增加（超过200 个）时。

系统工作如下：

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

关于基础设施：

在这种情况下，我们如何提高新工作的推送性能？我们应该使用更好的模式吗？

【问题讨论】：

切换（到芹菜）是否显着提高了性能？我遇到了同样的问题。
我目前不在同一个项目上工作。然而，我们确实继续使用rq 作为后端，随着我们清理基础设施，性能问题最终得到解决。对于您的特定用例，我不建议切换到celery 或保留rq；但是，我会建议运行测试。它可能没有您最初想的那么难，而且我保证花费在创建良好测试上的任何时间最终都会得到回报，因为您会更好地了解系统的性质。祝你好运！

【解决方案1】：

12 秒？这太疯狂了。

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

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

【讨论】：