芹菜工人的水平尺度导致相同的处理时间

Question

当我们用芹菜水平扩展时，我们正在经历芹菜的意外行为（增加我们的实例数量）。

我们所执行任务的当前处理时间仅超过1小时，这与我们增加工作人员实例的时间相同，如果我们扩展到16x worker1和16x worker2或者拥有4x worker1和4x worker2。

在将指标汇总到prometheus / grafana后，我们可以看到磁盘读取，写入和网络到桑巴不是瓶颈也是工人和经纪人的cpu和ram没有达到最大限度我们也看到任务分批完成并且在开始下一个任务之前等待一批任务完成而不是连续，这会导致在处理再次开始之前暂停一下。

我的问题是这种芹菜的预期行为？当我横向缩小时，我希望我的总处理时间减少。

我们的设置：

Rabbitmq Broker 3.6.14 8GB RAM 2CPU  
Celery 4.1.0 (apmq)  
Python application  
2 queues  
8x worker1 8GB RAM 2CPU  
8x worker2 8GB RAM 2CPU  
all in docker containers  
writing to samba share

芹菜配置：worker_prefetch_multiplier = 1

运行命令：

worker1：celery -A node_slave worker -n worker@%h --loglevel=debug --concurrency=2
worker2：celery -A node_slave worker -n worker@%h --loglevel=debug --concurrency=2 -Q queue2
配置测试：gevent，Ofair
处理背景：消息被发送到中央队列，例如queue1，

worker1将从queue1检索消息并运行从samba共享（输入）上的目录检索文件的应用程序，并将文件转换为特定的文件类型并将其放到（输出）samba共享worker1上也将写入消息进入queue2异步

worker2针对queue2中的文件运行应用程序并写入nosql后端。