有人的地方就有江湖,有代码的地方就有Bug!压测如同照妖镜 妖怪哪里逃! 业务代码、核心代码、机器配置通通无处遁形 藏得再深,藏得再久,也逃不出压测的猛烈攻击!压测实战分享

压测如同照妖镜 妖怪哪里逃! 业务代码、核心代码、机器配置通通无处遁形 藏得再深,藏得再久,也逃不出压测的猛烈攻击!压测实战分享是这阵子感触比较深的!压测在于暴力,在于并发,在于无情。一个铁的事实标准摆在面前,从配置到代码,从业务到核心,从cpu到硬盘,从网络到逻辑,方方面面,能争取一秒算一秒,能榨一毫秒算一毫秒!压测能把潜伏在系统里的深层Bug暴露出来,经典到格致,让人难以忘却所在所闻!下面从几个方面分享一下。

一、压测反推工程结构

压测与代码工程结构的千丝万缕关系。从压测的角度来看,代码至少要分成两部分,一是可控代码,简单的说,就是项目中的业务代码,因为是自己写的,所以可控性很强,压测的时候,可以针对性优化;二是不可控代码,像调用的第三方接口,这种没法自主控制。如图示,agent中存放与第三方交互的代理类。压测的时候,区分开可控代码与不可控代码。可控的代码就自己优化 ,不可控的代码,如果是公司团队提供的,就去沟通一下吧,对于外部公司的Agent,那真的是超级不可控了,直接忽略吧。在工程结构上来分析,建议Agent的异常要及时抓住并记一条神奇的【甩锅】日记,看看日志,就能快速定伴Agent对应的团队人员,找到快速处理问题。最好,把第三方的交互统一加上try-catch,记下异常。这样子,可控与不可控就划得很清楚了。

二、不要迷信核心代码

使用核心代码公共类库是一件很开心的事情,省下很多不必要的时候,省下的不仅是时间,更是一堆堆重复代码,可以让人关注业务。然后,千万不要迷信核心类库的代码,所谓有人的地方就有江湖,有代码的地方就有Bug。

这次压测,压到一个神奇的核心库Bug。具体表现为,controller捕获了2%左右的失败,有时候又没有错,这个错误一直在0%到2%的样子。为了查这个压测失败的问题。查看失败日志,能定位到Ip获取环节。但是不知道为什么会失败,断点调试,一切都是正常的,只是压测的时候,总能重现异常。

难道核心库有问题?这个简直不敢想,对于核心库,一直以来都是膜拜啊,拿来用,没有想过核心库会有Bug。但是面对压测的数据,又没法排除核心库的嫌疑,只能对核心库代码进行排查了。

如果构建核心库的时候,把源代码打进去,我觉得对于使用者来讲,绝对是一个福音。可惜我面对的这个核心库没有,还好之前把源代码打进去了。单个调试一切显示正常,压根调试不出任何问题。简单就是诡异到头了。

肿么办,抓掉几根头发后,突然灵光一闪。直接把代码Copy出来,将ip获取的代码逻辑加上步骤日志,从第一步到第六步,一一打出来,进行压测,日志显示,所ip获取的时候,步骤都是正常的。但是期间能出现还是出现了异常。看步骤的话,从request中取ip的代码逻辑并没有出现bug。面对诡异的压测结果,那就再想想。

看样子,从reqeust中取ip的逻辑没有问题,那就把取ip的地方加上try-catch抓一下日志。果真发现Bug了,使用ip的时候,出现了ip为空,导致异常了。

再往回看代码,发现static,发现new,一下子,抓到了Bug,这可是14年种下的bug,19年才来杀。这段代码的bug,可以描述为static误用。来来,展示一下bug的样子,希望你不要写出这种级别的bug,不好发现,不好杀,sonarqube查不出来,普通使用,一切正常,只有压测才会现形。花了8个小时才杀,不要问我为什么花了这么多时间。当核心代码在sonarqube的检查下,呈现出很多bug,很多坏外道。核心类库,想说爱你不容易~

static误用示范public class Ip{
 private string address; 
 private int ipNumber; 
 private Ip ip;  
private Ip(){   
 //sonarqube说禁止外面创建实例  
}  
public static getIp(Request reqeust){   
 ip = new Ip();   
 ....    ...    
//相信我,这里是复杂的ip识别与获取逻辑
...    
...  
}  
public String getIpString(){
     return ip.address;  
}}

压测的时候,不要迷信核心类库,把工程分成三大块,业务代码,核心类库,agent,对应三种不可控级别的代码。业务代码自己搞定,核心类库慎重的找人处理,并[AT]尽量多的人,Agent找人处理或者直接排除掉。

三、压测与机器配置

机器本身配置不行的话,压测就凉凉了。同事测试了机器硬盘读写性能,发现硬盘读写就把时间消耗没了,更不要谈压测业务代码了。提供一台标准的压测机器,是合理的前提。压测不过,不仅仅是代码,这一压,也得看机器本身性能。

压测就像一面照妖镜,英雄不问出处,是驴是马,拉出来溜溜就知道了。面对事实的标准,如何才能将压测做得更好呢?

1、压测环境与压测要匹配

在一个标准性能环境下,达到一个预期的压测值。这个标准环境,比如cpu,硬盘读写性能,可以是一个标准的。或者拿一个基准接口进行压测定值,先测算出环境本身适合的压测值。这样子,压测才能正常的进行。

2、压测环境最好有多个

接口多,接口要一个一个压,一个环境不好并行压。能有多个环境最好。不知道下次压测能不能实现,毕竟要有机器。

3、核心类库必过压测

核心类库都过不了压测的,放在核心类库里,这个有点点坑啦。又要用核心类库,又要过压测,没解。核心类库打上源代码,压测的时候,还可以用源代码进行压测调试。但是希望是通过压测的才放进核心类库,不要等业务代码进行压测的时候,再来找出核心类库的Bug.

4、核心类库必过sonarqube

为什么又扯到sonarqube,其实这个工具的强大之处在于,能分析出很多坏味道与bug,人不同于工具,工具在于将所有可性能全面覆盖分析,人没人注意到的地方,sonarqube可以注意到。这次压测就发现,核心库代码的规范性,并没有想像的美好。sonarqube找出了一堆坏味道,还有bug.

这次压测实战,感觉收获还是很大的。对于工程结果的理解,对于异常的捕获处理,对于核心库的优化改进,都有了新的认识,对于压测,也有了自己一套方案。希望你也能从中学到宝贵的经验!

关注公众号,我的经验就是你的经验!