记一次性能测试实践1

了解需求规格说明书，性能测试需求，具体指标，系统状态（可用不可用，功能、接口开发进度）等
项目未开始前的充电，看书学习、网络博客查找资料，各种监控指标的含义，用法等等都看看，有备无患。
性能测试计划和测试方案先写，清楚做事的方向。追开发要各种文档，要明确的写出来，邮件或者word明确的告诉你，不要口头通知。
性能测试计划可根据上线时间倒排时间，但要给自己留有足够的时间准备，写脚本，写用例等等
几个重用的监控工具要掌握使用，清楚里面每个指标的意思。常用命令：top,vmstat,jstat,iostat,df -h,sar,nmon.有些命令需要提前安装在服务器上，注意提前检查，
不然命令刚要用时方狠少，那个捉急啊。

这次新开发的系统，其实文档开发没有给全，但有个重要的接口需要提前验证，所以开发组长带头，指定人跟我对接，效率真的很高。所以，有时候搞定那个带头人，比搞定其他
人都重要，虽然这次我没有搞定开发组长，不过迫于项目紧急，他不得不动员别人也快速响应，我要什么资料都立马给弄来，真想说句粗话...

各项文档齐全：需求规格说明书，性能测试需求文档，明确的指标要求，接口地址及详细说明，服务器地址和账号密码，压测工具、监控工具、测试用例、脚本代码等
说明：服务器最好自己能使用，性能测试嘛，自己不能动手监控指标，还谈毛性能测试，看jmeter的聚合报告没啥卵用，具体的异常信息还得通过服务器分析。另外，自己
自己动手，提高性能分析能力，又加强对命令的学习，这，不香吗？加班你都觉得爽歪歪。
与开发协商好，沟通要做好，毕竟这玩意不是一个人能弄得了的。开发是对代码最熟悉的人，有些异常需要开发分析才能知道情况，比如日志debug是否开启，是否往磁盘里
写日志，规模多大等等。

先用postman或者jmeter单次调用接口，查看请求是否成功，若不成功，分析参数，请求头或其它设置是否正常。反正单接口测试必须通，不要鸟别人说多少次给你说可以用，
测通了才有后面的故事。
按性能需求的并发数执行脚本代码，循环次数和持续时间都刻意设置相对少一点，先做个预测试，根据结果再去调整并发数或者时间。若是一开始就发现了明显的异常，比如
响应时间已经超过目标很大了，那大概率问题会比较容易发现，把持续实践设置稍长一些，用top命令监控，观察CPU,内存，IO,平均1分钟，5分钟，15分钟等的负载情况去分析，另外还必须留一下磁盘空间利用率，可能IO读写非常大，导致磁盘空间可用减少，那要分析什么操作在大量写入磁盘。
处理比较明显的问题后，关注不大容易找到问题的异常信息。比如这次，CPU高(80%以上)，内存正常(20%多一些)，IO正常，基本没什么东西频繁读写。那究竟是个毛原因
导致的呀，问度娘，嗯，没错，有问题找度娘，我也是一边搜索问题，找思路，一边尝试。一般性能测试问题在网上回答还蛮多，这次我的问题思路：

不巧，这次打印只有关于一些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不熟悉，不然可以直接自己查找了。所以能搞还是自己弄最好，不行最后就交给开发处理吧。等处理完后再验证调优结果。