网络很差，那就试试数据压缩吧

承接上文如何从几百到几千再到几万吞吐量。经过一番改造，本以为结束了，不料漏了一个性能关键点，性能直接被摩擦！

原以为内网环境都是这样的

--- [IP] ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7000ms
rtt min/avg/max/mdev = 0.053/0.060/0.069/0.005 ms

坏的情况却是这样

--- [IP] ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8008ms
rtt min/avg/max/mdev = 35.241/35.247/35.266/0.216 ms

模拟数据传输，获得数据如下：

序列化	客户端单次条数	单条最大耗时	平均耗时/100
无	0	0.05660	0.05043
json	1000	0.74370	0.42465
marshal	1000	0.48271	0.38207

看到数据，这下找到罪魁祸首了

常见的压缩算法信息参考，看起来都不错。接着就是是否兼容，有利于以后扩展。

考虑到我们此次Agent是想要原生无依赖，这样才好丢上去就能用，因此选取lz4和zstd与Python内置的压缩模块进行对比，参考如下：

算法	内置	条数	压缩前长度	压缩后长度	耗时
zlib	是	400	198262	2983	0.001125
bz2	是	400	198262	2034	0.034718
lz4	否	400	198262	3672	0.000093
zstd	否	400	198262	1766	0.000420
zlib	是	1000	495263	6254	0.002393
bz2	是	1000	495263	2708	0.098263
lz4	否	1000	495263	8060	0.000289
zstd	否	1000	495263	3163	0.000499

由于日常请求单次不超过400，那么增加1MS的时延在整体路径上，影响不大。单独传输数据，对照如下：

网络情况PING	客户端单次条数	before 平均耗时	after 平均耗时
35.2ms	1000	0.38207	0.07571
0.183ms	1000	0.04445	0.01631

这下放心了，平时也有加速，网络阻塞时候更有作用。

posted @ 2021-11-25 20:54 last_coding 阅读(232) 评论(0) 收藏举报

刷新页面返回顶部

last_coding