一嘉蕾、條碼數(shù)據(jù)丟代理服務(wù)器
每次條碼數(shù)據(jù)隨機(jī)生成,測(cè)試過(guò)程中單次傳輸數(shù)據(jù)量大小如下
| 數(shù)據(jù)量 | 原始json大小 |
加上安全參數(shù)后 | 加密后 | 密文轉(zhuǎn)base64后 |
封裝成最終請(qǐng)求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肪康、初步結(jié)論
-
表面上看上去加上安全參數(shù)后體積變大也不小，如
50w條數(shù)據(jù)中长踊，加上安全參數(shù)，體積增大約14mb萍倡，然而安全參數(shù)大小固定為81byte身弊，原因是加上安全參數(shù)后，原業(yè)務(wù)參數(shù)json作為一個(gè)子json字段列敲，所以會(huì)對(duì)原json中的"進(jìn)行轉(zhuǎn)義阱佛，加上大量的\。- 優(yōu)化等級(jí)：低
- 解決辦法：不采用
json傳輸協(xié)議
-
可以看出對(duì)數(shù)據(jù)加密后戴而，體積幾乎不變凑术，但是將二進(jìn)制密文轉(zhuǎn)成
base64后，體積增加 ?所意，如50w條數(shù)據(jù)中麦萤，體積增大39.53mb。- 優(yōu)化等級(jí)：中
- 解決辦法：不采用
json傳輸協(xié)議扁眯，因?yàn)?code>json格式中無(wú)法存儲(chǔ)二進(jìn)制數(shù)據(jù)壮莹，可能采用TLV等協(xié)議
2、客戶端單次傳輸條碼數(shù)據(jù)量 與 服務(wù)器各階段處理耗時(shí)如下
目前client與server以及redis姻檀、3個(gè)節(jié)點(diǎn)的kafka集群以及一個(gè)zookeeper都跑在一臺(tái) mac命满、2.8 GHz Intel Core i7、16 GB 2133 MHz LPDDR3 電腦上
| 條目 | 1 條碼耗時(shí) | 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 |
計(jì)算sha3-256并驗(yàn)證數(shù)據(jù)完整性 |
60.98 μs |
68.78 μs |
382.21 μs |
3.38 μs |
26.62 μs |
270.78 μs |
1.58 s |
兩次redis訪問(wèn) |
3.99 ms |
4.35 ms |
4.45 ms |
4.18 ms |
4.76 ms |
4.88 ms |
4.98 s |
json反序列化為擁有x個(gè)條碼對(duì)象的List |
291.77 μs |
352.93 μs |
857.33 μs |
4.75 ms |
25.10 ms |
230.25 ms |
1.54 s |
數(shù)據(jù)丟給kafka producer緩存 |
171.23 μs |
324.83 μs |
1.47 ms |
7.15 ms |
125.01 ms |
957.60 ms |
4.81 s |
| 總計(jì) | 5.48 ms |
6.00 ms |
9.04 ms |
30.58 ms |
258.57 ms |
2.27 s |
12.51 s |
1绣版、初步結(jié)論
- 除了
redis的兩次訪問(wèn)需要消耗常數(shù)時(shí)間胶台，其他各階段耗時(shí)都是隨數(shù)據(jù)量大小線性增長(zhǎng)的。 - 性能還是很不錯(cuò)的杂抽，而且實(shí)際生產(chǎn)過(guò)程中诈唬，客戶端單次傳輸條碼數(shù)量限制
< 1000
3、并發(fā)測(cè)試
- 待更新
