背景说明
本次项目是存管系统应用区块链技术，在业务系统报文发出的环节，增加了入区块链的功能，所以性能测试也是针对系统新增的区块链部分，用JMeter等测试工具构造业务报文并发到区块链节点的8545管理端口，然后看区块链网络的整体处理情况，是一种端到端的测试。
网络拓扑结构图：
测试准备
对照上图，本性能测试环境的物理部署，分为2个机房，分别是北软机房（部署核心的挖矿节点）和滨江机房（部署普通业务节点），两机房之间走互联网进行联通；之所以要分多个机房经公网部署后进行压测，是因为将来实际生产部署时，各联盟成员必然有各自的机房，联盟成员之间连接是走互联网的。
物理部署图：
实际测试网络情况，其中北软的34.11节点到滨江的各节点，延迟在31-50ms之间；两个机房内部都是低延迟。
测试方案
测试轮次和场景的初步设计（端到端测试场景）：
场景一：单商户满带宽压测
说明：从测试发起机器上发起多线程的测试请求至单个商户节点（比如24节点），24通过普通商业宽带连接挖矿节点，测试其交易吞吐量和时间延迟等指标；并和局域网条件的的同样场景进行性能比较
场景二：多商户满带宽压测
说明：从测试发起机器上发起多线程的测试请求至多个商户节点（比如24节点、25节点、26节点），这些通过普通商业宽带连接挖矿节点，测试其交易吞吐量和时间延迟等指标；并和局域网条件的的同样场景进行性能比较
场景三：多商户有限带宽压测
说明：从测试发起机器上发起多线程的测试请求至多个商户节点（比如24节点、25节点、26节点），这些通过普通商业宽带连接挖矿节点，但是其带宽受到限制（分布测试100M带宽、50M带宽、10M带宽、1M带宽、300K带宽），测试其交易吞吐量和时间延迟等指标；并和局域网条件的的同样场景进行性能比较
实测性能热点
在开始梳理性能热点之前，首先给大家一个Big Picture，了解整体：
性能热点排查一：从api到异步发送队列
指标监控发送队列长度，api送来的交易，先写入Leveldb的txpool命名空间，后通过线程读取Leveldb并写入发送队列，衡量这个过程的处理耗时和吞吐量
性能热点排查二：从异步发送队列到发出
异步队列被发送线程取出后进行交易签名等动作，填写具体的gas消耗等技术性值，后发出到以太坊区块链网络上，衡量这个过程的处理耗时和吞吐量
性能热点排查三：从以太坊网络到中心节点Pending队列
网络中交易发到中心节点，接受后，经过验证进入Pending队列，衡量这个过程的处理耗时和吞吐量
性能热点排查四：从中心节点Pending队列到区块链入链成功
交易在Pending队列，经过验证，被纳入新增的区块，经过程序中TrytoConnect后成为区块链的不可篡改的一部分，衡量这个过程的处理耗时和吞吐量
回顾与思考
这篇文章是在之前公司进行金融联盟链性能测试时的总结，已经过去了一段时间，区块链的性能指标在最近2年有极大的提升，所以本次测试时提出的性能指标，现在看来已经落伍了，但是本文中提到的测试思路、热点排查、问题归零等方法，还是对当下测试有现实的意义。
另外关于金融业务网走专线还是公网，有几点思考：
- 之前十多年在银行工作，和合作机构的联网都是走专线的，已经成为固定的模式，其成本和不便项目各方都是默默接受
- 近年来，国外一些银行开始“拆除围墙”，拥抱互联网技术栈，开放数据，开放接口，即所谓“开放银行业务”，这种业务走的都是公网
- 现在回头看，我们设计的这套方法，已经相当程度上拥抱公网，也符合区块链适用的场景，可谓先行者。不过区块链走公网，节约了成本，增加了便利，但是是有代价的，性能是要比专线打折（NAT、防火墙、跨运营商、深度包检查等都是有性能损耗的），特别是在高并发的场景下，某些情况下甚至引起网络不可用，考虑区块链要承载的业务重要性，业务负载飙升情况下还是要考虑专线方案