很早之前就说好好总结一下自己的职业,一直忙于一些乱七八糟的事,现在这个时间难得偷得空闲,趁着有感觉,赶紧进行敲下“这些年,我的软件性能测试”来祭奠我这IT行业的几年......
记得第一次做性能测试项目,心情是忐忑的,觉得,性能测试,做不好就背包滚蛋了都可能,不过当时带我做项目的老大给了我很大的信心和支撑,我在做的过程中,遇到的疑问,他都会耐心的给我以解答或者给我一个方向,让我去前行,解决,随着一个个问题的出现和解决,自己每一天也过的感觉很充实。也是在这个项目里面,这个老大告诉我,作为性能测试,如果仅仅只会用工具,这个只能算初级性能测试工程师,重要的还是设计能力,思想为王,于是,我从他口里听到了一个词:性能建模和容量规划......当时,我真心的不知道这个是什么,有的就是对老大的崇拜和对未来的路如何走的思考......
第一个性能项目,如期完成,对google的GA插入的js代码进行测试,验证该js注入website之后,对性能的影响(因本身js需要做下载和数据上报,中间的过程需要看下情况如何),测试过程中,发现会有大部分的用户响应时间比较长,当时就是按照2-5-10法则来做的响应时间是否合理(想想,这个就是传说中的拍脑袋吧呵呵),想到该如何分析是哪里原因呢?第一次做性能测试,看到结果之后,欣喜的同时更多的是一种忐忑,不知道对着面前的report该如何下手?好在,有老大给予指导,分析了带宽,排除带宽的影响,查看server本身的资源,也无问题,同时细分验证,发现大部分的时间是消耗在server层,于是基于此基础,直接看了下apache(当时我们用的server)的队列等待(当时用的方法很简单,直接ps -ef|grep httpd|wc -l),发现随着虚拟用户的逐步增多,会造成排队的数也越来越多,初步怀疑是配置问题,咨询了运维,apache 的配置没有动,用的默认的配置方式,于是我们提出,需要查看并尝试调整该配置文件。在查看的过程中,参考网上朋友的资源,发现maxclient的确是默认的,修改之后,进行重启,回归,发现问题还是存在,,,难道是别的地方慢?怎么弄呢?这个时候运维告诉我们,apache只修改这个还不够,还需要修改一个隐藏变量,serverlimit,只有修改了它,maxclient修改超过1000的时候才会生效。于是也是瞎子摸象,动手试一试,发现,果真是这里,修改了之后,排队的用户减少了,超过5S以上响应时间的用户百分比也降低,于是开始准备性能测试报告(报告写了我十多次才发出去,那个苦啊~~~),顺便给予运维建议,因当时这一服务对应的apache是单点,建议去除单点,再申请一台机器作为热备,高峰时还可作为balance功能使用。于是,我的第一次性能测试,随着这第一份性能测试报告的发出,结束了.......也从此,我开始踏上了性能测试的路,开始爱上了性能测试
在后面的工作中,大大小小的项目也接触了一些,零零散散的一些性能问题也跟研发,DBA一起定位,调优解决了,但是慢慢的我在思考,性能测试就是这样了吗?在随后而来的一次项目中,让我知道,其实性能测试并不如此,远非我之前看到的,之前看到的还不够深入......
记得那次项目,是对c++开发的一个搜索服务server的测试,在测试的过程中,发现,开始没多久,磁盘就速度变大,内存也消耗的很快,cpu飙的特别快......可并发用户才5啊,,,,这个问题会在哪里呢?cpu飙的特别快,那一般是运算复杂,调度频繁,切换频繁等原因造成的,于是,找到研发,咨询相关的算法,是否过于复杂,可否再优化?研发也好沟通,给耐心的讲解了算法,并回复,当前无法再优化,只能后面逐步来看。那难道就这样放出去?反正公司不差服务器,堆服务器就是了,硬件解决性能问题似乎成了行业的潜规则,而且产品也说了,平常根本也没多少人会用这个,这样的问题,他们也可以接受......就这样发到外网?不,作为一名性能测试工程师,如果就这样洗洗睡了,那我们的价值在哪里?于是,跟研发建议,如果确实是算法的问题,在当前我们无法进行修改,调优的基础上,是否可以进一步请求资深和专家研发给予check和给予建议,对该风险进行分析?于是,研发开始进一步确认到底是算法哪一块,哪一处消耗最多,戏剧的是,分析到最后,发现该问题并不是算法是主要凶手,之前冤枉了算法,而是程序本身的一个bug,研发之前对于c++里面用到的hashtable,错误的认为是有序的,但实际该hashtable在处理的时候是无序的,从而造成每次都会生成新的追加的文件,这样文件越来越大,造成磁盘疯狂的长,同时写磁盘这个过程对cpu的占用也就飙的很高,再一个,读数据的时候,之前都是直接很疼的从磁盘上拿,没有做map处理,map处理之后使得程序都从内存里面读,这样响应时间也得到了有效的提升,并且,研发还对不该加锁的地方进行了顺序读的锁处理进行修复,导致server的吞吐率得到提升......最终,版本打回研发,研发自测后,再进行提测和验证
在上个项目中,让我觉得,作为一名性能测试工程师,不要错误的将自己定义为架构师(很多行业的人都觉得性能测试工程师很牛逼,牛逼的过程中,不自然间就把这个职位等价成了架构师,其实我想说,架构师是高于性能测试工程师的),但是,一名优秀的性能测试工程师应该不断的靠近架构师,只有这样,才能真正的从根本上去发现,解决问题,才能在研发体系中更好的体现自己的价值.也在这个项目之后,我开始思考并有了后面我主导的一个虚拟项目,“BMW软件性能平台”(据说名字霸气点是好事:))......
另:这些年的项目经验,还让我认识到,对于有的性能问题,在调优的时候,并不是说就一定需要用技术解决的,有的问题,技术不能解决的,需要思考和尝试业务需求上的调整,有的性能问题的定位和分析,并不是说就一定要那么费劲周折,高并发,查这里,看那里来定位和解决,有的只用单个用户,发个请求,抓个包,看下timechart,看下代码构成,就可以解决了.性能测试,我一直坚持,它跟监控是离不开的,有了监控,有了数据准备和数据收集,我们才能更快更好的发现问题,分析和解决问题(这个也是我弄“BMW软件性能平台”的原因)
这些年,我的软件性能测试项目经验,让我获得了很多,也失去了很多,对于行业的认识也看的更加深入了些,开始接触并学习之前根本不知道的语言内核知识,TCP/IP原理等网络知识,深深的感觉到学海无涯,而吾身有涯......
这些年,我的软件性能测试,写在我即将逝去的28岁......
====================================分割线================================
最新内容请见作者的GitHub页:http://qaseven.github.io/