性能测试分析和调优

性能测试分析和调优：

性能调优的步骤

1. 确定问题：根据性能监控的数据和性能分析的结果，确定性能存在的问题（要求）

2. 确定原因：确定了问题之后，对问题进行分析，找出问题产生的原因

3. 给出解决方案：确定调整目标和解决方案（改服务器参数配置/增加硬件资源配置/修改代码）

4. 验证问题：按照给出的解决方案，重新进行测试

5. 分析调优结果：分析出问题的性能指标是否有提升，关注其他指标未下降

注意：

​ 性能测试调优并不是一次完成的过程，针对同一个性能问题，上面的五步可能要经过多次循环才能最终完成性能调优的目标

性能瓶颈分析

性能问题可以产⽣的 原因：
· 服务器的资源 —— 影响应⽤服务器和数据库服务器处理的速率 和 ⽹络传输速率
· JVM瓶颈分析 —— JAVA程序运⾏的环境
· 数据库瓶颈分析 —— 数据库程序运⾏环境分析
· 程序内部实现机制 —— 开发⼈员编写的代码分析
· 压测机 —— 影响性能结果

服务器资源分析 —— CPU瓶颈

CPU使用率：表示一段时间内，正在使用的CPU时间段 / 总的CPU时间段 * 100%
CPU使用率分为用户态、系统态和空闲态
· 用户态：表示 CPU 处于应用程序执行的时间
· 系统态：表示系统内核执行的时间
· 空闲态：表示空闲系统进程执行的时间

查看CPU使用率的命令：top
测试关注点：
· 当CPU使用率高时，确定是用户CPU高，还是系统CPU高
· 如果是用户CPU高，说明某个软件程序的CPU资源占用率高，需要定位代码程序运行的效率
· 如果是系统CPU高，同步观察是否是其他资源（磁盘IO、内存、网络等）不足

服务器资源分析 —— 内存瓶颈

` 内存：实际内存/物理内存，机器实际的内存空间，所有的程序运⾏都必须加载到内存中才能运⾏
· 虚拟内存：⼀种虚拟化的技术。当内存空间不⾜时，从磁盘中读⼊数据，处理完成后写回磁盘，以此进 ⾏交换，保证在内存不⾜时，程序也能够运⾏。

注意：
由于虚拟内存，实际上完成了数据在磁盘和内存之间的读写过程，磁盘的速度要远慢于内存时，因 此当使⽤虚拟内存时，说明内存已经不⾜，可能存在问题

命令：
· 查看总量：top
· 查看虚拟内存的使⽤量：vmstat

测试关注点：
· 实际内存：查看内存使⽤百分⽐，检查是否超过80%
· 虚拟内存：查看swap的si和so是否为0，如果不为0，说明内存可能不⾜

服务器资源分析 —— 磁盘IO瓶颈

磁盘IO瓶颈：影响性能的是磁盘的读写速度（Input和Output速率），不是磁盘大小。

命令：iostat -x 1 1

测试关注点：
· %util⾼，说明磁盘⻓时间占⽤CPU在发送数据，说明磁盘传输速度不⾜，存在瓶颈 · %iowait⾼，说明磁盘IO传输数据的任务很多，在等待，说明磁盘传输速度不⾜，存在瓶颈

服务器资源分析 —— 网络瓶颈

网络瓶颈：影响性能的是网络的传输速度，与网络的总带宽进行对比，接近总带宽，说明网络存在瓶颈。

命令：sar -n DEV 1 2

测试关注点：
· 将每秒接收的数据量rxkB/s，与网络最大带 宽进行对比，如果实际传输速率接近网络最 大带宽，说明网络IO有瓶颈

数据库瓶颈分析 —— 慢查询

慢查询：
概念：找出查询速度慢的sql语句，
· 慢：查询时间超过设置的阈值
慢查询的相关参数：
· slow_query_long：慢查询开关
· slow_query_log_file：慢查询日志存放位置
· long_query_time： 慢查询时间阈值
查询慢查询的相关参数：show variables like “”
设置慢查询的相关参数：set global 参数名 = 值
设置完成，并运行脚本抓取到慢查询的日志信息为：

测试关注点：
· 基于当前记录下来的慢查询sql进行进一步的分析，判断是否存在问题，需要修改

数据库瓶颈分析 —— 数据库连接池

数据库连接池：事先建立好连接，当程序请求sql执行时，直接分配空闲连接，使用完成后释放连接。节省了SQL语句执行前后连接的建立和关闭的时间。
工作原理：

查看方法：
· 最大连接数：show variables like “max_connections”
· 当前使用的连接数：show status like “threads_connected”
测试点关注点：
· 关注：利用率 = 当前使用的连接数/最大连接数 ，建议：85%左右
· 如果利用率超过85%，连接池可能会被占满
· 如果利用率过低，说明资源存在浪费，可能会影响其他性能指标

数据库瓶颈分析 —— 数据库死锁

锁的介绍：
· 一个用户修改数据时，对该数据进行加锁操作，其他用户不能进行修改
· 只有当第一个用户修改完成后，其他用户才能修改
数据库中锁：
` 行锁：效率高，但是安全性低（会出现死锁）
· 表锁：效率低，但是安全性高（不会出现死锁）
死锁：
· 两个进程同时使用资源时，出现的相互争抢的现象
· 死锁后需要等待很长的时间，要么有程序校验机制来释放，要么手动释放

