区块链性能测试与优化-上篇
这?3?块内容涵盖的内容非常多，每一个内容都有很多书籍和文章介绍，详细的内容不会出现在本文中。
区块链的性能测试，方法论上与传统的性能测试没有不同。性能测试有很多混乱的概念，这里我列出本文描述概念做一些定义。性能测试是对系统或者服务的性能指标建立监控策略，在特定场景下执行测试，分析判断性能瓶颈并调优，最终得出性能结果来评估系统或者服务的性能指标是否满足既定值。这里结合?cosmos-sdk?的?simapp?区块链来解释。1. 基准性能场景：做单交易/接口的容量（业务量），为混合容量做准备。
2. （混合）容量性能场景：混合容量测试是因为线上真实场景就是由不同的业务组成的，所以由这些业务按照不同并发比例发起梯度压测就是混合容量测试场景。
3. 稳定性性能场景：核心就是时长，在长时间的运行之下，观察系统的性能表现。这个时长的设置，应该来源于运维周期。
4. 异常性能场景：在强压力之下，模拟异常。
比较重要的指标有资源使用率、吞吐量、响应时间，服务提供方比较关心前两者，用户更更新后者。关于这些指标的一般情况引用?Performance TestingMethodology(http://hosteddocs.ittoolbox.com/questnolg?22106?java.pdf)中的经典图来说明，实际情况可能不同。图中定义了?3?线?3?区域?3?状态，这个图值得多看看，能够大致理解指标简的关系。
1. 一般需要在什么时候做性能测试。
a. 项目上线前，估计系统承载能力
b.?项目重构后，评估效果
2. 如果一个项目得到性能报告就终止，这样就只是性能验证。做完全面的性能测试，同时将系统调优到最优状态，才算是一个完整的性能项目了。性能调优耗时长，还可能需要开发参与，代价高。
区块链性能测试
区块链的性能测试的指标最重要的是?TPS?与延迟，的文章Why blockchain performance is hard to measure?对此做了很有洞察的讨论，说明了为什么这两个指标很难测量和比较。其主要内容有以下方面：
延迟的这段时间的起点和终点如何定义？压力工具一般用Jmeter或者特定应用专用测试工具如下:
使用?Jmeter?应该是更贴近使用场景，更通用。一般与区块链节点进行交互的方式有（一般命令行交互最终也是调用下面的接口之一）
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?使用率/TPS 不稳定。
如果在?LightLoad?区域选择一定的并发压力，TPS?波动较大的话，可能就是系统设计得不好，需要找到原因和优化了。
如果是?CPU?使用率不稳定（趋势稳定，但波动大），从?CPU?指令执行层面来看为?CPU?处于?idle?状态的时长参差不齐。这种情况下的原因并不在于有?CPU?有?idle，而是在于处于?idle?的时间段有长有短。需要借助?Linux?系统工具、程序对应的?profilling?工具来观测，找到原因。
要解决性能问题，首先需要找到原因，寻找原因的分析工具可以参考下图(https://www.brendangregg.com/Perf/linux_perf_tools_full.png)。这是?Linux?性能分析最重要的参考资料了，显示了在不同子系统出现性能问题后，应该用什么样的工具来观测和分析。找到原因后，如果能够通过调整操作系统参数或者应用系统参数优化性能是比较快捷的，如果需要修改代码，则会涉及系统架构优化，会有涉及和编码工作，调优周期会很长。
下一篇文章将分享使用?cosmos-sdk?中的?SimApp?来进行性能测试以及在性能调优方面的方法。
