如何判断一个应用的流量消耗偏高
如果看流量的绝对值看不出高低,那就找几个同类型的产品对比一下。如果完成同样的
事务,被测应用比同类产品高很多,那就是偏高了,可能有优化空间。
如何找到有效的优化点
把分析的不同类数据包,按包占总流量大小的比例,和包的数量排序,占比多的,和消
息数量多的,一个优化空间大,一个精简请求次数的机会大。
常见的流量问题
最后简单例举几类可控的比较容易优化的流量问题给大家:
冗余内容
同类请求被间隔执行,请求的内容包含一些相对静态的信息,正确的处理是第一次请求
包括静态信息就好,后面的同类请求只包含必要的即时变化信息即可。错误的处理方式是每
次请求服务器都返回一次静态信息。
冗余请求
有的时候会发现应用短时间内发出多个同样的请求,收到结果也都几乎一样,这种情况
应该尽量减少请求次数,同时注意排查程序逻辑错误,也许问题不像表面看起来那么简单。
无用请求
有的请求,你会发现谁也不知道它是干嘛的,很可能是以前版本遗留下来的无用请求,
或者是引用的其他代码包偷偷发出的,甚至是间谍请求,请收集一切证据后,毫不犹豫的干
掉它。
永远无法得到回应的请求
如果见到某类请求永远是连接失败或被返回 404 之类的失败结果,那它不是历史遗留的
多余请求,就是某个不易察觉的功能已经失效了。
过多的失败请求
有见过一类或一组请求,n 个成功之中夹着 m 个失败的吗?举个简单的场景,某类请
求,间隔 1 分钟后连续发两次,总是先有一次失败的请求,1s 后马上再次发出一次同样的
请求就成功了(这里 1s 后发出的请求是指业务逻辑层判断前面请求失败后延迟 1s 后重传
的)。很好奇为什么第一次总失败是吧,就有这种情况,客户端两次请求乐观的想要复用
同一个 TCP 连接(长连接半长连接),但是服务端不这么想,也许是客户端发起两次请求的间
隔,超出了服务端长设置的长连接无响应时限。。如何判断呢?看看失败的那次请求,是否
和前一次成功的请求复用了同一个 TCP 连接(体现在 Wireshark 的 streamId)。
非预期请求
比如一种常见的情况,应用退后台后,有些请求就没必要了,观察下自己的产品,是
否在后台真的没有发出这些请求。