前言
对于压力测试结果的分析没有一个系统的思路，在压力测试结果不符合性能指标时无从下手，也无法向开发提出有效的优化性能的方法。在对多个项目分析后，总结出一个通用的分析思路，可以快速定位性能瓶颈。
分析思路
压测结果分析基本原则：
整体分析思路如下图所示
其中客户端问题概率较小。主要分析重点在网络问题及服务端问题上面。
网络问题：
- 负载均衡：在动态负载均衡器上设置动态分发负载的机制后，如果发现某个应用服务器上的硬件资源已经达到极限，动态负载均衡器会将后续请求发送到其他负载较轻的应用服务器上。此时若发现动态负载均衡器没有起到作用，则可以认为是网络瓶颈；
服务端问题：
操作系统：当出现物理内存不足时，需要设置虚拟内存，若设置不合理，虚拟内存的交换效率就会降低，从而导致响应时间增加；其他参数如缓冲区大小、系统文件描述符等都会对服务器性能产生较大影响；
SQL效率低下：主要原因有未建索引或使用性能低的索引、嵌套查询、产生锁等待或死锁；
中间件：主要包含线程是否够用，是否存在线程阻塞，JDBC连接池是否够用，GC/FULL GC是否频繁及垃圾回收的时间等因素；
硬件方面：CPU资源利用率较高主要看消耗在哪些进程、系统调用的资源消耗，内存问题主要看某个进程占用内存及虚拟内存交换swap，硬盘方面主要是繁忙率及传输内容大小上。
性能监控常用命令：
虚拟内存统计：vmstat。主要对操作系统内存、swap、io、cpu信息进行监控；
进程资源占用：top。top命令提供了实时的对系统处理器的状态监视，显示系统中CPU最“敏感”的任务列表；
系统负载：uptime。可以看到系统1分钟、5分钟和15分钟内的平均负载，一般这三个值不能大于cpu个数，如果长期大于cpu个数说明系统很繁忙负载高；
网络相关信息：netstat。用于显示与IP、TCP、UDP和ICMP协议相关的统计数据，一般用于检验本机各端口的网络连接情况；
内存相关信息：free。显示Linux系统中空闲的、已用的物理内存及swap内存,及被内核使用的buffer；
sar：目前 Linux上最为全面的系统性能分析工具之一。可统计出文件的读写情况、系统调用的使用情况、磁盘I/O、CPU效率、内存使用状况、进程活动及IPC有关的活动等；
磁盘I/O：iostat。对系统的磁盘I/O操作进行监控。汇报磁盘活动统计情况，同时也会汇报出CPU使用情况；
常见瓶颈点分析
| 性能瓶颈出现频次 | 具体表现 |
|---|---|
| 高 | TPS波动较大 |
| 高 | 未到期望并发前出现大量报错 |
| 中 | 并发数不断增加，CPU耗用不高 |
一、TPS波动较大
1、原因解析：
出现TPS波动较大问题的原因一般有网络波动、其他服务资源竞争以及垃圾回收问题这三种。
2、排查方法：
2.1 压力测试环境一般都是在内网或局域网内进行，可通过监控网络的出入流量来排查；
2.2 其他服务资源竞争也可能造成这一问题，可以通过top命令或服务梳理方式来排查在压测时是否有其他服务运行；
2.3 垃圾回收问题相对来说是最常见的导致TPS波动的一种原因，可以通过GC监控命令来排查，命令如下：
GC信息输出到文件
jstat -gc PID 1000 120 >> /path/gc.txt
jsatt -gcutil PID 1000 120 >> /path/gc.txt
二、未到期望并发前出现大量报错
1、原因解析：
出现该类问题，常见的原因有短连接导致的端口被完全占用以及线程池最大线程数配置较小或超时时间较短导致。
2、解决方案：
短连接问题：释放TIME_WAIT scoket用于新的连接；
线程池问题：修改服务节点中容器的server.xml文件中的配置参数，主要修改如下几个参数：
最大线程数，即服务端可以同时响应处理的最大请求数：maxThreads="200"
Tomcat的最大连接线程数，即超过设定的阈值，Tomcat会关闭不再需要的socket线程：maxSpareThreads="200"
等待超时的阈值，单位为毫秒，设置为0时表示永不超时：connectionTimeout="20000"</pre>
三、并发数不断增加，CPU耗用不高
1、原因解析：
- 出现该类问题，常见的原因有：SQL没有创建索引/SQL语句筛选条件不明确、代码中设有同步锁，高并发时出现锁等待；
2、解决方案：
SQL问题：没有索引就创建索引，SQL语句筛选条件不明确就优化SQL和业务逻辑；
同步锁问题：是否去掉同步锁，有时候不仅仅是技术问题，还涉及到业务逻辑的各种判断，建议和开发产品同事沟通确认；
结束语
性能测试结果分析是性能测试过程中的最后一步，也是一个非常重要的部分，以系统的思路进行分析，可以一层一层剥离问题表象，找到真正的性能瓶颈并进行优化，提升整体服务性能。
