MongoDB - 缓慢的并发响应和不同响应大小的速度差异巨大答案

【问题标题】：MongoDB - slow concurrent responses and huge difference in term of speed for different response sizesMongoDB - 缓慢的并发响应和不同响应大小的速度差异巨大
【发布时间】：2019-04-21 11:59:44
【问题描述】：

我试图通过创建数百个使用相同查询来查询 MongoDB 的 Promise 来模拟真实的用例（虽然不是真实的，因为实际的查询会同时不同），然后运行 Promise.all。我注意到 2 个有趣的行为：

第一次返回可能比最后一次返回快得多（通常是最后一次返回时间的两倍）。对于这个，MongoDB 是否会锁定集合，所以查询必须在队列中等待？
如果我将返回大小从大约 40 个字段减少到 1 个字段，查询运行速度会快 10 倍。

谁能解释这两种行为？谢谢。

【问题讨论】：

您针对哪个集合（索引、结构）运行哪些查询？
@JonasWilms 所有查询的字段都被索引并且没有嵌套。但是，文档有一些嵌套字段。所有查询条件要么相等要么$in，我可以在说明中看到使用了索引。

标签： javascript mongodb performance concurrency request

【解决方案1】：

Mongo 不会排队和阻止查询。

尝试查看您机器的性能，Promise.all/map 应该用于提高流程效率，但您显然受到 CPU/RAM 可用性的限制，我怀疑您的两个问题的答案都在这里。

如果查询太繁重，您应该尝试使用 Promise.map 和 {concurrency:x} 找到最佳位置，我发现我的机器无法处理同时排队的数百个复杂查询时间，但是当我使用较小的并发性对它们进行管道化时，我可以有效地使用我的 RAM/CPU 可用性而不会使其过载。

【讨论】：

嗨，Tom，您介意分享一下您的流水线策略吗？是否可以同时处理从 Node 到 MongoDB 的 10 000 个中等到大量查询，而不会产生巨大的延迟？

【解决方案2】：

1) 我猜最耗时的任务是 MongoDB 和 NodeJS 之间的数据传输，并且由于通过有限数量的套接字，查询会在网络中排队。

2) 因为这样需要传输的数据更少。

【讨论】：