经过工作 4 年,多个性能项目的实战,我总结了一份各个性能项目共性的东西(即如何做性能的流程),希望大家拍砖。我把性能测试的分为三大块,即前期准备、实战监控、问题定位。
这个是基础,前期准备工作做的越扎实到位,测试结果会越接近真实,也就更有意义,而且工作量也是蛮大的。
1、熟悉系统架构,业务主流程,确定性能测试的核心测试模块;(找开发人员或者项目经理要相关文档,至少应该熟悉到指定业务会涉及到后台的哪些表,哪些表的数据量会比较大,提前有个性能可能会出现的估测;另外测试服务器、中间件、数据库等的拓扑结构必须也得了解)
2、性能测试的具体模块的需求:必须要具体,特定的条件下,包括多少用户,多久时间,多大数据量下进行什么业务,最终指标多少。即,获取的性能需求是在特定的场景条件下的,而不是孤立的一个数值。(最真实的数据是通过系统访问日志分析真实的负载和主要业务场景来获取性能需求),(目前大部分的产品性能测试都是有个大概的性能指标,而且是人工拍出来的结果,所以性能测试的目的都是评估该系统的处理能力能否达到和预期的一样)
3、性能测试的场景选取:单业务,混合业务,稳定性,大数据量,可靠性(即其中一台 tomcat 或者其他中间件出故障后的处理,数据库灾备的切换等),(这些场景并不一定每个接口都需要涉及,看实际线上的使用情况,有选择性重点的测试)(想清楚应该选取哪些场景,其实性能测试用例的雏形也就有了)
4、性能测试数据确定:具体对应什么表需要多少数据量;以便提前准备测试数据。(尤其是有些测试数据比较复杂,会不同表之间有关联,可以找开发一起商讨一下测试数据如何弄;另外准备的测试数据一定要有效,否则你传参给函数,返回的都是失败的,这个测试结果就和真实有出入,导致测试无意义)
5、性能测试用例的编写;包括:场景描述,并发量,压测时间,数据量,加压方式,测试方法,重点关注指标,预期指标等。(这个性能测试用例一定要好好写,而且是必不可少的,因为我觉得把这个写的越清晰明了,对核心业务或者说压力业务也就梳理的越透彻;完成这一步,其实心里就已经对该系统如何进行性能测试心里有数了)
6、性能测试环境的准备:在相应的服务器上安装性能相关软件,如 JDK,nmon,jmeter,orzdba 等。(实际由于资源有限,只是在现有的硬件资源条件下,评估性能能力,从而间接的估算生产环境的性能。)
7、性能测试脚本的调试。性能测试脚本可以用本地的图形化界面的 jmeter 进行调试,方便查看返回的是什么错误。(如是接口性能测试,参考文档是接口的开发文档等;脚本调试成功后就可以上传到相应的压力服务器上,利用非图形化的 jmeter 压测)
前期的准备工作做好后,万事俱备,就差跑起来了。
1、开启实时监控后,启动性能脚本,开始压测。(压力机服务器,数据库服务器,业务服务器开启 nmon 的后台监控;数据库服务器的慢查开关、无索引开关)
2、压测时候重点观察数据库服务器和业务服务器;(需要查看业务服务器的处理日志情况,看里面是否有错误,如 tomcat 日志;查看数据库服务器的慢查和无索引的日志;查看服务器本身的状态,如 cpu、io、memory 等)
这个是难点也是最体现性能工程师价值的地方,需要平时不断的下功夫钻研和积累的。
1、硬件资源消耗情况。(cpu,内存是否消耗过大,io 等待是否很多,负载值是否很大,连接数是否超过限制,打开文件数是否过大等。这些是表现,我们得通过表现去分析到底是什么原因导致该现象的出现。)
2、Mysql 数据库服务器。(可以用 show processlist 不定时的查看目前数据库连接都在干什么,有没有消耗时间比较长的,如有,这个连接就是怀疑对象;慢查询是否很多,如有需要优化 sql 语句或者表结构加索引等;有无锁消耗的时间很多,查看使用的数据库引擎,不同的引擎锁的粒度不一样;另外,更加不同项目不同的业务情况;
3、mysql 配置参数的设定也是很关键的,这个也需要留意。比如更新比较多的表,其实缓存对它来说就是没有意义的,诸如此类的。)
4、JVM 运行情况。(目前 95% 的都是基于 java 的开发的项目,可以用 jstack 分析线程堆栈的运行情况,利用 jstat 分析 GC 情况,定位有问题的地方(如死锁,死循环,资源等待锁,内存泄露等))
5、中间件运行情况(目前,我遇到的都是 tomcat,查看启动的各个参数是否需要调优,如内存分配是否合理,垃圾回收的算法等)
6、网络情况(对于传输数据量大的测试,在并发大的情况下必须考虑网络有无瓶颈)
以上就是性能测试的大部分环节,内容很多,需要提升的东西也很多,如图,每一块都可以成为某一领域的专家。
大家可持续关注大话性能公众号,不断学习测试实战技能和高薪岗位内推。