事先准备：

了解需求规格说明书，性能测试需求，具体指标，系统状态（可用不可用，功能、接口开发进度）等
项目未开始前的充电，看书学习、网络博客查找资料，各种监控指标的含义，用法等等都看看，有备无患。
性能测试计划和测试方案先写，清楚做事的方向。追开发要各种文档，要明确的写出来，邮件或者 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 不熟悉，不然可以直接自己查找了。所以能搞还是自己弄最好，不行最后就交给开发处理吧。等处理完后再验证调优结果。

↙↙↙阅读原文可查看相关链接，并与作者交流