基于jmeter+nginx+raybaas-demo的Raychain-Pftest解决方案

【问题记录】

• 针对raychain怎么设计具体的测试方案（参考文档+源码）

• 针对raychain怎么实现具体的测试方案（根据实际业务场景确定相关指标）

【性能测试的术语】

• 【事务】

一个事务是指一个客户机向服务器发送请求然后服务器做出响应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息对系统性能进行定量评估。

• 【TPS】

• 专业解释：Transactions Per Second 的缩写，每秒处理的事务数目。系统的吞吐量，系统每秒钟处理的事务数量，单位：个/秒

• 通俗解释：被测系统单位时间内能够处理的事务的数目

• 详细解释：TPS 的过程包括：客户端请求服务端、服务端内部处理、服务端返回客户端。在计算机领域，TPS其实并不是一个原生概念，何为原生概念？就是底层客观存在的数据指标，比如磁盘转速、网速、CPU赫兹数、进程和线程数等。而TPS其实是一个人造的次生概念，是几种底层数据的一个综合计算结果，是为了在宏观上衡量某些特定系统而制造出来的概念。

• 具体应用：比特币业务，比特币网络每秒钟能够处理的交易数。其计算公式为：比特币系统tps=交易数/时间，单位：个/秒。在这个定义中，真正的原生概念只有“交易数”，而TPS，则是我们人为用一段时间的交易总数除以这段时间的总秒数，而得到的一个指标，代表了平均每秒能处理的交易数，注意是平均，不是真的每秒都在处理交易！

• 那么问题来了：既然“一段时间”是我们人为截取的，那么在比特币网络里，我们截取多少合适呢？一般来说，需要截取最小区块，就是一个区块的打包间隔，现在设置为1秒。请注意，第二个原生概念出来了，出块时间“1秒”。

• 交易所占物理空间：决定每条交易所占的实际物理空间大小主要有三点：1.待上链的上层应用数据 2.智能合约即上链规则 3.系统配置的每个区块的交易数目和交易时间的上限

以上两个因素唯一标定了一条链上交易数据体的实际物理空间大小。

• 区块所占物理空间：决定一个区块所占的实际物理空间大小主要有五点：1.待上链的上层应用数据 2.智能合约即上链规则 3.系统配置的每个区块的交易数目和交易时间的上限 4.网络速度和稳定性 5.系统的性能

• 区块落地时间：决定一个区块落地时间的几个重要因素：1.每个区块落地的时间和交易数目限制  2.原始的待上链数据的数据结构和数据大小 3.区块链网络的参数配置 4.系统性能 5.网络速度和稳定性。其中第3点又包括四点： 1.智能合约即上链规则 2.共识算法，例如四种常用的算法：pbft、kfaka、raft、solo 3.节点数量以及分布 4.节点物理服务器的硬件配置和系统配置

【分析结论】

• 综上所述，在比特币业务模型中，TPS其实依赖的是三个底层概念：出块时间，每个区块包含交易数，截取的时间区间。

【解决方案】

• 目前每个区块的默认配置是（1000个，1秒），具体可根据实际业务场景进行修改。 这两个参数在安装部署raychain产品的时候可以进行配置，需要注意的是：一旦配置完成便不可更改。

• 首先按照当前的系统对于区块的时间和交易数目限制，还有当前服务器的物理配置和系统配置，基于jmeter+nginx+raybaas-demo的测试方案，求出当前被测系统的最大tps。

• 其次，修改系统对于区块的时间和交易数目限制，还有当前服务器的物理配置和系统配置，继续求解被测系统的最大tps。

• 备注：关于jmeter+nginx+raybaas-demo的测试解决方案，请参考本人的博客园文章：https://www.cnblogs.com/Kevin0626/protected/p/12891339.html 密码：raychain20200515

【参考资料】

• [1]与raychain开发郭和超和曾司龙的讨论

• [2]csdn、博客园、链节点：https://www.chainnode.com/post/171800

• [3]个人分析整理汇总，欢迎大家随时批评指正

【手稿附件】