数据库中锁的介绍：

测试关注点：
· show open tables where in_use>=1： 查看当前正在使用的表（可能是锁定的表）
· show pricesslist ：查看执行时间长的线程，找到对应的sql
· kill pid：如果锁死，先手动杀死死锁的连接

JAVA应用瓶颈分析 —— JVM内存

JVM内存：Java 虚拟机在执行 Java 程序的过程中所管理的不同的内存数据区域。可简单分为：堆内存和非堆内存
· 堆内存：主要存放用new关键字创建的对象，所有对象实例以及数组都在堆上分配。 —— 给开发人员使用的
· 非堆内存：保存虚拟机自己的静态数据，存放加载的Class类级别静态对象如类、方法等。 —— 给JVM自己使用的

JAVA应用瓶颈分析 —— JVM内存监控

1、在JAVA程序启动时，添加启动参数

-Dcom.sun.management.jmxremote
-Djava.rmi.server.hostname=182.92.81.159
-Dcom.sun.management.jmxremote.port=10086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

2、进入JDK的bin目录下，选择“Jvisualvm.exe”
3、点击远程，右键选择“添加远程主机”，并设置服务器IP
4、点击主机IP，右键点击“添加JMX连接”，并设置JVM监控的端口

5、点击 IP + port，右边选择“监视”，可以查看JVM内存的实际使用情况

压测机瓶颈分析 —— 压测机

原因：JMeter单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会导致TPS压不 上去
监控的方法：
· windows压测机 —— 任务管理器
· linux压测机 —— PerFMon 或者 top命令

解决方法：
· 添加资源
· 添加多台压测机，进行分布式测试

性能调优案例：

案例1：

分析过程：
· 进入首页后，加载首页的相关数据，包括：轮播图、频道、优惠券、团购专区、品牌商直供、新品 首发、热卖商品、专题精选 等数据
· 每发送一个HTTP请求，需要查询27个SQL语句。当TPS为100时，每秒要处理2700个SQL语句
解决方案：
· 增加CPU
· 通过分批次、异步加载的方式，第一次进入首页时只加载第一屏的内容，下拉时再加载后续的数据

案例2（网络）：
问题分析：

原因：
· 已使用的网络带宽已经接近于总带宽
解决方案：
· 增加网络带宽
· 减少进入商品详情页面时的数据请求量

案例3（慢查询）：
案例：
当搜索商品时，慢查询日志中记录了一个查询SQL比较慢，该SQL为获取商品类别信息的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条SQL语句会返回大量重复数据 第4条SQL语句中的in查询条件中同样包含大量重复的商品分类id
因此：第4条SQL会出现查询时间较长,是由于第3条SQL返回的ID有大量重复

案例4（JVM内存泄漏）：
问题分析：
测试接口：/wx/index/oom
执行时会出现内存泄漏：
现象：

解决方案：
· 开发定位出泄漏的点，修改代码