【性能测试】常见的性能问题分析思路（一）道与术

微信搜索【大奇测试开】，关注这个坚持分享测试开发干货的家伙。

本次是一篇关于性能测试的，从行业的背景来看，测试开发（包括但不限于平台工具开发、自动化..）和性能测试一直是持续关注最高的，这里暂不讨论新新方向比如音视频、大数据、AI等，毕竟笔者也没过多经验，很多人可能跟我经历很类似，因为不是专门做性能测试，大部分都是利用一些开源工具进行业务是否满足需求上的测试，很少能做或者没经历进步一步的性能分析，以下是组内性测试小组，专注性能测试比较资深伙伴，我们称呼为 “禧子哥” 的一次分享内容，对比好多文章和一些外部分享，个人觉得真的是干货，因此特别争得同意，大奇再此基础上进行部分整理和优化，呈现给大家，最后再次感谢原作者 “禧子” 的干货总结和无私分享。

 

压测目标

性能测试一定是要有它的目的或目标，一切拍脑袋不知道想要干啥的性能测试需要真的是只能用呵呵来形容，分享者基于目前给出，压测有三大目标：

1.  找出性能的瓶颈
2. 给出基准指标
3. 机器配置容量规划

性能缺陷类型

对于性能问题产生的类型，大体总结为五类，通过一个思维导图展示

性能分析方式方法

任何性能问题出现首先都会有对应现象发生，现象分为前台现象和后台现象，这里我们讲的是前台现象，也就是用户或测试者感受到的表象，如TPS曲线波动，响应时间持续上涨等。有些性能问题，前台表现很正常，用户可以正常使用，但是后台可能发现一些异常现象，例如cpu比较高，可用内存比较少等，这种情况下，不要轻易做任何性能调整，否则可能引发其它性能问题，只要前台使用正常满足业务容量目标即可。
现象可以大致分为3大类

1. 单个功能点慢

java进程还在，系统首页、登录均正常，只是访问到特定功能点，特定接口时比较慢，且现象每次操作都可以重现。

2. 系统慢

java进程还在，系统打开首页、登录操作很慢，或者一直停在那里。即使登录到系统中后，点所有菜单、功能都很慢，整个系统基本无法使用。相当于我们的整条单链路或全链路都受影响

 

3.宕机

java进程自动中止，进程消失。

这3种现象不是孤立存在的，关系如下：

1. 单个功能点慢，一旦积累到一定程度，应用服务器很多线程都在处理此功能时，会导致系统变慢，甚至可能导致宕机。

2. 系统变慢，基本上都是由于用户用操作了某个功能，此功能存在死循环或者资源不释放之类的代码问题，例如发生内存溢出，导致系统变慢。在系统慢的情况下，找出有问题的单个功能点是关键。

3. 宕机，通常也是由于某个功能点的性能问题导致。

4. 只要知道哪个功能点或操作慢，就可以进行优化。多数情况下，我们不知道是什么操作导致的性能问题，分析诊断的主要目的就是找出这些功能和操作。

 

单点慢如何处理    

如果我们已经知道某个功能点慢，并且可以重现，那么问题就比较容易解决了，检查代码、优化sql语句等。多数情况下，单个功能点慢的问题是sql语句执行的慢，抓出执行效率低的sql语句，可以进一步定位问题。对于oracle数据库，可以通过“Plsqldev-工具-会话” 这个工具进行抓取,或者生成AWR报告，对于mysql数据库可以借助explain等解析语句分析。
执行效率低的sql语句查看执行计划，是否走全表扫描，索引创建是否合理，检查基础数据分布是否合理等。

若是B/S的，可以通过httpwatch，fiddler查看哪个点比较慢。

宕机如何处理

根据宕机的解释，多数情况下我们遇到的性能问题并不属于“宕机”，只是我们习惯这么叫而已。一旦出现宕机，唯一可以做的只能是查看宕机日志。根据目前项目经验，所有宕机问题都是由于内存溢出导致（内存溢出并不一定引起宕机），所以如果出现宕机，应该首先检查jvm内存参数是否设置、设置的是否正确，如果确认jvm内存参数没有问题，需要进一步分析宕机日志文件，如heapdump/coredump文件，javacore文件等。

 

系统慢如何处理

绝大多数的性能问题都是“系统慢”的问题。系统慢，可能慢在应用服务器端、数据库端、网络端、客户端(客户端慢通常比较容易定位)，可以先从以下四个方法进行分析诊断，定位大的方向：

1. 观察服务器资源利用率

主要观察应用服务器、数据库服务器的cpu、内存使用情况，如果应用服务器cpu利用率较高，例如在50%以上，则说明应用服务器正在处理请求，有压力。如果数据库服务器cpu利用率较高，例如在50%以上，则说明数据库服务器正在处理请求，有压力，可能有较耗时的sql语句在执行。资源分析属于辅助分析，需要结合其它方法一起使用。

2. 查看日志

查看日志非常重要，日志里会提供非常有用的线索，需要养成查看日志的习惯。查看日志定位问题需要一定的经验和积累，以下是查看日志的几条经验和建议（查找日志中是否有如下关键字信息）：

• Outofmemory：有内存溢出，通常会生成heapdump文件，需要结合javacore进一步分析，可以借助相关工具。

• can not open connection：应用服务器的数据库连接池用光，检查连接参数是否设置正确，如果参数配置没有问题，需要结合javacore进一步分析

• Stack overflow：结合javacore进一步分析

• Dead lock：日志中会明确指明哪段代码发生了死锁 

3.关注时间戳分析日志时关注时间戳信息，尤其关注系统变慢前后时间点的日志。关注反复出现的日志信息，关注同一时间点大量出现的日志信息出现了很多很多错误信息，对这些信息尤其需要重点关注。
4.其它显而易见的错误如网络连接错误等，可以检查当前正在处理什么请求，可以查看jvm内存的使用情况，检查线程、数据库连接、控制台检查只是辅助，需要结合其它措施，如利用全链路系统一起分析。比如：生成java线程快照，常用命令

• kill -3 进程号或者jstack 进程号

• Jstack –l  进程号

• jstat –gcutil 进程号 关注内存堆使用情况

最后总结下系统慢的三个大方向

1. 应用服务器端问题，首先检查jvm参数、连接参数是否设置正确，参数没有问题那就是代码问题，根据日志、javacore、heapdump的分析结果，检查、修改代码。

2. 数据库端问题，通常都是由于低效的sql语句导致，优化sql语句即可，也可能是数据库连接池。

3. 其它调用过程问题，例如网络连接问题（日志中会有错误信息），检查网络联通稳定性等。

通用性能分析思路

基于上面的性能分析方法内容，总结下性能分析的通用方法，同样给出一个自上而下的思维图，从现象出发，分析初步范围，根据脉路进一步缩小范围，进行不断的验证测试等，从而定位问题，解决问题。

 

 

本篇就分享这些，下一篇将基于此文分享下实际案例和一种工具使用技巧。

坚持原创，坚持实践，坚持干货，如果你觉得有用，请点击推荐，也欢迎关注我博客园和微信公众号。

 

标签：宕机,性能,与术,问题,内存,测试,日志
来源： https://www.cnblogs.com/mrzcode/p/15422770.html