性能压测总结-测试结果分析和问题排查

明确问题
首先我们要确认是哪些性能指标不达到要求，或者需要改进

常见的性能指标：
用户体验层面

• 用户响应时间

就是用户感受软件系统为其服务所消耗的时间。对于web系统，请求的相应时间指的是从客户端发起的一个请求时间，到客户端接收到从服务器返回的相应结束。在互联网上对于用户响应时间，有一个普遍的标准：2/5/10秒原则。
也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。

 

事务处理层面

• 每秒处理事务（TPS）
• 事务平均响应时间（RT）

1.  90%响应时间

• 并发用户数
• HTTP错误率

这里有个简单的关联关系：并发用户数/TPS/RT之间的关系
假如并发数为10，接口RT为500ms，那每秒钟通过的请求数（TPS）应该为10*（1000ms/500ms）= 20
此处仅为简单换算，如果数据出入较大，需要进一步分析。

另外最优并发和最大并发之间的关系，在上一篇已经讲过了，可以参考这篇文章
https://www.cnblogs.com/jackei/archive/2006/11/20/565527.html

服务器资源层面

• CPU使用情况
• 内存使用情况和持续表现
• 磁盘IO速度
• 上行/下行网速情况

​

排查原则
为了能快速的排查分析，我们建议排查顺序为：从表及里，从易到难。
按照下面这个图的话，建议由左到右，由上到下

可能会出现瓶颈的地方
 

硬件瓶颈：
一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈
 

中间件性能瓶颈：
web软件，数据库，缓存等

应用程序瓶颈：
JVM参数不合理，容器配置不合理，慢SQL，慢事务，数据库设计不合理，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够、无缓冲、无缓存、生产者和消费者不协调等），造成系统在大量用户方位时性能低下而造成的瓶颈。

操作系统瓶颈：
连接数，虚拟内存，内核参数等

网络设备瓶颈：
包括但不限于SLB/WAF/高防IP/CDN/全站加速等
​

 

几种常见的瓶颈

1、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%！）

2、高并发下大量报错
原因解析：出现该类问题，常见的原因有短连接导致的端口被完全占用以及线程池最大线程数配置较小及超时时间较短导致。
调优方案：

• 短连接问题：修改服务节点的tcp_tw_reuse参数为1，释放TIME_WAIT scoket用于新的连接；
• 线程池问题：修改服务节点中容器的server.xml文件中的配置参数，主要修改如下几个参数：

# 最大线程数，即服务端可以同时响应处理的最大请求数
maxThreads="200"                        
#  Tomcat的最大连接线程数，即超过设定的阈值，Tomcat会关闭不再需要的socket线程       
maxSpareThreads="200"               
#  所有可用线程耗尽时，可放在请求等待队列中的请求数，超过该阈值的请求将不予处理，返回Connection refused错误
acceptCount="200"                 
#  等待超时的阈值，单位为毫秒，设置为0时表示永不超时
connectionTimeout="20000"         
 

3、集群类系统，各服务节点负载不均衡
原因解析：出现这类问题的原因一般是SLB服务设置了会话保持，会导致请求只分发到其中一个节点。
调优方案：如果确认是如上原因，可通过修改SLB服务（F5/HA/Nginx）的会话保持参数为None，然后再次压测验证；

4、并发数不断增加，TPS上不去，CPU使用率较低
原因解析：出现该类问题，常见的原因有：SQL没有创建索引/SQL语句筛选条件不明确、代码中设有同步锁，高并发时出现锁等待；
调优方案：

• SQL问题：没有索引就创建索引，SQL语句筛选条件不明确就优化SQL和业务逻辑；
• 同步锁问题：是否去掉同步锁，有时候不仅仅是技术问题，还涉及到业务逻辑的各种判断，是否去掉同步锁，建议和开发产品同事沟通确认；

5、压测过程中TPS不断下降，CPU使用率不断降低
原因解析：一般来说，出现这种问题的原因是因为线程block导致，当然不排除其他可能；
调优方案：如果是线程阻塞问题，修改线程策略，然后重新验证即可；

6、其他
除了上述的五种常见性能瓶颈，还有其他，比如：connection reset、服务重启、timeout等，当然，分析定位后，你会发现，我们常见的性能瓶颈，

导致其的原因大多都是因为参数配置、服务策略、阻塞及各种锁导致。。。
​

​

参考文章：
https://blog.csdn.net/weixin_43820813/article/details/109715497
https://www.cnblogs.com/aresxin/p/p63464523.html
https://www.cnblogs.com/Mr-xiao/p/6992948.html
https://www.cnblogs.com/imyalost/p/10850811.html
​

关于性能测试，安利下虫师的博客，各种内容非常详细。
https://www.cnblogs.com/fnng/