day：41 总结（六）性能测试

1. 性能测试的测试流程
1）分析性能的需求--》需求从哪里来的？--》① 业务和产品提出的 ② 测试提出的 ③ 客户提出的
2）执行性能测试的方案和计划，搭建性能测试环境
3）编写对应的性能测试用例 ==》设计对应的性能测试场景
4）在jmeter里面组件接口和开发性能测试脚本
5）执行性能测试
6）分析性能瓶颈，给出性能调优建议，得出性能测试报告

2. 性能测试当中的并发测试，负载测试，压力测试，失效恢复测试
1）性能测试常见的类型：
并发测试，负载测试，压力测试，失效恢复测试
并发测试--》所有的用户在同一时间请求同一个接口（瞬间的）--》秒杀、抢红包
负载测试--》通过不断的增加用户和增加请求对服务器施加压力，找到瓶颈点和拐点--》比如，用100并发线程数持续加压5-10分钟
压力测试--》又称为稳定性测试、破坏性测试--》找到瓶颈点和拐点后，通过80-100%的TPS去持续进行施压30分钟，1个小时，2个小时，12个小时，24个小时等等，看看系统是否有内存泄露和内存溢出等问题
失效恢复测试==》主要是检查系统在出现故障之后，能否自动恢复到正常状态，以及恢复的过程是否正确，数据是否完整等

3. 并发测试里面用户的概念
1）注册用户数 ==》50000个人注册
2）在线用户数 ==》5% ==》2500个人在线
3）并发用户数 ==》并发度1-5%*2500 ==》25=125个并发
【面试题】你在做并发测试的时候，怎么得到最佳或最优的并发用户数（并发线程数）
答：我会通过阶梯式加压的方式去进行测试，比如20-40-60-80-100-120-140-160，当接口响应时间不超过3秒，接近3秒，并且TPS最优，接口无报错，此时对应的并发线程数就是最优的并发用户数
TPS的计算公式：TPS=并发用户数/接口响应时间
注意：并发用户数并不是越高越好，并发用户数越高，带来响应时间也会增加，以及错误率也会提升

4. 性能测试的指标
1）性能测试的目的：
不断的增加用户和请求对服务器施加压力，看服务器的性能表现
2）性能测试的指标
① TPS（transaction per second） --》每秒处理的事务数--》瞬间 --》可以使用jp@gc - Transactions per Second插件来监听
② 吞吐量（throughput）--》网络上行下载的数据量总和 --》是平均的TPS --》可以在聚合报告里面查看
③ QPS（query per second） --》每秒SQL语句的查询数
④ RPS（request per second）--》每秒的请求数
⑤ HPS （hists per second）--》每秒点击率
⑥ RT （response time）--》接口的响应时间
a、从客户端发送接口请求到服务器的时间 T1
b、服务器处理请求的时间 T2
c、服务器把处理好的请求返回给到客户端的时间 T3
d、客户端把接口响应数据渲染到前端页面的时间 T4
在jmeter里面的接口响应时间=T1+T2+T3
⑦ 事务
a、打开cms输入用户名和密码--点击登录 ==》这是一个事务 ==》1TPS=1QPS
b、打开cms输入用户名和密码--点击登录--添加用户--修改用户--删除用户 ==》也是一个事务 ==》1TPS=4QPS
结论：处理单接口事务的时候TPS和QPS是相等的，处理多接口事务的时候TPS和QPS是不相等的
⑧ 错误率 ==》事务的错误率 ==》不能报错

TPS是衡量服务器好坏的唯一指标，TPS越高服务器性能越好，TPS越低服务器性能越差

5. 并发测试
1）相对并发测试：测试出来的数据不是很准确
2）绝对并发测试：所有的用户在同一时间请求同一个接口 ==》添加 同步定时器 （集合点）

6. 单接口场景和混合场景负载测试
1）并发用户模型：不断的去增加用户数对服务器施加压力，站在用户的角度去思考问题
2）吞吐量模型：不断的增加请求出对服务器施加压力，站在服务器的角度去思考问题
单接口场景：登录接口
混合接口场景：登录接口+查询接口 ==》登录查询业务
单接口场景的TPS一般比多接口的TPS要高多

7. 压力测试和性能测试需要关注的指标
1）业务指标：TPS、接口响应时间（接口平均响应时间，90%line）、错误率
2）硬性指标：CPU和内存的使用率低于70%，还有网络IO和磁盘IO

