想做性能测试?总得出个评估方案吧!

发表于:2021-11-25 09:38  作者:无敌大白   来源:掘金

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 性能测试 软件测试技术

  当我们开始做性能测试的时候,一定要得出结论,并且能给出优化方案和具体实施才可以,否则都是空谈。
  今天介绍几个具体的案例,可以给刚入门做性能测试的同学一点启发。

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

  如何分析瓶颈所在?
  首先遇到TPS低于20,RT大于2000ms的压测结果,那么肯定不是一个正常的结果,此时要观察各个服务的指标情况。
  根据时间区间,在pinpoint上面看接口请求分布,拉到具体的接口分布列表,查看当前测试接口的详情,查看调用链路是有哪些。根据调用链路,可以看到有做了数据库的连接(涉及到连接池),有查询redis,或者还有系统算法的内容。
  根据每个环节的耗时,有没有耗时特别长的,比如大于100ms的那种,比如连接数据库时间特别长,那么就可能是在连接池连接的时候较慢,原因是并发数太多,容量不够,排队等待的时间太久了。给出建议:需要增加连接池的容量。
  也可以查看系统cpu的情况,根据cpu占比中的系统或者JVM的占比是否异常高,如果是系统的占比异常高,则可能是代码中算法复杂,比如if循环较多。
  除了cpu,还有可能是其他指数会有异常飙高。
  看得多不如操作一把来的快,最好的方式就是自己写一个程序自己做性能测试,然后通过优化代码和慢sql等等,观察性能是不是好起来了,实践出真知。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理

评 论

论坛新帖



建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海信义律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2021, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道