多个工作容器和多个用户

Question

我们正在为每个用户运行大量后台任务，但增加处理这些任务的线程数并没有给每分钟执行的任务数量带来预期的加速 - 奇怪的是，这是仅涉及涉及多个用户任务的情况

在这种情况下，“worker”是一个Python 3.6容器，运行带有threading模块的5个线程，每个模块都使用同一个Google Cloud PubSub主题中的任务

以下是演示此问题的测试用例示例

• 测试1：任务队列中的800个任务，所有任务属于1个用户（A）
• 测试2：另一个任务队列中的2000个任务，所有任务属于另一个用户（B）

• 测试3：我们同时运行1和2两个任务队列（两个队列之间的公平消耗），共计2800个任务。

• 我们使用1个工作容器运行测试1，这需要约30分钟

• 我们使用2个工作容器运行测试1，这需要大约15分钟才能完成
• 我们使用1个工作容器运行测试2，这需要约120分钟才能完成
• 我们使用2个工作容器运行测试2，这需要约70分钟才能完成
• 我们使用2个工作容器运行测试3，这需要约200分钟才能完成
• 我们使用4个工作容器运行测试3，这需要200多分钟才能完成

据我所知，没有“死”线程（死锁或其他），但是有可能出现线程执行速度比预期慢得多的情况吗？ 当我们有4个工作容器/ 20个可用线程时，为什么吞吐量不会增加？我们还可以调试什么来理解为什么吞吐量没有增加？同样，只有在同时执行多个任务队列时才会发生这种情况。

有关工人容器与之交谈的内容的更多信息，以及我们迄今为止所发现的内容：

工作容器正在与（通过HTTP / S）进行通信：

• 由Google云SQL（读写）管理的数据库实例。我们没有看到同时读取或写入多达100个线程的性能显着下降
• 弹性搜索节点（读写）。每个用户都有自己的索引，每个任务都附加索引;我们观察到，当同时写入多个索引时，索引性能会有所下降;但是，使用批量写入模式并没有改善这一点。
• 完成部分任务的另一个后端服务，看了这个我们没有发现它是一个瓶颈，因为它是独立扩展的
• 用于提取和执行任务的Google Pub-Sub
• 第三方API - 我们没有遇到任何费率限制