Hyperledger Fabric v1.1.0性能测试问题及与官方结果差异问询

CouchDB as State Database #

针对你遇到的CouchDB高负载下连接异常问题，Fabric社区确实在v1.1.x版本中存在已知的CouchDB连接池配置缺陷。当时Peer节点默认的CouchDB连接数设置过小，当并发请求超过连接池上限时，会出现连接排队、请求失败的情况——这就是你看到peer日志大量报错、延迟上升但服务器资源仍有空闲的核心原因。

这个问题在v1.2.0版本中已经得到官方修复：社区调整了CouchDB连接池的默认参数，优化了连接复用逻辑，从根本上解决了高负载下的连接瓶颈。如果你暂时无法升级版本，可以尝试手动修改core.yaml中的couchdb.connectionTimeout、couchdb.maxRetries及连接池大小相关参数，临时缓解问题；但更推荐直接升级到v1.2及以上的稳定版本彻底解决该问题。目前社区针对v1.1.0这类老旧版本的bug没有额外修复计划，核心建议是迁移到新版本。

LevelDB as State Database #

延迟恶化原因 #

LevelDB是基于本地磁盘的键值数据库，当写入并发达到你测试的850 rps阈值时，磁盘IO瓶颈会凸显：大量写入操作会触发LevelDB的磁盘刷写（compaction）机制，该过程会占用大量磁盘IO资源，导致后续请求排队等待，延迟急剧上升。另外，v1.1.0版本的Peer节点在交易处理流程中存在序列化/反序列化的性能开销，在高负载场景下会进一步放大延迟问题。

为何达不到论文3500 rps性能 #

IBM论文中的测试场景是经过高度优化的理想环境：

• 使用NVMe高速磁盘，规避了普通磁盘的IO瓶颈；
• 调整了操作系统内核参数（如文件描述符上限、网络栈优化）；
• 采用单通道单Peer的极简拓扑；
• 测试的是空交易链码（仅完成背书流程，无复杂状态读写操作）。

而你的测试使用了Fabcar链码（涉及实际状态读写），还有自研Node.js SDK的额外开销，拓扑结构也可能更复杂，这些都会与论文的最优测试场景产生明显差距。

社区性能改进计划 #

Fabric后续版本针对性能做了大量针对性优化，核心包括：

• v1.4+版本引入状态数据库批量读写机制，大幅减少LevelDB的磁盘IO次数；
• v2.x版本重构了交易处理流水线，优化了背书、排序环节的并发逻辑；
• 支持并行交易验证，提升高并发下的交易处理效率；
• 对LevelDB的compaction机制进行调优，减少高负载下的IO阻塞。

如果想接近论文中的性能指标，建议升级到v2.x版本，同时优化测试环境：使用NVMe磁盘、调整操作系统内核参数、简化拓扑结构（比如单Peer单排序节点）、采用更轻量的测试链码。

内容的提问来源于stack exchange，提问作者Dmitry Pugachev