Python RQ作业推送性能不佳

Question

我正在尝试使用 python-rq 来支持我们的网页应用的后端，但添加新任务的速度非常慢，有时需要长达12秒。

这个性能问题主要出现在调用 enqueue_call 函数的时候，尤其是当连接到系统的工作进程数量增加到200个以上时。

系统的工作原理如下：

1. 前端将任务推送到任务队列服务器。这是通过 enqueue_call 函数来传递任务的参数（比如超时和存活时间），还有要执行的函数的实际参数。
2. 多个进程（分布在几台机器上）在运行工作者，每个工作者都在一个 UNIX screen 下。工作者按照文档中的模式运行，执行 Worker.work() 的无限循环函数来监听队列。
3. 在处理过程中，有些任务会生成新的任务，通常是在它们正在运行的同一个队列上。

关于基础设施：

• 运行这个任务队列的 Redis 服务器是专门用来做这个的。而且，持久化功能是关闭的。它运行在一个4GB的 Rackspace 服务器上。
• 在这个任务队列的服务器上运行 redis-benchmark，大多数基准测试的结果显示平均每秒超过20000次请求。

在这种情况下，我们该如何提高新任务的推送性能呢？有没有更好的模式可以使用？

Answer 1

12秒？这也太疯狂了。

你有没有考虑过使用celery？
我没用过redis-rq，但从文档上看，它似乎不太适合处理大量的工作任务。
Redis队列通常是基于BLPOP命令的，这个命令可以和多个客户端一起工作，但谁知道它对于一个键到底能处理多少呢。

所以我建议你换成Celery，或者自己写一个任务分发器给python-rq，这样做可能也不会比换成Celery简单。