性能测试相关理解(一)

根据学习全栈测试博主的课程做的笔记

一、说明

若未特别说明,涉及术语都是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%的响应时间
成功率也有进行统计。

2、也可以加上技术指标:sql耗时不能超过200ms,fgc在多少时间范围内不能超过多少次,服务器资源使用情况

相关推荐
腥臭腐朽的日子熠熠生辉23 分钟前
解决maven失效问题(现象:maven中只有jdk的工具包,没有springboot的包)
java·spring boot·maven
ejinxian25 分钟前
Spring AI Alibaba 快速开发生成式 Java AI 应用
java·人工智能·spring
杉之30 分钟前
SpringBlade 数据库字段的自动填充
java·笔记·学习·spring·tomcat
圈圈编码1 小时前
Spring Task 定时任务
java·前端·spring
俏布斯1 小时前
算法日常记录
java·算法·leetcode
27669582921 小时前
美团民宿 mtgsig 小程序 mtgsig1.2 分析
java·python·小程序·美团·mtgsig·mtgsig1.2·美团民宿
爱的叹息1 小时前
Java 连接 Redis 的驱动(Jedis、Lettuce、Redisson、Spring Data Redis)分类及对比
java·redis·spring
程序猿chen1 小时前
《JVM考古现场(十五):熵火燎原——从量子递归到热寂晶壁的代码涅槃》
java·jvm·git·后端·java-ee·区块链·量子计算
松韬2 小时前
Spring + Redisson:从 0 到 1 搭建高可用分布式缓存系统
java·redis·分布式·spring·缓存
绝顶少年2 小时前
Spring Boot 注解:深度解析与应用场景
java·spring boot·后端