性能测试调优实践笔记

一、性能测试的目的：寻找系统最大TPS，判断TPS和对应相应时间是否满足预期。

TPS

TPS：Transactions Per Second，意思是每秒事务数，具体事务的定义，都是人为的，可以一个接口、多个接口、一个业务流程等等。一个事务是指事务内第一个请求发送到接收到最后一个请求的响应的过程，以此来计算使用的时间和完成的事务个数。

以单接口定义为事务为例，每个事务包括了如下3个过程：

　　a.向服务器发请求

　　b.服务器自己的内部处理（包含应用服务器、数据库服务器等）

　　c.服务器返回结果给客户端

　　如果每秒能够完成N次这三个过程，tps就是N；

如果多个接口定义为一个事务，那么，会重复执行abc，完成一次这几个请求，算做一个tps。

QPS

QPS：Queries Per Second，意思是每秒查询率，是一台服务器每秒能够响应的查询次数（数据库中的每秒执行查询sql的次数），显然，这个不够全面，不能描述增删改，所以，不建议用qps来作为系统性能指标。

区别

果是对一个查询接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么tps=qps，否则，tps≠qps

如果是容量场景，假设n个接口都是查询接口，且这个接口内部不会再去请求其它接口，qps=n*tps

jmeter聚合报告中，Throughput是用来衡量请求的吞吐量，也就是tps，tps=样本数/运行时间；我们定义的是tps，不是qps

如果没有定义事务，会把每个请求作为一个事务

QPS是Query Per Second，是数据库中的概念，每秒执行条数（查询），被引申到压测中来了，但是不包括插入、更新、删除操作，所以不建议用qps来描述系统整体的性能；

建议用tps，这个t，你可以随意的定义，可以是一个接口，也可以是一个业务流程等等。

二、性能测试脚本

单系统压测脚本

适用场景：高频业务场景（查询类）、性能高消耗场景（下单、支付类）

作用：寻找性能拐点（方法：TPS不随用户数增加而增加，性能拐点前后5组数据可作为性能测试参考数据），单系统性能调优

链路压测脚本

适用场景：关键业务场景（出现问题后会导致严重后果，如订单后置处理，虚拟商品消耗等）

作用：完成关键业务场景调优

三、环境布置&脚本执行

在linux上部署分布式压测环境。(10条消息) 性能测试搭建Jmeter分布式压测与监控_m0_37449634的博客-CSDN博客https://blog.csdn.net/m0_37449634/article/details/121644438

脚本执行流程:

GUI界面调试脚本->部署linux环境->server（控制机）控制agent（压力机）执行脚本->查看聚合报告、HTOP监控系统资源->SQL调优、业务优化、系统瓶颈（数据库扩容、节点扩容、带宽、内存）

四、性能调优

1. SQL调优：

1.1 获取慢SQL日志

MySQL慢查询日志（Slow Query Log） (biancheng.net)

1.2 使用pt-query-digest分析慢日志

使用 pt-query-digest 分析慢日志

1.3 sql调优

        1)添加索引

        2)避免在索引上进行计算

        3)使用预编译查询

        4)表连接在where条件之前

        5)尽量避免多表联查，多表联查需使用别名

        6）添加临时表，避免重复扫码主表，提高并发性能。

        7）避免查询null值，字段预设默认值。

2.业务优化

2.1 服务拆分，降低耦合度

2.2 使用缓存（预处理、结果缓存）

2.3 使用配置

2.4 部分流程后置处理

3.缓存问题

CDN、redis

缓存击穿问题：

热点key失效，高并发请求打到数据库造成缓存击穿。（解决方法：设置缓存过期时间和缓存刷新方式。验证方法：监控数据库压力。）

CDN缓存失效,造成服务器压力，前端响应速度慢。（解决方法：刷新CDN缓存，优化缓存方案。验证方法，抓包验证JS\CSS文件地址来自于缓存服务器的地址）

缓存穿透：

        使用缓存就是为了减小数据库压力，让大部分的读请求都能落到缓存系统上。而只要请求穿过了缓存层，直接打到了数据库，这个现象理解为缓存穿透。

        缓存失效了，就会出现缓存穿透，然后根据失效缓存数量的多少，划分出缓存击穿和缓存雪崩，比如热点key失效，高并发请求打到数据库，就是缓存击穿现象。比如大量key同时过期，相关的请求全部都被转发到数据库上，就是所谓的缓存雪崩了。还有就是如果一直请求的都是数据库不存在的数据，比如id为-1的商品数据，也会出现缓存击穿，这就算是恶意攻击了。