性能测试评估方案,还是需要了解一下-IT知识库

性能测试评估方案,还是需要了解一下-IT知识库

咨询热线

0731-82115773

精选文章 > IT知识库 > 性能测试评估方案,还是需要了解一下

性能测试评估方案,还是需要了解一下

时间:2021-12-16  发布:新梦想IT职业教育  来源:新梦想培训

当我们开始做性能测试的时候,一定要得出结论,并且能给出优化方案和具体实施才可以,否则都是空谈。


今天介绍几个具体的案例,可以给刚入门做性能测试的同学一点启发。


如何判断已经达到系统瓶颈?

做性能压测的时候,把并发线程数按照阶梯式不断累加上去,观察cpu是否有达到80%以上。


如果有,即已经达到系统瓶颈,此时也不用再压下去,压下去只会把系统打爆掉,应该去查看此时的TPS是否满足预期,如果满足预期设定的值,则可以不用考虑隐患(前提是预期值要设置的合理),如果不满足预期的TPS,就需要根据具体性能瓶颈,提出优化改进建议。


而优化改进建议就通过观察是哪个地方的瓶颈最明显,最值得修改,就对该地方作出优化,比如RDS、连接池、Redis、代码逻辑、系统配置、JVM服务等等。


粗略几个影响点:

系统内存容量太小--影响系统性能

算法过于繁琐--影响系统性能

慢sql--影响RDS性能

数据库连接过多,超出容量--影响系统的连接池性能

redis请求过多--影响Redis性能


如何分析瓶颈所在?

首先遇到TPS低于20,RT大于2000ms的压测结果,那么肯定不是一个正常的结果,此时要观察各个服务的指标情况。


根据时间区间,在pinpoint上面看接口请求分布,拉到具体的接口分布列表,查看当前测试接口的详情,查看调用链路是有哪些。


根据调用链路,可以看到有做了数据库的连接(涉及到连接池),有查询redis,或者还有系统算法的内容。


根据每个环节的耗时,有没有耗时特别长的,比如大于100ms的那种,比如连接数据库时间特别长,那么就可能是在连接池连接的时候较慢,原因是并发数太多,容量不够,排队等待的时间太久了。


给出建议:需要增加连接池的容量。


也可以查看系统cpu的情况,根据cpu占比中的系统或者JVM的占比是否异常高,如果是系统的占比异常高,则可能是代码中算法复杂,比如if循环较多。


除了cpu,还有可能是其他指数会有异常飙高。


看得多不如操作一把来的快,最好的方式就是自己写一个程序自己做性能测试,然后通过优化代码和慢sql等等,观察性能是不是好起来了,实践出真知。


End

大咖面授 免费试听

性能测试评估方案,还是需要了解一下-IT知识库
技术支持 英铭科技