本文从客户端的视角,分享客户端如何协同服务端进行接口时间的优化。
Compose是什么
接口性能优化对于客户端的同学来讲涉及可能不是很多,但是接口的性能对于客户端的体验影响是巨大的;请求失败、loading、无数据这几个关键词跟客户端的同学一提,想必接口优化的意义就不用多说了吧。
一个快速而又稳定的接口,对于客户端的用户体验来说是大有裨益的。本文从客户端的视角,分享客户端如何协同服务端进行接口时间的优化。
分析
▐简析
客户端的一次完整的接口请求主要包括:
那么我们来看一下通常客户端发起一次接口请求,耗时都发生在哪些阶段:
从上面数据上来看,客户端的耗时主要是:
客户端上这些操作往往在整个链路上占比较小,且过程优化空间较小;
然而大头往往在这两个方面:网络传输和服务端处理。
方案
▐降低ServerRT(服务端处理耗时)
通常降低服务端处理耗时,是由服务端小伙伴来优化,当然优化过程中需要端上一起协助完成,大致了解一下服务端耗时的几种处理方案;
▐降低网络传输时间
虽然现有阶段大多数用户网络已经很不错了,但是还是有很多场景下,网络耗时占比还是非常高,尤其长尾数据中,网络耗时往往是最大的占比,所以网络耗时的优化依然是非常重要;当然端上的小伙伴在这个阶段可参与的空间也更多。
主要有哪些方式呢?
通常一个接口承载了较多的内容的话,其内容就会无限的进行膨胀,如果将埋点,日志,反馈等非主线的数据进行多段返回的话将会有很大的收益,此方案主要结合接口组成进行分析;当然,此方案改动量也比较大,成本也比较高。
大多数我们接口使用的是TCP协议,相比来说如果更换UDP协议,接口返回速度会快不少,详细原因可以翻一下资料学习一下,这里不再多说。
目前也已经有成熟的方案,比如阿里的XQUIC,有感兴趣的可以了解一下,具体的收益我这里也还在测试中。
为何缩小网络包会降低网络传输时间呢?
客户端和服务端网络通信时数据传输过程如下图所示:
数据包越大,则在光纤传输时所需的时间就会越久,因此接收方等待数据包的时间也会更长,最终会导致应用层等待数据时间变长。
还有,由于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%
数据表明,针对重复字段的精简,压缩后依然是有效的。
压缩后降低率依然有46.9%。
拿到这个结果后,如何做呢?
▐数据查找表
将重复的业务数据在第一页的数据中建立字段的查找表,然后通过端上进行合并操作,具体方式:
但是,与服务端的同学对方案时,发现请求的第一页数据放置查找表,服务端不容易实现,因为数据在下游。
调整方案,将数据查找表改放置在每一页数据中,这样服务端更改就非常少了,实现也比较简单。
但是数据放在每一页,压缩后还会有收益吗?来看一下实验的结果:
采用压缩方式:gzip的压缩方式
压缩比:best模式(系统缺省值6)
方案1:
将负反馈数据查找表放在第一页数据中:
优化前后:降低45KB
降低率 :1 - 61 / 106 ≈ 42.2%
方案2:
将负反馈数据查找表放置于每一页数据的头部:
优化前后:降低43KB
降低率 :1 - 63 / 106 ≈ 40.5%
实验发现,查找表的数据仅仅占用2KB,优化依然有效。
▐优化效果
在原有的数据包下,线下实验,精简字段会将数据包从106KB降低至63KB;线下的实验可以得到接近90ms的优化;
缩小接口返回数据的个数,从50个降低至20个,数据大小大约降低63KB,网络传输耗时减低107ms;
结论
注:
团队介绍
我们是大淘宝技术-用户产品技术,团队主要负责电商核心基础链路业务和平台的研发,包含:手机淘宝首页、信息流、NewDetail、商品详情、购物车、全域触达、分享购物车、消息平台等电商核心基础能力及创新型业务。这里有世界一流的技术产品,有超大的电商基础场景,有百亿级别的数据、有超过百万QPS的高并发流量,有丰富的业务场景,服务于10亿级的消费者,这里有巨大的挑战等着你的到来。
作者:马啟超(是也)
出处:https://mp.weixin.qq.com/s/NYUuP1mG2o1E6QkVUoRjiw