区块链性能测试与优化-上篇

大纲

本篇文章目的是通过具体示例（cosmos-sdk SimApp），介绍完整的性能项目过程，具体内容介绍区块链性能测试中使用的：

• 1. 基本概念

• 2. 常用工具

• 3. 性能调优的常见情况

这 3 块内容涵盖的内容非常多，每一个内容都有很多书籍和文章介绍，详细的内容不会出现在本文中。

基本概念

区块链的性能测试，方法论上与传统的性能测试没有不同。性能测试有很多混乱的概念，这里我列出本文描述概念做一些定义。

性能测试的定义

性能测试是对系统或者服务的性能指标建立监控策略，在特定场景下执行测试，分析判断性能瓶颈并调优，最终得出性能结果来评估系统或者服务的性能指标是否满足既定值。这里结合 cosmos-sdk 的 simapp 区块链来解释。

• 1. 需要明确指标，一般指两类指标: 技术 指标、业务指标。技术指标一般是 TPS，响应时间，资源利用率，对应到区块链一般是指每秒可以处理多少笔交易？这些交易的响应时间或者统计结果是多少？在这种情况下系统使用的资源处于什么状态？期望满足的业务指标，应该来源于生产环境统计，以 cosmos-sdk 的生产应用 cosmos-hub 为例，其现阶段出块时间大约 6 秒，每个区块中的交易数大多数小于 10 。期望的业务指标设定为 TPS 为 100 是较为合理的。（这么低的 TPS 其实是与 cosmos-hub 的目标有关，因为其主要关注点在链的互操作性）。

• 2. 测试模型: 是真实场景的抽象，描述业务模型是什么样的。以 cosmos-hub 为例大致就是，分布在全球的区块链节点，在验证者节点约 500 个，活跃验证者节点约为 200 的情况下处理交易。测试时可以按比例抽象实际情况。

• 3. 测试方案: 包括测试环境，测试数据，测试模型，性能指标等。对比区块链系统的测试，就是确定测试架构，准备好如 1000 个用户，每个用户余额 1000 stake 这样的内容。

• 4. 需要有监控: 监控的对象有压力机、区块链节点、其他如负载均衡服务器等。云原生时代的监控一般是 Kubernetes+Prometheus+Grafana。

• 5. 需要测试条件：硬件环境，测试执行策略等。例如: 4 C 8 G, 前 60 秒，每秒增加 10 个线程。

• 6. 需要有场景：指性能场景，正式化的描述是: 在既定的环境、既定的数据、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。性能场景，有时被称为测试用例其实是不对的。

• 7. 要有结果报告：报告内容当然就是实际的指标数据。

性能场景分类

• 1. 基准性能场景：做单交易/接口的容量（业务量），为混合容量做准备。

• 2. （混合）容量性能场景：混合容量测试是因为线上真实场景就是由不同的业务组成的，所以由这些业务按照不同并发比例发起梯度压测就是混合容量测试场景。

• 3. 稳定性性能场景：核心就是时长，在长时间的运行之下，观察系统的性能表现。这个时长的设置，应该来源于运维周期。

• 4. 异常性能场景：在强压力之下，模拟异常。

重要的性能指标

性能测试的指标有很多，比如：

• 1. RT, Response Time

• 2. HPS, Hits Per Second

• 3. TPS, Transactions Per Second, 这里的 Transactions 在传统的应用中一般称为”事务“，在区块链领域指”交易“

• 4. QPS, Queries Per Second

• 5. PV, Page View

• 6. Throughput

• 7. IOPS, Input/Output Operations Per Second

