区块链上链项目各个模块性能测试结果

一、条码数据丢代理服务器

每次条码数据随机生成,测试过程中单次传输数据量大小如下

数据量	原始json大小	加上安全参数后	加密后	密文转base64后	封装成最终请求body
1	221 byte	381 byte	400 byte	536 byte	587 byte
10	2,189 byte = 2.14 kb	2,619 byte = 2.56 kb	2,640 byte = 2.58 kb	3,520 byte = 3.44 kb	3,571 byte = 3.49 kb
100	21,885 byte = 21.37 kb	25,015 byte = 23.43 kb	25,040 byte = 24.45 kb	33,388 byte = 32.61 kb	33,439 byte = 32.66 kb
1,000	218,636 byte = 213.51 kb	248,766 byte = 242.94 kb	248,784 byte = 242.95 kb	331,712 byte = 323.94 kb	331,763 byte = 323.99 kb
10,000	2,186,595 byte = 2135.35 kb = 2.09 mb	2,486,727 byte = 2,428.44 kb = 2.37 mb	2,486,752 byte = 2,428.47 kb = 2.37 mb	3,315,672 byte = 3,237.96 kb = 3.16 mb	3,315,723 byte = 3,238.01 kb = 3.16 mb
100,000	21,864,301 byte = 21,351.86 kb = 20.85 mb	24,864,431 byte = 24,281.67 kb = 23.71 mb	24,864,448 byte = 24,281.69 kb = 23.71 mb	33,152,600 byte = 32,375.59 kb = 31.61 mb	33,152,651 byte = 32,375.64 kb = 31.62 mb
500,000	109,326,940 byte = 106,764.59 kb = 104.26 mb	124,327,070 byte = 121,413.15 kb = 118.57 mb	124,327,088 byte = 121,413.17 kb = 118.56 mb	165,769,452 byte = 161,884.23 kb = 158.09 mb	165,769,503 byte = 161,884.28 kb = 158.09 mb

---

1、初步结论

1. 表面上看上去加上安全参数后体积变大也不小，如50w条数据中，加上安全参数，体积增大约14mb，然而安全参数大小固定为81byte，原因是加上安全参数后，原业务参数json作为一个子json字段，所以会对原json中的"进行转义，加上大量的\。

   • 优化等级：低
   • 解决办法：不采用json传输协议

2. 可以看出对数据加密后，体积几乎不变，但是将二进制密文转成base64后，体积增加 ⅓，如50w条数据中，体积增大39.53mb。

   • 优化等级：中
   • 解决办法：不采用json传输协议，因为json格式中无法存储二进制数据，可能采用TLV等协议

2、客户端单次传输条码数据量 与 服务器各阶段处理耗时如下

目前client与server以及redis、3个节点的kafka集群以及一个zookeeper都跑在一台 mac、2.8 GHz Intel Core i7、16 GB 2133 MHz LPDDR3 电脑上

条目	1 条码耗时	10 条码	100 条码	1k 条码	1w 条码	10w 条码	50w 条码
aes解密	197.05 μs	198.71 μs	863.21 μs	8.02 ms	60.00 ms	609.93 ms	3.46 s
json序列化	97.18 μs	61.72 μs	240.39 μs	2.04 ms	16.61 ms	190.90 ms	1.09 s
计算sha3-256并验证数据完整性	60.98 μs	68.78 μs	382.21 μs	3.38 μs	26.62 μs	270.78 μs	1.58 s
两次redis访问	3.99 ms	4.35 ms	4.45 ms	4.18 ms	4.76 ms	4.88 ms	4.98 s
json反序列化为拥有x个条码对象的List	291.77 μs	352.93 μs	857.33 μs	4.75 ms	25.10 ms	230.25 ms	1.54 s
数据丢给kafka producer缓存	171.23 μs	324.83 μs	1.47 ms	7.15 ms	125.01 ms	957.60 ms	4.81 s
总计	5.48 ms	6.00 ms	9.04 ms	30.58 ms	258.57 ms	2.27 s	12.51 s

1、初步结论

1. 除了redis的两次访问需要消耗常数时间，其他各阶段耗时都是随数据量大小线性增长的。
2. 性能还是很不错的，而且实际生产过程中，客户端单次传输条码数量限制 < 1000

3、并发测试

• 待更新