在这里要强调一下,性能测试不是用Jemter和Loadrunner等工具,模拟几个用户跑个场景,再导出个测试报告,然后出去跟人家说我会压力测试。这是丢人的,人家都笑话你。 完整的压测流程:业务场景->性能指标->测试策略->性能脚本->分析系统->问题定位->性能报告。话题跑偏了,言归正传,今天的话题是【压力测试瓶颈分析】,服务端出现性能瓶颈,分析思路如何展开。一、压测目的
观察系统的负载能力,测试系统在高负载的情况下的稳定性,评估系统当前的性能情况,解决性能的瓶颈。
二、服务端常见问题
CPU性能瓶颈有两种情况:
CPU高、TPS低和CPU低、TPS也低
有同学问:“不是还有CPU低,TPS高的情况吗”,这个情况不就是CPU没有压力,性能达标呗。
分析过程:
先定位进程->查看哪个进程使用率较高,找到被测服务的进程号->分析进程中,资源使用率高的线程->导出对应的线程日志,进程定位具体的原因。
思路图
内存性能瓶颈表现为两种:
内存泄露和内存溢出
引起内存泄露和溢出的原因如下:
分析内存的过程:
查看内存资源->判断Gc的回收是否异常->导出内存日志->分析具体的泄露对象。
常见的分析工具:MAT、profile、ha456.jar
思路图
注意
大多数的中小型公司,对于性能的要求偏低,甚至不要求性能。这类公司大多业务形态散,迭代较快、市场占有率低。即使遇到性能问题,不愿意花费时间和人力成本,进行性能调优。一般通过加服务解决问题,对应了那句“通过钱能解决的事都不是事”。建议大家挑选性能相关工作,一定要找大厂,一定要找大厂,一定要找大厂。大厂让你施展才华的机会才会更多。
总结
1、性能调优和性能定位的原则,每次只改一处。改完后进行回归,如没有解决问题,回滚到修改前,再次寻找可能出现的问题点进行优化再回归
2、性能问题跟很多的因素有关,问题可能出现在任何节点,可能是程序,可能是中间件,也可能是配置的原因。所以在定位问题的时候,一定要熟悉数据的流转,这样你在排查问题的时候,脑子才能保持清醒。
标签:分析,瓶颈,性能,内存,测试,压力,CPU From: https://www.cnblogs.com/zgq123456/p/18063375