事先准备:
- 了解需求规格说明书,性能测试需求,具体指标,系统状态(可用不可用,功能、接口开发进度)等
- 项目未开始前的充电,看书学习、网络博客查找资料,各种监控指标的含义,用法等等都看看,有备无患。
- 性能测试计划和测试方案先写,清楚做事的方向。追开发要各种文档,要明确的写出来,邮件或者 word 明确的告诉你,不要口头通知。
- 性能测试计划可根据上线时间倒排时间,但要给自己留有足够的时间准备,写脚本,写用例等等
- 几个重用的监控工具要掌握使用,清楚里面每个指标的意思。常用命令:top,vmstat,jstat,iostat,df -h,sar,nmon.有些命令需要提前安装在服务器上,注意提前检查,
不然命令刚要用时方狠少,那个捉急啊。
执行
这次新开发的系统,其实文档开发没有给全,但有个重要的接口需要提前验证,所以开发组长带头,指定人跟我对接,效率真的很高。所以,有时候搞定那个带头人,比搞定其他
人都重要,虽然这次我没有搞定开发组长,不过迫于项目紧急,他不得不动员别人也快速响应,我要什么资料都立马给弄来,真想说句粗话...
执行的前提(能准备全最好)
- 各项文档齐全:需求规格说明书,性能测试需求文档,明确的指标要求,接口地址及详细说明,服务器地址和账号密码,压测工具、监控工具、测试用例、脚本代码等
说明:服务器最好自己能使用,性能测试嘛,自己不能动手监控指标,还谈毛性能测试,看 jmeter 的聚合报告没啥卵用,具体的异常信息还得通过服务器分析。另外,自己
自己动手,提高性能分析能力,又加强对命令的学习,这,不香吗?加班你都觉得爽歪歪。
- 与开发协商好,沟通要做好,毕竟这玩意不是一个人能弄得了的。开发是对代码最熟悉的人,有些异常需要开发分析才能知道情况,比如日志 debug 是否开启,是否往磁盘里
写日志,规模多大等等。
实施
- 先用 postman 或者 jmeter 单次调用接口,查看请求是否成功,若不成功,分析参数,请求头或其它设置是否正常。反正单接口测试必须通,不要鸟别人说多少次给你说可以用,
测通了才有后面的故事。
- 按性能需求的并发数执行脚本代码,循环次数和持续时间都刻意设置相对少一点,先做个预测试,根据结果再去调整并发数或者时间。若是一开始就发现了明显的异常,比如
响应时间已经超过目标很大了,那大概率问题会比较容易发现,把持续实践设置稍长一些,用 top 命令监控,观察 CPU,内存,IO,平均 1 分钟,5 分钟,15 分钟等的负载情况去分析,另外还必须留一下磁盘空间利用率,可能 IO 读写非常大,导致磁盘空间可用减少,那要分析什么操作在大量写入磁盘。
- 处理比较明显的问题后,关注不大容易找到问题的异常信息。比如这次,CPU 高 (80% 以上),内存正常 (20% 多一些),IO 正常,基本没什么东西频繁读写。那究竟是个毛原因
导致的呀,问度娘,嗯,没错,有问题找度娘,我也是一边搜索问题,找思路,一边尝试。一般性能测试问题在网上回答还蛮多,这次我的问题思路:
- CPU 高其他指标正常
- top 命令查看占用 CPU 高的进程
- 查看该进程下面的线程,那个占用率高,命令:ps -mp -o THREAD,tid,time
- 将高占用率的线程用 16 进制数打印出来,为后面的查看堆栈准备,命令:print "%x\n"
- 用堆栈命令查看给线程的堆栈信息,命令: jstack | grep -A 200 tid 就是上一步用 16 进制数打印 PID 的结果
不巧,这次打印只有关于一些 GC 的信息,一旦代码信息都没有,但至少提供一个思路,GC 是跟 JVM 的垃圾回收有关,这里打印的都是 GC 的,那应该查看具体的 GC 信息。
有这个方向后,调整分析。
- 查看 jvm 的情况,使用 jstat。jstat 主要利用 JVM 内建的指令对 Java 应用程序的资源和性能进行实时的命令行的监控,根据这句话,jstat 并非所有进程都可以调用,
属于 Java 进程的都可以调用,非 Java 的应该是使用不了。用法 jstat -gcutil 2000 10 每 2 秒打印一次,打印 10 次。查看 FGC 的次数,以及 FGCT 的值,FGC 的值
不能过大。 因这个命令不熟悉,导致一直排查问题得不到头绪,最后看网文一篇文章才明白自己是参数加全,所以对命令熟悉也很重要啊。
- 明白垃圾回收频繁的原因,那可以猜测进一步的原因可能是内存不足或者内存泄露导致,那有什么方法能知道那个占用率高的 Java 进程信息呢,打印堆栈。用 jstack 命令。
jstack >> jstack.txt 将进程的堆栈信息输入到文件中,再去查看。
- 最后,代码定位。可惜我对 Java 不熟悉,不然可以直接自己查找了。所以能搞还是自己弄最好,不行最后就交给开发处理吧。等处理完后再验证调优结果。