• 背景：CouchDB 支持客户使用其作为 AAA 体育游戏后端超 10 年，即将推出新版，其六节点集群配置为 AWS EC2 上 192 核、768GB RAM、NVME 存储，原基准测试显示每秒请求增加仅 50%，且负载下请求延迟增加 10 倍。
• 基准测试问题：测试方式不利于 CouchDB，为最差情况基线，由 9 次调用ab工具组成，模拟并发请求但不符合实际应用情况，未计算结果统计显著性。
• CouchDB 内部原理：数据库按 shard 存储，默认 2 个，数据均衡分布，sharding 可增加并行读写性能但影响视图查询性能，客户 shard 级别为 60。
• CouchDB 集群工作原理：节点可接收请求并内部转发，文档操作和视图操作处理方式不同，文档操作需获取 shard 范围，视图操作需接触每个 shard 范围。
• 网络问题及解决：客户网络被限制在 1Gb/s，启用 AWS 更快网络设置后可达 25Gb/s，但基准测试限制因素变为其他方面。
• 磁盘 IO 及 Erlang 进程：排除磁盘 IO 为瓶颈，介绍 Erlang 进程相关，如消息队列、调度器等，通过recon库观察 Erlang 进程消息队列。
• 请求处理各阶段分析：通过curl观察_dbs_info端点在基准测试前后的处理时间，发现接收请求、发送响应头和发送响应体阶段均有延迟，推测存在两个瓶颈，分别是接受新请求和收集集群中多个 shard 的响应体数据。
• 接受请求瓶颈及解决：CouchDB 使用mochiweb处理 HTTP 请求，客户配置相关选项，通过ss工具观察backlog和acceptor_pool_size，将acceptor_pool_size从 16 增加到 32 减少了请求接受延迟。
• CPU 利用分析及其他尝试：使用msacc进行性能分析，未发现明显 CPU 瓶颈，后受 CouchDB 开发团队启发，调整 Erlang 网络相关设置，将zdbbl等设置调整后使_dbs_info响应时间降至 0.5 - 1.2s 范围，请求吞吐量提升 4 倍以上至 60000req/s，CPU 利用率 60 - 70%且有 10 - 20%余量。
• 总结与展望：感谢阅读，希望读者学会调优 CouchDB 和 Erlang，了解系统工作原理有助于寻找瓶颈，未来将发布开源 metrics 仪表盘和 CouchDB 监控工具 Opservatory，如有需求可预约咨询。