比较重要的指标有资源使用率、吞吐量、响应时间，服务提供方比较关心前两者，用户更更新后者。关于这些指标的一般情况引用 Performance TestingMethodology(http://hosteddocs.ittoolbox.com/questnolg 22106 java.pdf)中的经典图来说明，实际情况可能不同。图中定义了 3 线 3 区域 3 状态，这个图值得多看看，能够大致理解指标简的关系。

• 1. 3 线: Utilization，Throughput，Response Time

• 2. 3 区域: Light Load, Heavy Load, Buckle Zone

• 3. 3 状态: Resource Saturated, Throughput Falling, End Users Effected

其他

• 1. 一般需要在什么时候做性能测试。

• a. 项目上线前，估计系统承载能力

• b. 项目重构后，评估效果

• 2. 如果一个项目得到性能报告就终止，这样就只是性能验证。做完全面的性能测试，同时将系统调优到最优状态，才算是一个完整的性能项目了。性能调优耗时长，还可能需要开发参与，代价高。

• 区块链性能测试

区块链的性能测试的指标最重要的是 TPS 与延迟， a16z 的文章 Why blockchain performance is hard to measure 对此做了很有洞察的讨论，说明了为什么这两个指标很难测量和比较。其主要内容有以下方面：

延迟

延迟的这段时间的起点和终点如何定义？

• 1. 起点是用户点击提交还是交易到达内存池？

• 2. 终点是交易被第 1 个区块确认？还是被第 6 个区块确认（POW 区块链是这样认为的）？又或者是最终用户收到接口响应的时间？

• 3. 有些区块链系统对交易会等待一定延迟和到达一定数量才开始处理。这样比较幸运的就是最后加入的交易，其处理延迟最短。

• 4. 对于上诉问题的一种折中方案是，即准确评估整个系统需要考虑延时的分布，而不是将其延迟看做单一数字。

• 5. 有些区块链系统的交易处理是有优先级的，fee 高的交易很快确认，fee 低的相对慢些。fee 的不同对交易的延时和 TPS 的统计是有影响的。

吞吐量

区块链中的吞吐量，即 TPS(Transaction Per Second)来衡量，这里的 transaction 显示不是平等的，最简单的例子就是以太坊中的交易，它可以是转账也可以是调用合约。因此，得出 TPS 需要指定 T 指代的是什么。

另外一个实际的问题是，用户其实不关心一个区块链的 TPS 是多少，用户只关心如何少用 fee 并尽快完成交易。从这个角度来讲，TPS 只对系统服务提供商有意义。

基本工具

压力工具

压力工具一般用 Jmeter 或者特定应用专用测试工具如下:

• 1. hyperbench/hyperbench

• 2. h yperledger/caliper: A blockchain benchmark framework to measure performance of multiple blockchain solutions

• 3. https://github.com/xuperchain/xbench

• 4. …

使用 Jmeter 应该是更贴近使用场景，更通用。一般与区块链节点进行交互的方式有（一般命令行交互最终也是调用下面的接口之一）

• 1. gRPC 协议

• 2. HTTP 协议 (REST 接口)

Jmeter 支持的 Sampler 支持有 HTTP，对 gRPC 协议的支持需要借助插件 jmeter-grpc-request

监控工具

监控工具一般用 Prometheus 这工具可以监控的内容比较多，其生态如图( https://prometheus.io/assets/architecture.png )。在测试区块链应用的实践中，一般是先使用 docker-compose 部署多个区块链节点模拟正式进行测试的环境，因为正式的测试环境一般硬件配置较高，如果不是自建机房，使用云服务厂商的机器，费用昂贵，这样做可以节约成本。

docker-compose 中可以限制容器使用的资源，如内存和 CPU 算力，甚至绑定 CPU 核心，对这些资源的监控可以使用 cadvisor 。

为了验证 CPU 限制是否准确，可以用 stress-ng 压满核心，看统计结果是否与限制值一致。

性能调优

一般遇到性能瓶颈的常见元原因（我称之为原因背后的原因，一般都会到硬件层面）会是网络、CPU、磁盘 IO。引发磁盘 IO 的瓶颈的操作有写日志频频繁，打印不必要的日志，通过网络访问磁盘等。这些资源都会通过系统调用来完成，跟踪系统调用，可以使用 strace 来查看执行了哪些系统调用，以及在这些调用上花费的时间等信息

还可能遇到的问题是系统不稳定，可以表现为 CPU 使用率/TPS 不稳定。

如果在 LightLoad 区域选择一定的并发压力，TPS 波动较大的话，可能就是系统设计得不好，需要找到原因和优化了。

如果是 CPU 使用率不稳定（趋势稳定，但波动大），从 CPU 指令执行层面来看为 CPU 处于 idle 状态的时长参差不齐。这种情况下的原因并不在于有 CPU 有 idle，而是在于处于 idle 的时间段有长有短。需要借助 Linux 系统工具、程序对应的 profilling 工具来观测，找到原因。

分析工具

要解决性能问题，首先需要找到原因，寻找原因的分析工具可以参考下图( https://www.brendangregg.com/Perf/linux_perf_tools_full.png )。这是 Linux 性能分析最重要的参考资料了，显示了在不同子系统出现性能问题后，应该用什么样的工具来观测和分析。

磁盘 IO

磁盘 IO 一般会导致系统瓶颈，磁盘 IO 栈比较长，分析起来难度不小。熟悉 IO 栈，有助于我们发现问题( https://www.thomas-krenn.com/en/wikiEN/images/c/c 2/Linux-storage-stack-diagram_v 6.2.pdf )

找到原因后，如果能够通过调整操作系统参数或者应用系统参数优化性能是比较快捷的，如果需要修改代码，则会涉及系统架构优化，会有涉及和编码工作，调优周期会很长。

下一篇文章将分享使用 cosmos-sdk 中的 SimApp 来进行性能测试以及在性能调优方面的方法。