【软件测试】10_性能测试实战 _性能分析和调优

文章目录

一、性能测试瓶颈分析
二、性能调优
- [2.1 调优原则](#2.1 调优原则)
- [2.2 性能调优的步骤](#2.2 性能调优的步骤)
三、性能调优案例
- [3.1 案例1-获取首页数据（CPU）](#3.1 案例1-获取首页数据（CPU）)
- - [3.1.1 场景描述](#3.1.1 场景描述)
  - [3.1.2 测试结果数据](#3.1.2 测试结果数据)
  - [3.1.3 问题分析](#3.1.3 问题分析)
  - [3.1.4 解决方案](#3.1.4 解决方案)
- [3.2 案例2-查看商品详情（网络）](#3.2 案例2-查看商品详情（网络）)
- - [3.2.1 场景描述](#3.2.1 场景描述)
  - [3.2.2 测试结果数据](#3.2.2 测试结果数据)
  - [3.2.3 问题分析](#3.2.3 问题分析)
  - [3.2.4 解决方案](#3.2.4 解决方案)
- [3.3 案例3-搜索商品（慢查询）](#3.3 案例3-搜索商品（慢查询）)
- - [3.3.1 场景描述](#3.3.1 场景描述)
  - [3.3.2 测试结果数据](#3.3.2 测试结果数据)
  - [3.3.3 问题分析](#3.3.3 问题分析)
  - [3.3.4 解决方案](#3.3.4 解决方案)
- [3.4 案例4-JVM内存溢出](#3.4 案例4-JVM内存溢出)
- - [3.4.1 场景描述](#3.4.1 场景描述)
  - [3.4.2 测试结果数据](#3.4.2 测试结果数据)
  - [3.4.3 问题分析](#3.4.3 问题分析)
  - [3.4.4 解决方案](#3.4.4 解决方案)

一、性能测试瓶颈分析

在实际的性能测试中，会遇到各种各样的问题，比如TPS压不上去，导致这种现象的原因很多，作为测试人员应配合开发人员进行分析尽快找出瓶颈的所在。

常见性能瓶颈分析：

1、服务器资源分析

CPU瓶颈分析
- CPU已压满（接近100%），需要再看其他指标的拐点出现的时刻是否与CPU压满的时刻基本一致
内存瓶颈分析
- 内存不足时，操作系统会使用虚拟内存，从虚拟内存读取数据，影响处理速度
磁盘I/O瓶颈分析
- 磁盘I/O成为瓶颈时，会出现磁盘I/O繁忙，导致交易执行时在I/O处等待
网络带宽
- 如果接口传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，导致TPS上不去

2、JVM瓶颈分析

内存泄漏：内存不释放
内存溢出：内存不够用

3、数据库瓶颈分析

慢查询
数据库的连接池设置太小，导致数据库连接出现排队
数据库出现死锁

4、程序内部实现机制

5、压测机

JMeter单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会导致TPS压不上去

二、性能调优

2.1 调优原则

按照由难到易的顺序：

1.硬件资源（CPU、内存、磁盘）

2.网络资源

3.中间件（应用服务器）、数据库配置

4.源代码、数据库脚本

5.系统架构设计

2.2 性能调优的步骤

确定问题：根据性能监控的数据和性能分析的结果，确定性能存在的问题（要求）
确定原因：确定问题后，对问题进行分析，找出问题的原因
确定调整目标和解决方案（改服务器参数配置、增加硬件资源配置、修改代码）
测试给出的解决方案
分析调优的结果

yacas 复制代码

注意：性能测试调优并不是一次完成的过程，针对同一个性能问题，上面的五步可能要经过多次循环才能最终完成性能调优的目标（即：测试发现问题-找原因-调整-验证-分析-再测试。 。 。 ）

三、性能调优案例

3.1 案例1-获取首页数据（CPU）

3.1.1 场景描述

进入首页后，加载首页的相关数据，包括：轮播图、频道、优惠券、团购专区、品牌商直供、新品首发、热卖商品、专题精选等数据。

3.1.2 测试结果数据

3.1.3 问题分析

1）从目前的测试结果来看：性能存在问题

并发数达到50时，TPS达到52，此时虽然响应时间为4.4s（小于5s），但是数据库服务器的CPU使用率非常高（接近100%），重点关注数据库。

2）CPU分为用户CPU和系统CPU

综合其他的各项资源指标来分析，内存、磁盘IO、网络等指标无任何异常，因此此处不是系统CPU占用高
主要原因是用户进程占用的CPU高
目前CPU占用高的为数据库服务器，而数据库服务器主要的任务就是执行SQL语句

3）数据库服务器CPU高，可能的原因：SQL执行时间太长，SQL语句过多

确定SQL执行时间是否过长
- 查看慢查询日志，看看是否有超过预期指标的SQL语句，并分析排查
- 目前案例经过慢查询日志的分析，没有超长时间执行的SQL语句
确定是否SQL语句过多
- 查看当前数据库中正在执行的SQL语句及连接池的状态，发现大量SQL在等待执行

4）再结合操作过程中的系统日志进行分析（执行进入首页脚本，抓取日志），通过日志分析，每进入一次商城首页，就需要在数据库中执行19条查询的SQL语句

3.1.4 解决方案

1、CPU高------增加CPU，提高服务器配置

2、根本上解决问题的方法

分析这19条SQL都是在查询什么数据，包括：轮播图、频道、优惠券、团购专区、品牌商直供、新品首发、热卖商品、专题精选等数据。
考虑使用分批次、异步加载的方式（展示到什么位置，就查询什么位置的数据）

3.2 案例2-查看商品详情（网络）

3.2.1 场景描述

进入商品详情页面时，加载商品的详细信息。

3.2.2 测试结果数据

3.2.3 问题分析

从监控图表可以看出，当前的网络流量已经基本将网络带宽占满，因此网络存在瓶颈。

网络带宽已跑满
一次请求中返回了全部数据

3.2.4 解决方案

提升服务器网络带宽（宽带便宜）
分批次、异步加载商品数据（分析进入商品详情时的数据传送内容，内容是否有可用精简的内容；或者是否可以异步传送）

3.3 案例3-搜索商品（慢查询）

3.3.1 场景描述

进入首页，在搜索框中输入关键字搜索商品

3.3.2 测试结果数据

搜索关键字"床"时，出现慢查询SQL语句
通过日志查看慢查询语句 cat /var/lib/mysql/localhost-slow.log

sql 复制代码

select id, `name`, keywords, `desc`, pid, icon_url, pic_url, `level`, sort_order, add_time, update_time, deleted from litemall_category WHERE ( id in (1008009, 1008009, 1008008, 1008008, 1015000, 1015000, 1008009, 1008009, 1008009, 1008008, 1036000) and `level` = 'L2' and deleted = 0);

3.3.3 问题分析

1、性能测试结束后，通过慢查询日志查看到执行时间超长的SQL语句

bash 复制代码

[root@localhost ~]# tail -f /var/lib/mysql/localhost-slow.log     # 实时查看日志文件信息
[root@localhost ~]# cat /var/lib/mysql/localhost-slow.log         # 查看日志文件信息

2、结合业务来分析，确定每个SQL的作用（尤其关注与慢查询的SQL语句相关的那几条SQL）

sql 复制代码

-- 1.统计所有名称或关键词包含 "床" 字的在售商品总数，用于展示 "找到 11 个相关商品" 
SELECT count(0) FROM litemall_goods WHERE (keywords LIKE '%床%' AND is_on_sale = 1 AND deleted = 0) OR (`name` LIKE '%床%' AND is_on_sale = 1 AND deleted = 0);

-- 2.分页获取满足条件的商品列表
select id,`name`,brief, pic_url, is_hot,is_new,counter_price,retail_price from litemall_goods WHERE (keywords like '%床%' and is_on_sale = 1 and deleted = 0) or(`name` like '%床%' and is_on_sale = 1 and deleted = 0) order by add_time desc LIMIT 10;

-- 3.查询满足条件的商品分类id
select category_id from litemall_goods WHERE (keywords like '%床%' and is_on_sale = 1 and deleted = 0) or( `name` like '%床%' and is_on_sale = 1 and deleted = 0);

-- 4.根据商品分类id获取商品分类信息
select id, `name`, keywords, `desc`, pid, icon_url, pic_url, `level`, sort_order, add_time, update_time, deleted from litemall_category WHERE (id in (1008009, 1008009, 1008008, 1008008, 1015000, 1015000, 1008009, 1008009, 1008009, 1008008, 1036000) and `level` = 'L2' and deleted = 0);

3、定位问题，分析慢查询SQL本身是否有优化空间。

当搜索关键字匹配到大量的商品时，第3条SQL语句会返回大量重复数据
第4条SQL语句中的in查询条件中同样包含大量重复的商品分类id
第3条和第4条SQL都会出现查询时间较长

3.3.4 解决方案

优化第3条SQL语句，因该SQL语句的查询结果大部分都是重复的，可以进行去重处理。

第4条SQL（慢查询SQL）自身无优化空间
但是在查询时条件中的ID有大量重复，而ID又是第3条SQL返回的结果
因此可以优化第3条SQL语句，进行去重处理

sql 复制代码

select DISTINCT category_id from litemall_goods WHERE (keywords like '%床%' and is_on_sale = 1 and deleted = 0) or (`name` like '%床%' and is_on_sale = 1 and deleted = 0);

3.4 案例4-JVM内存溢出

3.4.1 场景描述

请求测试接口（/wx/index/oom），模拟内存溢出

3.4.2 测试结果数据

3.4.3 问题分析

JVM内存占用随着时间的推移占用越来越多，直至内存溢出，系统退出

3.4.4 解决方案

排查代码存在的问题，及时释放无用的对象