13

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

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

系统工作如下：

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

关于基础设施：

  • 运行此任务队列的 Redis 服务器专用于它。此外，持久性被禁用。它在 4 GB Rackspace 服务器上运行。
  • 在带有任务队列的服务器上运行redis-benchmark时，大多数基准测试的平均结果超过 20000 r/s。

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

4

1 回答 1

0

12 秒？疯了吧。

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

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

于 2013-03-24T01:37:10.123 回答