根据学习全栈测试博主的课程做的笔记
一、说明
若未特别说明，涉及术语都是jmeter来说，线程数，就是jmeter线程组中的线程数
二、软件性能是什么
1、用户关注：响应时间
2、业务/产品关注：响应时间、支持多少并发数、对业务的处理能力
3、运维关注：响应时间（是否有超时的请求）、资源利用率、稳定性等
4、dba关注：响应时间（慢sql或者死锁），关注数据库的资源利用情况（表空间的资源使用情况）
5、开发关注:响应时间(代码逻辑的处理快慢，特别是锁，锁的力度不合理导致后来的请求响应时间长）
6、架构师关注：架构是否涉及合理（是否具备扩展能力）
7、测试关注（关注6类用户关注的）：响应时间、处理能力（TPS）、稳定性、什么时候进行扩展等
三、几个性能测试相关得概念
1、 负载测试：不同客户端线程数下服务器处理的能力
客户端线程数下即就是jmeter下的线程数
模拟客户端向服务器发送压力
2、容量测试:强调的是容量测试、业务（混合容量tps），当前支持的最大容量、对未来容量的规划
数据库容量即就是数据库的数据量
3、递增测试：强调的是递增，连续递增加压，看服务器的处理能力
4、 强度测试：用大量的客户端，并发线程看服务端表现情况
5、性能测试：在某个特点的硬件、软件、网络设计场景模拟并发请求，通过监控分析进行调优，达到性能测试目标
6、总结
前面的四种强调的是不同的性能测试方式，性能测试场景的设计。可以将四种测试设计在里面。负载测试（场景就是阶梯加压，每个阶梯对应的就是客户端的线程数，对应的负载，再测一个最大值。
递增测试：连续阶梯加压。
强调测试：连续阶梯加压，测试最大值。
四、性能测试中的关键术语
1、 并发、线程、tps
1.1公司要求500并发、500并发表示什么？
1.2并发分类、以及线程、tps的关系
1.2.1绝对并发–狭义：表示服务端某一个时刻物理的请求数。处理的请求数和什么有关系？
如某一个服务器是16c，64g,某一个时刻处理多少请求和逻辑cpu有关系，实际测试时服务端做并发。
1.2.2相对并发-广义/tps
某一个时间段内处理的请求数，相对并发才是真正服务器的处理能力。不是站在服务器逻辑cpu的角度。
平时的并发就是相对并发，就是tps。
tps就是每秒钟处理多少个请求，1s是时间段。
为什么并发是tps？
解释：并发=tps，需要站在客户端和服务端的视角下。
上面两个并发仅站在服务端的角度，tps是要站在客户端和服务端的视角下。把并发分为客户端并发和服务端并发。
很多都是认为客户端jmeter处的线程数就是并发数.,其实没啥问题，但是需要认定为客户端并发，而并不是服务端并发。还把并发分为客户端并发和服务端并发。
1.2.3客户端并发
此处的jmeter中的线程数是模拟大量请求对服务端产生压力,此时的数值在性能测试中是没有参考意义的。
此处并不能说明值设计的越大，性能就越好。而是需要看服务器的处理情况(服务器的tps、成功率、响应时间）
一般说的并发说的是服务端的并发。
并发不等于线程数,为什么?
举例：若每秒的线程数为10，每个线程数1s内可以完成10个事务，循环发10次请求。此处完成的请求是100个，看性能需要看服务端而不是客户端，服务端相当于是10个线程，完成了10个事务，循环发了10个事务的请求，服务端都进行了处理。即并发–100，则tps是100。
线程是否是用户 10个线程不等于10个用户(虚拟用户）
领导要求500并发，并不是说jmeter客户线程数设置就是500.jmeter的线程数是可以随意设置的最好的就是连续加压，可以看到每个阶梯的tps使用情况再看监控。
每个线程1s，阶梯加压到50个线程时tps就是500。
前提：tps服务器处理请求随着jmeter线程数增加而线性增加。
压测不仅要压目标tps，还需要压测出最大的tps.
50个线程已经达到500目标tps。假设在200个线程时，线程增加时，最大的目标tps则为2000，继续加压时，tps则下降，这时已经超过服务器的最大处理能力，请求都在排队，响应时间增长。
所以如果一个系统的响应比较快，1个线程1s时间内可以完成10个事务，需要设置的线程数是小于客户端jmeter的线程数。
并发：客户端的并发只是为了模拟用户给服务端加压力，他是没有参考意义的，是需要服务端的并发,服务端的并发是tps
线程是否=用户？(虚拟用户）
线程不等于用户（为什么？
因为线程做了用户的动作，线程的每一次迭代才称为用户）即jmeter处的循环次数，发一次请求服务端给一次响应，这个是迭代。
注册场景：
1s内，1个线程可以发10次请求，注册时用户名需要不一样，此时假设已经参数化并且参数是足够多，1个线程1s可以发10次请求就相当于10个用户进行注册，10个线程就是发100个请求，即就是100个用户进行注册，100个用户用户名不同。并发用户数此时是100，tps100，压力线程数是10.
可以这么理解：
线程只是执行用户的操作，线程的每一次迭代是模拟了用户的操作。
事务（关注流程,整个流程就为请求，若不关注流程，一个请求就是一个事务就是）
1.2.4服务端并发（站在业务层面，站在服务器的处理能力进行谈并发）
客户端并发只是为了向服务端发送压力，并没有什么参考意义。
服务端并发的：前提是需要保证事务的成功率，具体是多少，看行业要求，涉及到金钱事务的成功率是100%，涉及到其他一般是项目组定(如99.9%）
1.2.5线程和tps的瞬时计算
线程和tps的瞬时计算，并不是整个的计算
此处表面3个线程，1s可以完成5次请求，3个线程即就是3*5=15，
tps=15=总请求数/并发时间=15/1s=35=3（1000ms/200ms）
总请求数/并发时间=线程数*(1000/rt每个请求的响应时间)
rt是瞬时值
2、QPS和TPS的区别
QPS（Query Per Second）:每秒钟的查询
TPS（Transaction per Second)）：每秒钟的处理事务数
3、响应时间rt：判断业务快慢的指标
正常的性能压测响应时间都是从低到高
刚开始压力小时，服务器都能进行处理，响应也比较快。随着压力越来越大，处理不过来，请求排队。
3.1rt增加、表示开始出现性能瓶颈
3.2补充瓶颈分析
此处简单介绍，后面详细解释
3.2.1简单架构
对于简单架构，一般是通过服务器的资源情况进行判断是否出现瓶颈。
3.2.2复杂架构（微服务）
对于复杂架构
就需要进行去分解响应时间看什么地方耗时多。
对时间的分解的方式：日志打点计时器,通过日志去查看请求的时间，
对于微服务最后是：链路监控工具（skywalking)
4、 线程、tps、rt三者的关系
4.1线程、tps、rt三者关系图
jmeter线程数增加，发送的请求增加，刚开始都能处理，随着增加线程逐渐增加，服务器的资源利用率就会增加（cpu、mem），此图，tps随着线程数的增加是线性增加，到了一定阶段后，服务器出现了瓶颈后，响应时间开始增加，tps达到最大值后，tps增幅趋于平稳或者下降
4.2连续阶梯加压场景设计图（这个是用插件实现的）
图上斜的就是启动线程，启动多少线程
启动后又可以平稳的运行一段时间
五、性能指标
怎么衡量系统的性能？以下指标
1、tps、rt、成功率
tps是用来衡量服务器的处理能力,而在jmeter中就是压测那段时间内，总的请求数/压测的时间=tps
rt:jmeter中有平均响应时间、90%、95%、99%的响应时间
成功率也有进行统计。
