QPS、TPS、RT、吞吐量
一、QPS「每秒查询」
QPS:Queries Per Second意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
互联网中,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
二、TPS「每秒事务」
TPS:是TransactionsPerSecond的缩写,也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。
QPS vs TPS:QPS基本类似于TPS,但是不同的是,对于一个页面的一次访问,形成一个TPS;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就可计入“QPS”之中。
如,访问一个页面会请求服务器2次,一次访问,产生一个“T”,产生2个“Q”。
三、RT「响应时间」
响应时间:执行一个请求从开始到最后收到响应数据所花费的总体时间,即从客户端发起请求到收到服务器响应结果的时间。
响应时间RT(Response-time),是一个系统最重要的指标之一,它的数值大小直接反应了系统的快慢。
四、并发数
并发数是指系统同时能处理的请求数量,这个也是反应了系统的负载能力。
五、吞吐量
系统的吞吐量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。单个request 对CPU消耗越高,外部系统接口、IO速度越慢,系统吞吐能力越低,反之越高。
系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间。
- QPS(TPS):(Query Per Second)每秒钟request/事务 数量
- 并发数: 系统同时处理的request/事务数
- 响应时间: 一般取平均响应时间
理解了上面三个要素的意义之后,就能推算出它们之间的关系:
- QPS(TPS)=
并发数/平均响应时间 - 并发数 =
QPS*平均响应时间
六、实际举例
我们通过一个实例来把上面几个概念串起来理解。
按二八定律来看,如果每天 80% 的访问集中在 20% 的时间里,这 20% 时间就叫做峰值时间。
- 公式:
( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) - 机器:
峰值时间每秒QPS / 单台机器的QPS = 需要的机器
1、每天300w PV 的在单台机器上,这台机器需要多少QPS?
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
2、如果一台机器的QPS是58,需要几台机器来支持?
139 / 58 = 3
注意机房的网络带宽:
有人说以上条件我都满足了,但实际性能还是达不到目标。这时请注意你对外的网络的带宽,在国内服务器便宜但带宽很贵,很可能你在机房是与大家共享一条100M的光纤,实际每个人可分到2M左右带宽。再好一点5M,再好一点双线机房10M独享,这已经很贵了(北京价格)。
一天总流量:每个页面20k字节*100万个页面/1024=19531M字节=19G字节,19531M/9.6小时=2034M/小时=578K字节/s 如果请求是均匀分布的,需要5M(640K字节)带宽(5Mb=640KB 注意大小写,b是位,B是字节,差了8倍),但所有请求不可能是均匀分布的,当有高峰时5M带宽一定不够,X2倍就是10M带宽。10M带宽基本可以满足要求。
以上是假设每个页面20k字节,基本不包含图片,要是包含图片就更大了,10M带宽也不能满足要求了。你自已计算吧。
七、最佳线程数、QPS、RT
单线程QPS公式:QPS=1000ms/RT
对同一个系统而言,支持的线程数越多,QPS越高。
假设一个RT是80ms,则可以很容易的计算出QPS,QPS = 1000/80 = 12.5
多线程场景,如果把服务端的线程数提升到2,那么整个系统的QPS则为 2*(1000/80) = 25, 可见QPS随着线程的增加而线性增长,那QPS上不去就加线程呗,听起来很有道理,公司也说的通,但是往往现实并非如此。
QPS和RT的真实关系
我们想象的QPS、RT关系如下,

实际的QPS、RT关系如下,

最佳线程数量
性能压测的情况下,起初随着用户数的增加,QPS会上升,当到了一定的阀值之后,用户数量增加QPS并不会增加,或者增加不明显,同时请求的响应时间却大幅增加。这个阀值我们认为是最佳线程数。
为什么要找最佳线程数
- 过多的线程只会造成,更多的内存开销,更多的CPU开销,但是对提升QPS确毫无帮助
- 找到最佳线程数后通过简单的设置,可以让web系统更加稳定,得到最高,最稳定的QPS输出
最佳线程数的获取:
- 通过用户慢慢递增来进行性能压测,观察QPS,响应时间
- 根据公式计算:服务器端最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu数量
- 单用户压测,查看CPU的消耗,然后直接乘以百分比,再进行压测,一般这个值的附近应该就是最佳线程数量。
影响最佳线程数的主要因素:
1. IO
IO开销较多的应用其CPU线程等待时间会比较长,所以线程数量可以开的多一些,相反则线程数量要少一些,其实有两种极端,纯IO的应用,比如proxy,则线程数量可以开到非常大(实在太大了则需要考虑线程切换的开销),这种应用基本上后端(比如这个proxy是代理搜索的)的QPS能有多少,proxy就有多少。
2. CPU
对于耗CPU的计算,这种情况一般来讲只能开到CPU个数的线程数量。但是并不是说这种应用的QPS就不高,往往这种应用的QPS可以很高,因为耗CPU计算的应用,往往处理单次请求的时间会很短。
QPS和线程数的关系
- 在最佳线程数量之前,QPS和线程是互相递增的关系,线程数量到了最佳线程之后,QPS持平,不在上升,甚至略有下降,同时响应时间持续上升。
- 同一个系统而言,最佳线程数越多,QPS越高