很早之前就说好好总结一下自己的职业，一直忙于一些乱七八糟的事，现在这个时间难得偷得空闲，趁着有感觉，赶紧进行敲下“这些年，我的软件性能测试”来祭奠我这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/