fabric_performance
简单性能测试
服务
- order服务: 负责接收背书后的交易放入kafka中，并从kafka中读出交易出块
- peer服务： 负责背书交易
- http 客户端测试服务： 向peer发送交易背书后发送到order
- 1个通道，2个组织
机器
- 1号机，4核8g
- 2号机，4核8g
- 3号机，4核8g
- 云服务kafka
区块配置: 每区块512KB，每条交易2.9KB，每个区块平均包含173个交易
机器使用
| 1号机 | 2号机 | 3号机 |
|---|---|---|
| order服务 * 3 | peer服务 * 1 | http 客户端测试服务 * 1 |
性能情况
| 实时出块速度 | 只读出块速度 |
|---|---|
| 1400 | - |
只读出块速度： http 客户端发送交易，首先发送到peer背书，随后发送到order节点，order节点收到交易后放入到kafka存储(消息生产过程)，随后order出块(消息消费过程)。当消息生产速度高于消费速度，就会造成消息堆积，当消息生产速度为0，只消费堆积的消息的速度，称为只读出块速度。
第一次更新
增加区块大小
每区块1500KB，每条交易2，9KB，每个区块平均包含500个交易
性能情况
| 实时出块速度 | 背书速度 | 只读出块速度 |
|---|---|---|
| 1500 | 1500 | - |
第二次更新
增加peer数量
机器使用
| 1号机 | 2号机 | 3号机 |
|---|---|---|
| order服务 * 3 | peer服务 * 1；peer服务 * 1 | http 客户端测试服务 * 2 |
性能情况
| 实时出块速度 | 背书速度 | 只读出块速度 |
|---|---|---|
| 1000 | 8000*2 | 1800 |
观察
增加peer，peer的背书速度稍有提升，但出块速度竟然降低了..
出块的速度小于交易产生速度，当http 客户端停掉之后，出块的速度得到提升并且稍大于单个peer的情况。
第三次更新
追加服务器，负载均衡
- 4号机，4核8g
- 5号机，4核8g
机器使用
| 1号机 | 2号机 | 3号机 | 4号机 | 5号机 |
|---|---|---|---|---|
| order服务 * 3 | peer服务 * 1 | peer服务 * 1 | http 客户端测试服务 * 1 | http 客户端测试服务 * 1 |
性能情况
| 实时出块速度 | 背书速度 | 只读出块速度 |
|---|---|---|
| 1300 | 1400 * 2 | 2200 |
观察
负载均衡后，背书的速度得到显著提升！实时出块和只读出块的速度也稍有提升。
但实时出块的速度还是没有只有1个peer的速度…
第四、五次更新
提升服务器性能，首先将order服务所在的1号机升级为8核16g，实时出块的速度增加到1700，但2个peer的速度还是没有1个peer的速度快..
其次，提升了kafka服务器的性能.. 结果没啥变化
第六次更新
再次提升服务器性能，这次提升的是peer节点的性能，将peer节点的2号机和3号机升级为8核16g
机器使用
| 1号机8核16g | 2号机8核16g | 4号机 |
|---|---|---|
| order服务 * 3 | peer服务 * 1 | http 客户端测试服务 * 1 |
性能情况
| 实时出块速度 | 背书速度 | 只读出块速度 |
|---|---|---|
| 1800 | 1800 | - |
机器使用
| 1号机8核16g | 2号机8核16g | 3号机8核16g | 4号机 | 5号机 |
|---|---|---|---|---|
| order服务 * 3 | peer服务 * 1 | peer服务 * 1 | http 客户端测试服务 * 1 | http 客户端测试服务 * 1 |
性能情况
| 实时出块速度 | 背书速度 | 只读出块速度 |
|---|---|---|
| 2600 | 1700 * 2 | 3500 |
观察
1个peer时速度为出块速度为1800
增加1个peer，背书速度提升接近2倍，出块速度增加至2600，当停掉http客户端后，只读出块速度增加至3500
结论
(在一定条件下)增加peer的数量，能增加tps。在本例中，8核16g的peer下，增加一个peer的tps由1800增加至2600。
所谓一定条件，例如peer服务对于服务器性能(内存等)要求挺高的。