MongoDB副本集性能如何检测？为何副本集查询与单节点耗时一致

• 未利用副本集的读扩展特性：副本集的查询性能优势体现在多并发读场景下的负载分摊，单次/低并发查询无论发向副本集哪个节点，在硬件配置、查询逻辑、数据量一致的前提下，耗时和单节点不会有差异。你当前的测试应该是低并发甚至单请求测试，自然观测不到差异。
• 虚拟机共享硬件资源导致的结果偏差：4台VM均部署在同一台物理机的VirtualBox上，共享物理CPU、内存、磁盘IO资源。即便读请求路由到不同副本集节点，本质还是消耗同一物理机的算力，完全无法模拟多物理机部署副本集时的资源隔离收益，甚至副本集数据同步的额外开销可能导致性能弱于单节点。
• 缓存干扰导致测试结果无差别：多次切换读偏好执行相同查询时，查询对应的数据已经被WiredTiger缓存、操作系统页缓存命中，无论请求发向哪个节点都会直接读取缓存返回，耗时自然一致。测试前需要在对应节点执行MongoDB命令db.adminCommand({flushRouterConfig: 1})，以及节点所在VM的系统命令echo 3 > /proc/sys/vm/drop_caches清空所有缓存，确保每次测试都是冷数据查询。
• 未验证读请求实际路由：仅配置读偏好无法保证请求真的被分发到不同节点，可通过开启MongoDB慢日志、执行db.currentOp()查看请求实际执行的节点，排除配置错误导致所有请求仍然发向Primary的情况。

• 前置配置：保证4台VM分配的CPU核心数、内存、磁盘配置完全一致，副本集完成全量数据同步后，暂停Primary节点的所有写入操作，排除数据同步开销对测试结果的影响。
• 压测逻辑：使用mongoperf或MongoDB专用压测工具发起100以上并发的重查询请求，分别统计单节点、副本集场景下的QPS、P95/P99延迟指标，此时才能观测到副本集读扩展带来的性能提升。
• 变量控制：每次测试前清空所有节点的缓存，单次测试时长不低于30秒，取3次以上测试的平均值作为最终结果，排除偶然误差。

内容的提问来源于stack exchange，提问作者Milind Chaudhary