性能测试
时间：系统处理请求的响应时间
资源：系统在运行过程中，系统资源消耗的情况
1、什么是性能测试¶
2、性能测试的目的¶
评估当前系统的能力
寻找性能瓶颈，优化性能
评估软件是否满足未来的需求
3、什么项目适合性能测试¶
基础功能要完成，并且保证系统是处于稳定的状态
项目用户人数比较多，或者并发量比较大
有单独的测试环境（性能测试环境）
4、性能测试分类¶
5、负载测试¶
通过逐步增加系统的负载，确定满足系统性能指标（比如：响应时间等）情况下，找出系统能够承受的最大负载量
作用：系统最大负载量达到用户要求时，系统才能正式上线
6、稳定性测试¶
在服务器稳定运行（用户正常的业务负载下）的情况下长时间测试（1天----1周）,并最终保证服务器能满足线上业务需求。
作用：系统在用户要求的业务负载下运行达到规定时间时，系统才可以正式上线使用
7、并发测试¶
在极短的时间内，发送多个请求来验证服务器对并发的处理能力
适用场景：抢红包，秒杀，抢购
8、压力测试¶
在强负载下的测试，查看系统在峰值情况下是否功能隐患，系统是否具有良好的容错能力和恢复能力
负载和压力测试
负载测试是以并发维度出发，在不断增加并发的情况下，查看系统的性能指标
压力测试是以访问时间维度出发，在并发量一定的情况下不断增加访问时间的情况下，查看系统的性能指标。
并发测试：同一时间，同一时刻，同时请求，查看在这个时间内服务器的运行情况
9、性能指标¶
响应时间¶
并发用户数¶
吞吐量¶
TPS(每秒事务数)¶
指系统每秒能够处理事务和交易的数量 tps= 并发数/平均响应时间
QPS（每秒查询率）¶
PV（点击数）¶
页面访问量，用户访问一次计算一次 （点击页面必须发送请求才会计算）
UV(独立访客数)¶
错误率¶
10、资源利用率¶
cpu使用率
不高于 75%-85%
内存（大小）使用率
不高于 80%
磁盘IO(速率)
不高于 90%
网络（速率）
不高于80%
11、性能测试流程¶
- 性能测试需求分析
2. 性能测试计划及方案
3. 性能测试用例设计
4. 性能测试执行
5. 性能测试分析和调优
6. 性能测试报告总结
12、需求分析¶
13、性能关注指标¶
cpu 使用率 不超过75-85%
内存 使用率 不超过 80%
磁盘IO 使用率 不超过90%
网络 不超过 80%
响应时间 单接口（不超过 500ms） 混合接口 不超过2 s
错误率 为 0
吞吐量 （tps）大于或等于需求规定
在规定时间内达到规定的pv量
宽带使用率符合规定
14、jmeter运行 （非 GUI模式）¶
GUI 会消耗系统服务器部分性能，导致压测不准确，或者导致 GUI界面卡死，部分请求会死掉，压测被迫中断。
非GUI模式是通过命令去触发脚本，并且不用实时渲染数据，这样减少了对资源的浪费
准备：
1. 需要有压测脚本
2. 需要有报告存放地址（空文件夹）
3. jtl 文件存放地址 （电脑路径+文件.jtl）
命令：
在 jmeter的bin路径下
jmeter -n -t "压测脚本" -l jtl文件 -e -o 报告地址
-n 非GUI模式运行
-t 执行测试文件脚本位置
-l 指定生成测试结果存放文件
-e 测试结束后生成测试报告
-o 指定测试报告位置
15、性能瓶颈¶
网络宽带
系统瓶颈 （cpu 内存）
数据库瓶颈
应用本身问题（如 项目问题）
应用服务瓶颈 （如 nginx apache linux）
16、性能调优¶
一般优化都是测试提建议，开发或者运维调优
像 硬件问题，网络宽带，系统瓶颈，服务瓶颈这些 提给运维
像 数据库，代码逻辑复杂，程序本身的问题 提给开发去修复
注：性能一般数据库出问题的可能性较大，一般都是 用 非关系数据库解决，或者读写分离
程序本身代码复杂，可以让 开发优化算法，优化代码，优化设计，参数调优，时间换空间，空间换时间
17、TPS上不去（压测过程中）¶
网络宽带
硬件问题（cpu 内存）
项目逻辑复杂，项目本身问题
系统架构
数据库问题
压测脚本配置问题
==通信连接机制问题（cdn ）内容分发网络==
连接池过少，造成请求等待
垃圾回收机制问题
18、性能测试测试的哪一种策略¶
19、压力测试场景¶
1. 全链路
2. 单场景压测
1. 下单
2. 领取优惠券
19、压测是长压还是短压¶
20、压测线程多少¶
注册用户 % 20 ====在线用户
在线用户 %30 ===== 线程（并发用户数）
500
阶梯式压测，最终压测到的500
21、分布式压测¶
并发量较小的情况下不采用分布式压测
jmeter最大 支持1000的并发，超过1000并发考虑分布式压测
一个主控制机然后连接到其他多个执行机进行分布式，把执行机的ip 配置到对应的文件里面，然后远程启动执行机进行压测
压测时间 ： 30分钟
线程数： 500
pv: 90万+
uv: 2000
tps: 180----250
22、性能拐点¶
指的是当并发量达到一定的数量，平均响应时间，tps不增反降，当前并发数就是该测试的拐点。
23、性能测试流程¶
首先先进行需求分析，把需要压测的非功能点整理出来，因为高并发会影响公司同事的正常工作，需要有单独的性能测试环境，和线上环境保持一致，接下来准备压测的脚本编写，使用jmeter工具，配置压测线程组 http请求、tps折线图、响应时间折线图、聚合报告、查看结果树，配置压测策略，配置阶梯式压测逐步增压，知道达到或者超过我们的预期，之前我们压测20分钟，压测到500
在压测过程中也会出现问题，压测到300的时候压测的时候压不上去，当时tps达不到我们的预期，通过调优的方式解决，最后压测到500
在压测过程中我还会使用top、iftop、vmstart、iostart去关注服务器的cpu、内存、磁盘情况，如果有问题我会暂停压测，我们的cpu和内存使用率不能超过80%，最后压测完生成测试报告，报告主要分析的有：响应时间是否在我们的预期内，单线程不超过500ms，多线程不超过2s，请求错误率为零，tps是否等于或者大于我们的需求规定内，带宽是否符合规定，是否在规定时间内达到一定的pv量，这就是性能测试的流程。
24、性能测试出现什么问题¶
性能测试要求达到500的并发量，但是压测到300的时候就压测不上去，tps也达不到我们的预期，当时进行瓶颈分析的时候，认为是项目瓶颈，当时数据库响应过慢，因为当时只用了MySQL数据库，每秒只能处理2w条左右数据，解决的方案是：加入一个非关系型数据库redis，每秒可以处理10w条左右的数据，redis是将数据存放当缓存中，速度比较快，调优之后，再次压测，指标都达到了我们的预期。
25、性能拐点¶
并发量达到一定的数量，平均响应时间，tps不增反降，当前并发数就是测试的系统性能拐点。
26、测试计划¶
测试范围 测试目的 测试人员 人员分配 任务分工 测试时间安排 测试的方法