业务指标主要关注了：接口的平均响应时间、90%line、吞吐量tps（系统每秒处理事务数）、错误率
资源指标主要关注了： cpu、内存、磁盘、网络（i/o）
应用指标主要关注了：如空闲线程数、数据库连接数、GC/FULL GC次数、函数耗时等。
前端指标主要关注了：如页面加载时间、网络时间（DNS、连接时间、传输时间等）
我们当时规定的tps必须要达到270/s以上，接口的平均响应时间要小于3秒，错误率为0%，CPU和内存的使用率是需要低于70%以下的

8. 通过jmeter -n -t XX.jmx -l XX.jtl -e -o ./report命令行做压测
参考地址：
https://www.cnblogs.com/xiaoshubass/p/16984657.html ==》先配置环境
https://www.cnblogs.com/xiaoshubass/p/17512575.html ==》使用命令进行压测

9. 性能测试结果分析和编写性能测试报告
有发参考的报告在QQ群里，自己可以去总结一下报告里面有哪些内容

10. 性能测试的面试题
1）怎么找出性能测试的拐点？
答：TPS上升到最高点开始下降，响应时间开始上升的这个点就是性能的拐点和瓶颈点

2）怎么知道服务器所能承受的最大的并发用户数
我会通过阶梯式加压的方式去进行测试，比如20-40-60-80-100-120-140-160，当接口响应时间不超过3秒，接近3秒，并且TPS最优，接口无报错，此时对应的并发线程数就是最优的并发用户数
TPS的计算公式：TPS=并发用户数/接口响应时间
注意：并发用户数并不是越高越好，并发用户数越高，带来响应时间也会增加，以及错误率也会提升

3）求出最大的tps
可以使用jp@gc - Transactions per Second插件去看最高的TPS就是可以了
TPS的计算公式：TPS=并发用户数/接口响应时间

4）你们之前公司的tps能达到多少？
答：每个接口的TPS都是不一样的，增加类的接口TPS就会高一点，查询类的接口TPS就会低一点，==》800多TPS，1000多TPS

5）什么情况下TPS等于QPS？
处理单接口事务的时候TPS和QPS是相等的

6）你们在做性能测试的时候是用的单机去压测还是用的多机（分布式）
建议回答：是用的单机去压测的

7）如果不知道并发线程数数到底取多大，怎么操作？
我会通过阶梯式加压的方式去进行测试，比如20-40-60-80-100-120-140-160

作业：

1、背诵性能测试讲解：
（参考如下文或者自己编写讲解文档）https://www.cnblogs.com/xiaoshubass/p/16352846.html
性能测试或者压力测试你用jmeter是怎么做的？
【保险业务讲：登录接口，查看险种接口，投保接口，投保用户列表接口，保单查询接口，保单管理接口】【电商业务讲：登录接口，添加商品接口，关联优惠券接口，查询商品列表接口，商品详情页等等接口】

答案一：我们产品经理首先会进行性能需求分析评审，并且和我们讲解完之后，我们就会根据需求做性能场景的设计，比如我就拿我之前做过的一个贷款业务，首先是有登录-贷款资料录入-初审-回退-重新提交-复审-签约接口这样的一个压测场景，和您这边大概说一下吧：【超级重点】
首先我会在Jmeter里面组建接口，把接口请求组建好之后，设置对应的并发线程数比如100，然后再添加TPS插件，接口响应时间插件，混合图表，查看结果树，聚合报告等等，然后就开始点击运行，持续压测5分钟，在压测过程当中，我一般会去看TPS和接口响应时间的变化，如果压出来的结果TPS是符合我们要求的，并且接口的响应时间也是符合我们要求的，并且没有错误率，我们就认为这个接口的压测是通过的。
除了这些我还会在服务器端用top命令去监控它的cpu和内存，如果CPU和内存的使用率都能低于70%的话那就说明没问题，我会去输出性能测试报告，然后再发送报告给到我整个项目组。

答案二：我们一般会先问产品和业务那边tps和响应时间和CPU，内存指标的一些要求，得到这些之后，我会根据需求做性能场景的设计，设计完之后我会在jmeter里面添加阶梯加压的线程组，设置最高300并发线程数，然后分10次递增，递增的时间为2分钟，再稳定运行3分钟，再添加TPS插件，响应时间插件，以及混合图表，查看结果树，聚合报告这些，然后就开始点击运行，进行压测，在压测过程当中，我会通过去看混合图表，看接口响应时间跟我的TPS之间的一个曲线变化，然后通过在聚合报告里面看吞吐量tps是否符合我们之前业务定的tps，如果符合的话，还要去关注接口的响应时间90%line是不是在3秒钟之内。如果在3秒之内就是合格的，还有就是事务的成功率是否高于99.9%，如果低于的话说明接口有很多的报错，也是不符合性能要求的。
除了这些我还会在服务器端用top和vmstat命令去监控它的cpu和内存，如果CPU和内存的使用率都能低于80%的话那就说明没问题，我会去输出性能测试报告，然后再发送报告。

