威海 医院网站建设,商品详情页设计模板,设计案例展示网站,外贸网站建设ppt模板目录#xff1a;导读 前言一、Python编程入门到精通二、接口自动化项目实战三、Web自动化项目实战四、App自动化项目实战五、一线大厂简历六、测试开发DevOps体系七、常用自动化测试工具八、JMeter性能测试九、总结#xff08;尾部小惊喜#xff09; 前言
常见的一些性能缺… 目录导读 前言一、Python编程入门到精通二、接口自动化项目实战三、Web自动化项目实战四、App自动化项目实战五、一线大厂简历六、测试开发DevOps体系七、常用自动化测试工具八、JMeter性能测试九、总结尾部小惊喜 前言
常见的一些性能缺陷表现及如何进行定位分析并且调优。
注意事项
1、断言 在压测时为了判断发送的请求是否成功一般会通过对请求添加断言来实现。使用断言时建议遵循如下规范
①断言内容尽量以status/code、msg/message来判断当然前提是接口设计遵循Restful规范
Jmeter示例 阿里云PTS
如果使用的是PTS压测则断言设置中以code/status、msg/message等于对应的值为准
②尽可能不要将所有的Response Body内容作为断言判断的内容这样很可能会导致大量的“断言”失败
PS然后很遗憾的是见过很多做压测的童鞋断言内容以整个响应参数内容做断言导致大量的报错。
2、成功率 一般在性能测试中我们都追求99.99%的成功率但在实际的测试过程中为了尽可能覆盖代码逻辑在准备阶段会尽可能的准备较多的热点数据去做到覆盖。
这样的话我们所关注的成功率指标就要分为如下两种
①事务成功率 事务成功率在某些时候也可以视为请求成功率在断言判断时以code/status等内容来作为请求是否成功的衡量依据
②业务成功率 实际的业务场景中所谓的成功率并不能仅根据返回的code/status来判断。比如一个查询请求无论是返回正确的查询结果还是由于对应数据返回空这个请求都是成功的。
对应的响应参数可能是 {“status”:“200”,“message”:“success”} 也可能是 {“status”:“200”,“message”:“暂无对应结果”} 。
PS在性能测试过程中考虑到业务成功率和请求成功率的不同指标结合断言内容需要灵活设置断言的方式当然我依然建议遵循如上的2点断言规范
常见性能瓶颈解析及调优方案
在性能测试中导致性能出现瓶颈的原因很多但通过直观的监控图表现出来的样子根据出现的频次大概有如下几种
性能瓶颈出现频次具体表现高TPS波动较大高高并发下大量报错中集群类系统各服务节点负载不均衡中并发数不断增加TPS上不去CPU耗用不高低压测过程中TPS不断下降CPU使用率不断降低下面对常见的几种性能瓶颈原因进行解析并说说常见的一些调优方案
1、TPS波动较大 原因解析出现TPS波动较大问题的原因一般有网络波动、其他服务资源竞争以及垃圾回收问题这三种。
性能测试环境一般都是在内网或者压测机和服务在同一网段可通过监控网络的出入流量来排查
其他服务资源竞争也可能造成这一问题可以通过Top命令或服务梳理方式来排查在压测时是否有其他服务运行导致资源竞争
垃圾回收问题相对来说是最常见的导致TPS波动的一种原因可以通过GC监控命令来排查命令如下 # 实时打印到屏幕
jstat -gc PID 300 10
jstat -gcutil PID 300 10# GC信息输出到文件
jstat -gc PID 1000 120 /path/gc.txt
jstat -gcutil PID 1000 120 /path/gc.txt调优方案 网络波动问题可以让运维同事协助解决比如切换网段或选择内网压测或者等到网络较为稳定时候进行压测验证
资源竞争问题通过命令监控和服务梳理找出压测时正在运行的其他服务通过沟通协调停止该服务或者换个没资源竞争的服务节点重新压测也可以
垃圾回收问题通过GC文件分析如果发现有频繁的FGC可以通过修改JVM的堆内存参数Xmx然后再次压测验证Xmx最大值不要超过服务节点内存的50%
2、高并发下大量报错 原因解析出现该类问题常见的原因有短连接导致的端口被完全占用以及线程池最大线程数配置较小及超时时间较短导致。
调优方案 短连接问题修改服务节点的tcp_tw_reuse参数为1释放TIME_WAIT scoket用于新的连接
线程池问题修改服务节点中容器的server.xml文件中的配置参数主要修改如下几个参数
# 最大线程数即服务端可以同时响应处理的最大请求数
maxThreads200
# Tomcat的最大连接线程数即超过设定的阈值Tomcat会关闭不再需要的socket线程
maxSpareThreads200
# 所有可用线程耗尽时可放在请求等待队列中的请求数超过该阈值的请求将不予处理返回Connection refused错误
acceptCount200
# 等待超时的阈值单位为毫秒设置为0时表示永不超时
connectionTimeout20000# 最大线程数即服务端可以同时响应处理的最大请求数
maxThreads200
# Tomcat的最大连接线程数即超过设定的阈值Tomcat会关闭不再需要的socket线程
maxSpareThreads200
# 所有可用线程耗尽时可放在请求等待队列中的请求数超过该阈值的请求将不予处理返回Connection refused错误
acceptCount200
# 等待超时的阈值单位为毫秒设置为0时表示永不超时
connectionTimeout20000 3、集群类系统各服务节点负载不均衡 原因解析出现这类问题的原因一般是SLB服务设置了会话保持会导致请求只分发到其中一个节点。
调优方案如果确认是如上原因可通过修改SLB服务F5/HA/Nginx的会话保持参数为None然后再次压测验证
4、并发数不断增加TPS上不去CPU使用率较低 原因解析出现该类问题常见的原因有SQL没有创建索引/SQL语句筛选条件不明确、代码中设有同步锁高并发时出现锁等待
调优方案 SQL问题没有索引就创建索引SQL语句筛选条件不明确就优化SQL和业务逻辑
同步锁问题是否去掉同步锁有时候不仅仅是技术问题还涉及到业务逻辑的各种判断是否去掉同步锁建议和开发产品同事沟通确认
5、压测过程中TPS不断下降CPU使用率不断降低 原因解析一般来说出现这种问题的原因是因为线程block导致当然不排除其他可能
调优方案如果是线程阻塞问题修改线程策略然后重新验证即可
除了上述的5种常见性能瓶颈还有其他比如connection reset、服务重启、timeout等当然分析定位后你会发现我们常见的性能瓶颈
导致其的原因大多都是因为参数配置、服务策略、阻塞及各种锁导致的。
下面是我整理的2023年最全的软件测试工程师学习知识架构体系图
一、Python编程入门到精通 二、接口自动化项目实战 三、Web自动化项目实战 四、App自动化项目实战 五、一线大厂简历 六、测试开发DevOps体系 七、常用自动化测试工具 八、JMeter性能测试 九、总结尾部小惊喜
在逆境中汲取力量在困难中锤炼意志努力奋斗方能超越自我。不管前路多坎坷坚持追逐梦想用汗水浇灌希望在青春的岁月里绽放绚丽谱写生命的壮丽乐章。
坚持的力量塑造辉煌奋斗的精神谱写传奇。扬起梦想的风帆冲破人生的浪潮。挫折只是暂时的迷茫努力则是前行的动力。奋斗不止于口号而是用行动书写自己的传世之篇创造无限可能的精彩人生。
勇往直前不畏困难追逐内心的梦想和热爱。用坚持与努力书写人生华章每一次奋斗都是收获的种子。不止步于平凡踏上征程闯出自己的天空让奋斗之光点亮未来的道路。
