1、QPS
服务器每秒处理查询次数,是一台服务器每秒能够处理的查询次数。
用户发起查询请求到服务器做出响应这算一次,一秒内用户完成了50次查询请求,那此时服务器QPS就是50。
2、TPS
服务器每秒处理事务数,一个事物是用户发起查询请求到服务器做出响应算一次。
划重点,这里就要说清楚一个概念了,在针对单接口,TPS可以认为是等价于QPS的,如访问order.html这个页面而言,是一个TPS。
而访问order.html页面可能请求了3此服务器(如调用了css、js、order接口),这实际就算产生了三个QPS。
总结:在针对单接口的时候TPS = QPS ,否则QPS就要看实际的请求次数了。
3、RT
响应实际,就是从客户端请求发起到服务器响应结果的时间。
RT这个参数是系统最重要的指标之一,它的大小直接反应了当前系统的响应状态。
基本和咱们用户体验息息相关,现在好一点监控系统一般都有三个RT,即平均、最大、最小。
一般系统RT 100ms 以内是比较正常的,300ms 勉强可以接受,1s的话再加上一些其他的外因,给用户的体验就是实实在在的不爽了。
4、并发数
系统能同时处理的请求的数量,很多人经常会把并发数和TPS理解混淆。
举例:请求一个index.html 页面,客户端发起了三个请求(css、js、index接口),那么此时TPS =1 、QPS =3 、并发数 3。
所以,计算公式 :
QPS=并发数/RT || 并发数=QPS*RT
5、吞吐量
每秒承受的用户访问量,吞吐量(系统能承受多少压力)和当前请求对CPU消耗、内存、IO使用等等紧密相关。
单个请求消耗越高,系统吞吐量越低,反之越高。
一个系统的吞吐量和其TPS 、QPS、并发数息息相关,每个系统针对这些值都有一个相对极限值,只要其中某一个达到最大,系统的吞吐量也就到达极限了。
如此时压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,各种资源切换等等的消耗导致系统性能下降。
关系:所以,理解上面几个关系后,就可以推算出:
QPS(TPS)= 并发数/平均响应时间
6、PV
概念:即每个页面的浏览次数,用户每次刷新就算一次。
7、UV
独立访客数,每天访问的用户数,此数据需要根据用户唯一标识进行去重。
8、Load(系统负载)
Linux系统的负载情况,使用TOP命令,最上面显示的数据信息( load average:0.1, 0.2, 0.5)。
load average 的值越低,系统负荷越小。
查看:
如果单核cpu,那此值为1的时,系统已经满负荷状态了,需要马上去解决。
但实际经验,当系统负荷持续大于0.7的时候(也就是70%),就要马上解决问题了,防止进一步恶化。
为什么需要三个值 load average:0.1, 0.2, 0.5
比如只有1分钟的是1,其他俩都是0.1,这表明只是临时突发的现象,问题不大。
如果15分钟内,系统负荷都是1或大于1,那表明问题持续存在。所以应主要观察15分钟的系统负荷。
行动吧,在路上总比一直观望的要好,未来的你肯定会感 谢现在拼搏的自己!如果想学习提升找不到资料,没人答疑解惑时,请及时加入扣群: 320231853,里面有各种软件测试+开发资料和技术可以一起交流学习哦。
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!