答案三：我们一般会根据这个版本的性能需求，然后问运维那边生产有多少笔数据，然后通过最近3个月的峰值去计算一个通用模型的tps，然后再根据一天内调用的接口按业务比例相乘得到每个接口的tps，然后根据需求做性能场景的设计，先设计单业务场景的负载测试，然后再设计混合场景的负载测试，最后再设计稳定性压测场景，设计完再根据场景组建性能测试脚本，比如我会在jmeter里面添加普通线程组或者阶梯加压线程组，设置对应的并发线程数，然后设置ramp-up，然后设置稳定运行5分钟，然后把这个jmx文件导出上传到服务器，通过jmeter -J{参数名} -r{host} -n -t XX.jmx -l XX.jtl -e -o httpreport命令进行压测，在服务器端新开窗口通过top命令查看CPU和内存是否低于80%，还有load负载和sy，us这些，通过jstat -gc查看是否有GC，通过vmstat去查看是否有iowait和cs和in这些，然后运行完之后再把生成的jtl文件，在jmeter里面加载出来，再进行一个瓶颈的分析。然后再一个一个测完，找出性能瓶颈和提供优化建议，最后我会去输出性能测试报告，然后再发送报告。

2、背诵性能指标和性能bug ==》https://www.cnblogs.com/xiaoshubass/protected/p/17146923.html ==》常见的bug

有次我在做压测的时候，发现TPS就是上不去，然后呢通过用dstat -tcmnd --disk-util 命令去监控的时候发现CPU的使用率始终没有很大的波动、空闲95%左右、只占用了5%左右、当时就觉得应该不是fullGC和youngGC 内存泄露和内存溢出的问题，为了进一步的排查和定位我后面通过通过jstack 进程号 >1.log命令去获取对应的日志、看一下是不是线程阻塞的问题，然后把捕捉的日志下载到本地用notepad++打开、发现Thread.stat：Blocked阻塞的地方多达70多个地方，后面又通过反编译工具把log4j的jar包打开、找到了Category.class这个类、发现里面的第204行调了一个方法叫做callAppenders里面用了synchronized的锁，原因找到了是log4j里面为了保证线程的安全，里面加了很多的锁但是却牺牲了很多的性能，后面我们优化的时候就是首先进入项目中找到log4j.properties这个文件然后把log4j.rootLogger=info 中的info改为error、提升打日志的等级，然后重启项目，这个进行优化之后、重新压测发现TPS达到了7000/sec 、优化阻塞之后发现性能提升了3倍左右、CPU也占用了15%左右，当然也可以用log4j2打日志，因为这个log4j2在原来的log4j的基础上做了重构做了性能的优化、做了异步处理比log4j和logback有了18倍的性能的提升

3、TPS上不去的原因 ==》 https://www.cnblogs.com/xiaoshubass/p/17146837.html

1.网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，导致服务端接收到的请求数达不到服务端的处理能力上限。
2.连接池
可用连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行），没有保持长连接，TCP 连接频繁中断
3.GC
如果堆内存分配的不合理，就会导致频繁的gc，gc会导致线程暂停。尤其是fullgc，会造成线程长时间暂停，代码故障，list 使用 contain 方法进行遍历去重，线程阻塞或者死锁
jvm 内存分配故障，fullgc 频繁，内存溢出
4.数据库配置
高并发情况下，如果请求数据需要写入数据库且需要写入多个表的时候，数据库的最大连接数不够，或者写入数据的SQL没有索引，或没有主从分离、读写分离，就会导致数据库事务处理过慢，还有数据库没加索引，db 缓存空间不足，也会影响到TPS。
5.硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）
6.压力机
单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，会影响TPS（这个时候就需要进行分布式压测来解决问题）
7.其他中间件
Nginx 负载均衡策略不当，压力分配不均
Redis 瓶颈。hash 未合并，缓存被击穿，单条命令耗时过长
8.硬件资源中CPU和内存
服务器资源不足，上下文切换过快，中断过高，swap 交换频繁
压力大的时候tps频繁抖动，导致总tps上不去。查看是否有fullgc（tail -f gc_mSrv1.log | grep full）
pacing设置太小也会导致tps上不去，对抖动大的交易多增加点用户即可。
tps抖动，单压抖动大的交易，发现很平稳，这时怀疑是不是压力太大导致，所以发容量的时候把压力最大的那只交易分到其他压力机，然后发现tps不抖动了。注意：多台压力机只影响tps抖动，不会影响服务器的cpu。看响应时间有没有超时，看用户数够不够。