Hyperledger Fabric部署基准性能低下及存储占用过大问题咨询

一、10 TPS的性能瓶颈：是Composer上限还是实现问题？ #

先给结论：10 TPS确实偏低，既有Composer框架本身的特性限制，也大概率存在你的实现或配置优化空间。

• Composer的固有开销：Composer作为Fabric的上层抽象框架，会在链码逻辑之上增加业务建模、ACL管理、交易解析等额外开销，默认配置下它的吞吐量确实不如直接编写原生Fabric链码（原生链码合理配置下能轻松达到数百TPS）。但10 TPS远低于Composer的常规表现，所以这不是它的性能上限。
• 可能的实现/配置问题：
  • 链码逻辑冗余：比如每个交易是否存在不必要的复杂查询、多次重复读写世界状态，或是循环遍历大量数据？Composer的查询API如果使用不当，会额外消耗大量资源。
  • Fabric核心配置未优化：默认的batchTimeout（批处理超时）是2秒，如果你的交易频率低，会导致区块生成过慢，直接拉低TPS；另外maxMessageCount（每个区块最大交易数）默认是10，太小的话区块的元数据开销占比过高，也会影响吞吐量。
  • 节点资源未充分利用：虽然你给节点配置了8核8G，但Docker容器的资源限制有没有放开？比如是否在docker-compose里设置了cpus和mem_limit？如果容器实际只用到1核2G，性能自然上不去。
  • 交易复杂度：如果你的交易包含大量签名验证、多节点背书（比如超过3个背书节点），或是ACL规则过于复杂，都会拖慢交易处理速度。

如果要提升性能，优先排查上述配置和代码问题，若仍达不到预期，可能需要考虑迁移到原生Fabric链码开发。

二、存储占用过大：是否正常还是实现问题？ #

Fabric的存储机制和SQL Server完全不同，不能直接按SQL的存储量线性计算，700MB的存储在3节点场景下有一定合理性，但也存在优化空间：

• 存储逻辑的本质差异：
  • SQL Server是关系型数据库，仅存储最新的结构化数据，不会保留所有历史版本；而Fabric每个节点存储的是完整的区块链账本，包括：区块头（含哈希、签名等元数据）、区块体（所有交易的完整内容，包括签名、背书信息、输入输出参数）、世界状态快照，以及各类索引。每个交易的元数据开销远大于SQL里的单条数据。
  • 3个节点是各自存储完整的账本副本，不是“1个节点的存储量×3”这么简单，因为每个节点还要维护自己的世界状态和独立索引，总存储量会略大于单节点的3倍。
• 可能的优化点：
  • 区块配置优化：如果maxMessageCount设置太小，每个区块的元数据开销占比会很高，导致存储浪费。可以适当调大这个值（比如设为100或更高），减少区块数量。
  • 世界状态存储选择：Composer默认用LevelDB，它的键值对存储由大量小文件组成，磁盘占用会比CouchDB高一些。如果需要更好的存储效率，可考虑切换到CouchDB（支持JSON查询，存储更紧凑）。
  • 冗余数据检查：检查你的链码是否写入了大量不必要的元数据或重复数据，比如每次交易都写入相同的静态信息，这会大幅增加存储占用。
  • 历史数据清理：Fabric默认会保留所有交易历史，如果你不需要查询历史版本，可以通过配置关闭部分历史数据存储，或者定期清理旧的世界状态快照。

总的来说，700MB存储3节点1000条交易是偏多的，但属于Fabric存储机制下的可接受范围，通过优化配置和链码逻辑可以降低占用。

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