性能测试的分析和调优

性能测试的分析和调优
步骤：确定问题（测试） —— 分析问题原因（开发） —— 给出解决方案（开发） —— 验证问题（测试） —— 分析结果（测试/开发）

从资源方面来看：

CPU：用户CPU、系统CPU

查看CPU使用率的命令：top

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

内存：实际内存、虚拟内存

查看内存使用的命令 ：vmstat 3 10

磁盘：input和output速率

 查看磁盘IOs使用的命令 ：iostat -x 1 1

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

网络：传输速率

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

查看网络使用的 命令: sar -n DEV 1 2

从应用服务器（JVM）配置来看的话：

JAVA 应用瓶 颈分析 —— JVM

常见的内存问题：
Ø 内存泄露 memory leak，是指程序在申请内存后，无法完全释放已申请的内存空间。
Ø 一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。
Ø 内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of
memory
Ø memory leak会最终会导致out of memory！

可以使用JVM 监 控 —— 使用本地 jvisualvm 远程监控服务器 ：

第一步：在cmd里面输入java监控运行程序

java -server -Dfile.encoding=UTF-8 -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=192.168.176.134 -Dcom.sun.management.jmxremote.port=888 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -jar /home/itheima/litemall/litemall-all-0.1.0-exec.jar

第二步：进入本地jdk安装目录bin目录，找到jvisualvm.exe并启动

第三步：右键“远程”选择“添加远程主机”，并输入主机IP

第四步：右键主机选择“添加JMX连接”，并输入JMX端口

第五步：连接成功后在主机下会有对应的连接显示，双击查看监控信息 

从数据库服务器配置来看：

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

慢查询定义：指执行速度低于设置的阀值的SQL语句
作用：帮助定位查询速度较慢的SQL语句，方便更好的优化数据库系统的性能

mysql> show variables like "slow_query%"

使用这个可以查看慢查询的日志开启状态以及存放位置

mysql> show variables like "long_query_time"

慢查询的时长设置

慢查询 开启 并配置：
Ø mysql> set global slow_query_log='ON'; #开启慢查询日志
Ø mysql> set global slow_query_log_file='/data/slow_query.log'; #设置慢查询日志存放位置
Ø mysql> set global long_query_time=1; # 设置慢查询时间标准，设置之后需要重启才能发现数据变化

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

试关注点：
Ø MYSQL官网给出了一个设置最大连接数的建议比例：Max_used_connections / max_connections * 100% ≈ 85%，需要关注
MYSQL的最大连接数 和 系统运行时数据库已建立连接数的比例
Ø 如果已使用连接数与最大连接数比例超过85%，需要增加最大连接数设置，否则会造成连接失败
Ø 如果已使用连接数与最大连接数比例小于10%，那显然设置的过大，会造成系统资源的浪费

查看 MYSQL 最大连接数

mysql> show variables like "%max_connections%"

查询当前数据库已建立连接数：

mysql>show status like "Threads_connected"

死锁：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象。

测试关注点（初步确定死锁）：
Ø show open tables where in_use>=1 查询当前是否锁表
• 如果表锁了，这个sql可以查询出来
• 但是这个sql查出来的表，不一定是被锁住的。因为用查询，如果耗费时间很长，也会查询出来
Ø show processlist：查看执行时间最长的线程，找到对应sql，找到表

从程序来看(就是程序员写的代码)

从测试机资源来看：

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

 压 测机影响性能测试结果的原因主要是 ：
Ø JMeter单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会导致TPS压不上去
压测机资源的监控方法：
Ø Windows测试机：自带“任务管理器”
Ø Linux测试机：PerfMon组件

增加线程数，但是QPS不增加，或者增加线程数，QPS不是等比例增加，此时就证明压测机出现瓶颈。

1、带宽影响：所有接口每秒响应数据，或者请求数据，超过了带宽可以传输的最大值。比如当前网速的下载速度是5M/s，而接口总的响应数据是6M/s，则有5M可以在一秒内响应成功，另外1M的接口只能等到下一秒

2、cpu性能影响：当总的响应数据或请求数据未超出带宽速率时，则有可能是压测机的CPU占用率太高，即CPU的性能已经不足以支撑更高的并发率导致QPS上不去。压测时可以同时查看CPU的占用率，如果一直持续在100%则说明已经达到了CPU的性能极限。

3、运行内存：压测机的运存太小，压测时无法存入更多的对象、变量、数据等，导致内存溢出，只能等待内存释放，才能继续存入。

4、磁盘容量：磁盘剩余空间不足，导致接口不能继续写入数据。

5、磁盘读写速度：压测的接口需要读取或者写入数据到本地文件