我正在运行一个web应用程序，该应用程序在AWS上运行芹菜。然而，所有工作进程都在一个私人数据中心(校园超级计算机(中运行。我有34个独立的工作进程在运行以消耗作业，用于代理和后端的rabbitmq和Redis实例存在于我的EC2实例中的AWS上。
上个月，我震惊地发现，在没有向应用程序提交作业的情况下，我在托管rabbit和Redis的EC2实例上仍然使用了近700GB的网络带宽(仅限传出流量！(。这种流量完全是由celenite工作程序与rabbit实例的开销通信引起的。尽管没有实际的计算作业要处理，但每秒仍有近17条消息被发送到每个工作实例。
我的任务是长时间运行的(至少是几秒钟，有时是几分钟(，繁重的计算工作，所以任务检索的高延迟是完全可以接受的——以秒为单位的时间尺度是可以的。理想情况下，我想告诉我的芹菜员工每隔几秒钟检查一次新任务，并停止所有其他网络开销通信。
有没有办法减少芹菜工人的总体网络开销？
根据CloudAMQP上的这篇文章，除了其他设置外，他们还建议运行具有以下三个标志的工作程序，以限制工作程序的聊天次数：
celery -A my_celery_app worker --without-heartbeat --without-gossip --without-mingle
这个问题，以其他形式提出，似乎在这里对堆栈溢出进行了一些讨论。
Celery文档在这些标志上的不透明性非常糟糕。这里有一些关于心跳的信息。
在使用iptraf(此处快速概述(对自己进行了一些分析之后，我了解到--without-gossip标志可以将芹菜开销减少95%。八卦功能似乎为所有工作人员订阅了所有其他与工作人员相关的事件，如心跳和时钟同步。这将创建一条N^2比例曲线，其中N是工人数量。这很快就产生了大量的网络聊天，除非你自己编写了利用八卦功能的代码，否则所有这些交流似乎都是完全没有必要的。
我的分析证实，--without-mingle只减少了员工启动通信，但对长期网络开销没有影响。
心跳确实会消耗一些网络开销。令人惊讶的是，在34个工作人员和120秒的broker_heartbeat和3.0的broker_heartbeat_checkrate的情况下，我仍然会为这些心跳检查生成21GB/月的网络开销(粗略分析(。我不清楚从文档中禁用它们对应用程序的影响——如果代理不可用，工作人员会检测到吗？我通过杀死我的RabbitMQ实例并监视工作日志(通过--without-heartbeat的工作日志(自己进行了基本检查。他们似乎能很快(在几秒钟内(检测到代理的丢失，并且在我重新启动代理后立即重新连接。因此，我的基本观察表明，不需要心跳来维持芹菜工人的普遍预期行为。那么心跳的意义在哪里呢？我不清楚。
以上三个标志似乎通过消除所有多余的消息传递来减少所有不必要的工作网络开销。在没有启用这些功能的情况下，芹菜工人的行为通常与预期一致。