性能优化之接口优化( 二 ) _接口优化

文章插图

数据包越大，则在光纤传输时所需的时间就会越久，因此接收方等待数据包的时间也会更长，最终会导致应用层等待数据时间变长。
还有，由于TCP采用的滑动窗口机制来提升传输性能，窗口的大小受接收端处理速率和网络拥塞情况影响，因此如果传输的包越小，则可以在尽量少的窗口周期完成数据的传输，减少响应的等待时间，反之，响应等待更长。
从上面几个方式来看，业务客户端能够做的一部分其实是缩小网络包的大小，那么我们下面介绍一下缩小网络包研究。
收益
?缩小接口网络数据包方案与收益

缩小网络包，是否真的会对网络的传输有效果呢？

我们对数据包的大小与网络传输时长做了一个线下的实验，以下是实验的数据：

文章插图

其他条件不变，我们将一页返回数据改变后的数据；
可以看出网络传输时间与数据包的大小是有着正相关的关系的。

减少网络包大小有哪些措施呢？

更优的压缩算法
不同的压缩算法，压缩算法是不一样的：

文章插图

图片来源于网上大佬的图片
但是，压缩算法的调整需要考虑方面很多，如果仅仅是网络时间的收益在很多场景下可能成本较高，暂未考虑。
减少返回数据个数
减少返回数据个数，服务端的同学已经在投入，但是遇到了一个问题，数据个数的减少就需要增加请求的次数，机器资源的成本就会升高，需要申请机器的资源；那就比较尴尬了，本身是优化，却让成本来买单。
精简返回字段
在原有的请求数据上通过精简字段，减少数据包的大小。这样既能降低数据包，成本又不增高。如何做呢？下面来研究一下。
?精简数据报文

做一个实验

一个接口的分页接口数据包大小在1.5M左右，Server使用的是gzip（best模式）的压缩方式，我进行压缩后的大小为106KB左右。通常其他接口数据包大小压缩后普遍在10KB以下，所以可以看出分页接口横向对比来看，数据包大小是非常严重的。这也是为什么会选择精简数据报文作为优化手段一大原因。

分析

精简数据报文需要根据业务的场景来看，我这里来举一个我这边实践的例子：
从数据包上分析，业务A的数据占比59.8%，而且该业务数据元素字段重复率非常高，来看一下去除该业务后的数据包大小：
原始数据
精简后
降低率
59.8%
从数据比对来看，不同的卡片有大约18处的不同，其占比：
占比 = 1 - (5350 / 17439) ≈ 0.693
那么，此时就有一个问题了，重复的数据，经过压缩后还会占包大小吗？
所以我就用服务端的压缩方式对数据做了个压缩：
原始数据
精简后
原始数据Gzip压缩
精简后Gzip压缩
降低率
59.8%
90%
95%
数据表明，针对重复字段的精简，压缩后依然是有效的。