性能测试常见瓶颈分析及调优方法
在性能测试过程当中，最重要的一部分就是性能瓶颈定位与调优。而引起性能瓶颈的缘由是多种多样的，在以前的博客：常见的性能测试缺陷有进行介绍。html
这篇博客，来聊聊性能测试过程当中的一些注意事项，以及常见的一些性能缺陷表现及如何进行定位分析而且调优。。。网络
1、注意事项并发
一、断言运维
在压测时，为了判断发送的请求是否成功，通常会经过对请求添加断言来实现。使用断言时，建议遵循以下规范：socket
①、断言内容尽可能以status/code、msg/message来判断（固然前提是接口设计遵循Restful规范）tcp
Jmeter示例：高并发
阿里云PTS：性能
若是使用的是PTS压测，则断言设置中，以code/status、msg/message等于对应的值为准；测试
②、尽量不要将全部的Response Body内容做为断言判断的内容，这样极可能会致使大量的“断言”失败；优化
PS：而后很遗憾的是，见过不少作压测的童鞋，断言内容以整个响应参数内容作断言，致使大量的报错。
二、成功率
通常在性能测试中，咱们都追求99.99%的成功率，但在实际的测试过程当中，为了尽量覆盖代码逻辑，在准备阶段会尽量的准备较多的热点数据去作到覆盖。
这样的话，咱们所关注的成功率指标，就要分为以下两种：
①、事务成功率
事务成功率在某些时候也能够视为请求成功率，在断言判断时以code/status等内容来做为请求是否成功的衡量依据；
②、业务成功率
实际的业务场景中，所谓的成功率，并不能仅根据返回的code/status来判断。好比：一个查询请求，不管是返回正确的查询结果仍是因为对应数据返回空，这个请求都是成功的。
对应的响应参数多是： {"status":"200","message":"success"} ；也多是： {"status":"200","message":"暂无对应结果"} 。
PS：在性能测试过程当中，考虑到业务成功率和请求成功率的不一样指标，结合断言内容，须要灵活设置断言的方式（固然，我依然建议遵循如上的2点断言规范）！
2、常见性能瓶颈解析及调优方案
在性能测试中，致使性能出现瓶颈的缘由不少，但经过直观的监控图表现出来的样子，根据出现的频次，大概有以下几种：
| 性能瓶颈出现频次 | 具体表现 |
| 高 | TPS波动较大 |
| 高 | 高并发下大量报错 |
| 中 | 集群类系统，各服务节点负载不均衡 |
| 中 | 并发数不断增长，TPS上不去，CPU耗用不高 |
| 低 | 压测过程当中TPS不断降低，CPU使用率不断下降 |
下面对常见的几种性能瓶颈缘由进行解析，并说说常见的一些调优方案：
一、TPS波动较大
缘由解析：出现TPS波动较大问题的缘由通常有网络波动、其余服务资源竞争以及垃圾回收问题这三种。
性能测试环境通常都是在内网或者压测机和服务在同一网段，可经过监控网络的出入流量来排查；
其余服务资源竞争也可能形成这一问题，能够经过Top命令或服务梳理方式来排查在压测时是否有其余服务运行致使资源竞争；
垃圾回收问题相对来讲是最多见的致使TPS波动的一种缘由，能够经过GC监控命令来排查，命令以下：
1 # 实时打印到屏幕
2 jstat -gc PID 300 10
3 jstat -gcutil PID 300 10
4 # GC信息输出到文件
5 jstat -gc PID 1000 120 >>/path/gc.txt
6 jstat -gcutil PID 1000 120 >>/path/gc.txt
调优方案：
网络波动问题，可让运维同事协助解决（好比切换网段或选择内网压测），或者等到网络较为稳定时候进行压测验证；
资源竞争问题：经过命令监控和服务梳理，找出压测时正在运行的其余服务，经过沟通协调中止该服务（或者换个没资源竞争的服务节点从新压测也能够）；
垃圾回收问题：经过GC文件分析，若是发现有频繁的FGC，能够经过修改JVM的堆内存参数Xmx，而后再次压测验证（Xmx最大值不要超过服务节点内存的50%！）
二、高并发下大量报错
缘由解析：出现该类问题，常见的缘由有短链接致使的端口被彻底占用以及线程池最大线程数配置较小及超时时间较短致使。
调优方案：
短链接问题：修改服务节点的tcp_tw_reuse参数为1，释放TIME_WAIT scoket用于新的链接；
线程池问题：修改服务节点中容器的server.xml文件中的配置参数，主要修改以下几个参数：
# 最大线程数，即服务端能够同时响应处理的最大请求数
maxThreads="200"
# Tomcat的最大链接线程数，即超过设定的阈值，Tomcat会关闭再也不须要的socket线程
maxSpareThreads="200"
# 全部可用线程耗尽时，可放在请求等待队列中的请求数，超过该阈值的请求将不予处理，返回Connection refused错误
acceptCount="200"
# 等待超时的阈值，单位为毫秒，设置为0时表示永不超时
connectionTimeout="20000"
三、集群类系统，各服务节点负载不均衡
缘由解析：出现这类问题的缘由通常是SLB服务设置了会话保持，会致使请求只分发到其中一个节点。
调优方案：若是确认是如上缘由，可经过修改SLB服务（F5/HA/Nginx）的会话保持参数为None，而后再次压测验证；
四、并发数不断增长，TPS上不去，CPU使用率较低
缘由解析：出现该类问题，常见的缘由有：SQL没有建立索引/SQL语句筛选条件不明确、代码中设有同步锁，高并发时出现锁等待；
调优方案：
SQL问题：没有索引就建立索引，SQL语句筛选条件不明确就优化SQL和业务逻辑；
同步锁问题：是否去掉同步锁，有时候不只仅是技术问题，还涉及到业务逻辑的各类判断，是否去掉同步锁，建议和开发产品同事沟通确认；
五、压测过程当中TPS不断降低，CPU使用率不断下降
缘由解析：通常来讲，出现这种问题的缘由是由于线程block致使，固然不排除其余可能；
调优方案：若是是线程阻塞问题，修改线程策略，而后从新验证便可；
六、其余
除了上述的五种常见性能瓶颈，还有其余，好比：connection reset、服务重启、timeout等，固然，分析定位后，你会发现，咱们常见的性能瓶颈，
致使其的缘由大多都是由于参数配置、服务策略、阻塞及各类锁致使。。。
性能瓶颈分析参考准则：从上至下、从局部到总体！
以上分析及调优方案仅供参考，具体定位还须要根据日志监控等手段来分析调优。。。