一、条码数据丢代理服务器
每次条码数据随机生成,测试过程中单次传输数据量大小如下
| 数据量 | 原始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、初步结论
-
表面上看上去加上安全参数后体积变大也不小，如
50w条数据中，加上安全参数，体积增大约14mb，然而安全参数大小固定为81byte，原因是加上安全参数后，原业务参数json作为一个子json字段，所以会对原json中的"进行转义，加上大量的\。- 优化等级：低
- 解决办法：不采用
json传输协议
-
可以看出对数据加密后，体积几乎不变，但是将二进制密文转成
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、初步结论
- 除了
redis的两次访问需要消耗常数时间，其他各阶段耗时都是随数据量大小线性增长的。 - 性能还是很不错的，而且实际生产过程中，客户端单次传输条码数量限制
< 1000
3、并发测试
- 待更新
