多测师-多培养一些优秀的测试工程师
网站地图 |   收藏本站   |   

13825291265

性能测试之评估方案

发布日期:2021-12-29 10:08:45 作者:多测师 浏览次数:

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

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

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

  做性能压测的时候,把并发线程数按照阶梯式不断累加上去,观察cpu是否有达到80%以上,如果有,即已经达到系统瓶颈,此时也不用再压下去,压下去只会把系统打爆掉,应该去查看此时的TPS是否满足预期,如果满足预期设定的值,则可以不用考虑隐患(前提是预期值要设置的合理),如果不满足预期的TPS,就需要根据具体性能瓶颈,提出优化改进建议。而优化改进建议就通过观察是哪个地方的瓶颈最明显,最值得修改,就对该地方作出优化。比如RDS、连接池、Redis、代码逻辑、系统配置、JVM服务等等。

性能测试之评估方案

  粗略几个影响点:

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

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

  ·慢sql--影响RDS性能

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

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

  如何分析瓶颈所在?

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

  根据时间区间,在pinpoint上面看接口请求分布,拉到具体的接口分布列表,查看当前测试接口的详情,查看调用链路是有哪些。根据调用链路,可以看到有做了数据库的连接(涉及到连接池),有查询redis,或者还有系统算法的内容。

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

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

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

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

如需了解更多测试技术信息请关注:https://www.duoceshi.cn/jswz/深圳多测师软件与技术服务有限公司


查看更多 >>

推荐阅读