到底什么是QPS、TPS、RT、PV、UV、IV、VV、IP、系统吞吐量?

QPS:Queries Per Second意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。    
TPS: 是TransactionsPerSecond的缩写,也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。    
RT: 响应时间(RT) 是系统对请求作出响应的时间。并发数: 系统同时处理的request/事务数    
RT,TPS,QPS关系    
QPS(TPS)= 并发数/平均响应时间 或者 并发数 = QPS*平均响应时间    
案例    
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,在因特网上,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。    
原理:每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间    
公式:( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)    
机器:峰值时间每秒QPS / 单台机器的QPS = 需要的机器    
每天300w PV 的在单台机器上,这台机器需要多少QPS?    
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)    
如果一台机器的QPS是58,需要几台机器来支持?    
139/58取整为3台机器    
PV: 访问量(页面浏览量),偶页面访问量,每打开一次页面PV计数+1,刷新页面也是。    
Page View访问量, 即页面浏览量或点击量,衡量网站用户访问的网页数量;在一定统计周期内用户每打开或刷新一个页面就记录1次,多次打开或刷新同一页面则浏览量累计。    
UV: 访问数(Unique Visitor)指独立访客访问数,一台电脑终端为一个访客。    
Unique Visitor独立访客,统计1天内访问某站点的用户数(以cookie为依据);访问网站的一台电脑客户端为一个访客。可以理解成访问某网站的电脑的数量。网站判断来访电脑的身份是通过来访电脑的cookies实现的。如果更换了IP后但不清除cookies,再访问相同网站,该网站的统计中UV数是不变的。如果用户不保存cookies访问、清除了cookies或者更换设备访问,计数会加1。00:00-24:00内相同的客户端多次访问只计为1个访客。    
IV:是IP访问数指独立IP访问数,计算是以一个独立的IP在一个计算时段内访问网站计算为1次IP访问数。在同一个计算时段内不管这个IP访问多少次均计算为1次。计算时段有以1天为一个计算时段,也有以1个小时为一个计算时段。    
VV: 即VisitView,访客的访问次数,用以记录所有访客1天内访问了多少次您的网站。当访客完成所有浏览并最终关掉该网站的所有页面时便完成了一次访问,同一访客1天内可能有多次访问行为,访问次数累计;    
IP: Internet Protocol独立IP数,是指1天内多少个独立的IP浏览了页面,即统计不同的IP浏览用户数量。同一IP不管访问了几个页面,独立IP数均为1;不同的IP浏览页面,计数会加1。 IP是基于用户广域网IP地址来区分不同的访问者的,所以,多个用户(多个局域网IP)在同一个路由器(同一个广域网IP)内上网,可能被记录为一个独立IP访问者。如果用户不断更换IP,则有可能被多次统计。
系统吞吐量:
吞吐量是指对网络、设备、端口、虚电路或其他设施,单位时间内成功地传送数据的数量(以比特、字节、分组等测量)。--百度百科
系统吞吐量是指在单位时间内中央处理器(CPU)从存储设备读取->处理->存储信息的量。
吞吐量影响因素:
1、存储设备的存取速度,即从存储器读出数据或数据写入存储器所需时间;
2、CPU性能:①时钟频率②每条指令所花的时钟周期数(即CPI);③指令条数;
3、系统结构:如,并行处理结构可增大吞吐量

综上:        
一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。        
单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高。        
系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间        
QPS(TPS):每秒钟request/事务 数量        
并发数:系统同时处理的request/事务数        
响应时间: 一般取平均响应时间一个系统吞吐量通常由QPS(TPS)、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。

不同角度性能关注点:    
1.用户
首先,开发软件的目的是为了让用户使用,我们先站在用户的角度分析一下,用户需要关注哪些性能。                
对于用户来说,当点击一个按钮、链接或发出一条指令开始,到系统把结果已用户感知的形式展现出来为止,这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间,当相应时间较小时,    用户体验是很好的,当然用户体验的响应时间包括个人主观因素和客观响应时间,在设计软件时,我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如:用户在大数据量查询时,我们可以将先提取出来的数据展示给用户,在用户看的过程中继续进行数据检索,这时用户并不知道我们后台在做什么。用户关注的是用户操作的相应时间。                
2.管理员                
①响应时间②服务器资源使用情况是否合理③应用服务器和数据库资源使用是否合理④系统能否实现扩展                
⑤系统最多支持多少用户访问、系统最大业务处理量是多少⑥系统性能可能存在的瓶颈在哪里                
⑦更换那些设备可以提高性能⑧系统能否支持7×24小时的业务访问                
3.开发(设计)人员                
①架构设计是否合理②数据库设计是否合理③代码是否存在性能方面的问题④系统中是否有不合理的内存使用方式                
⑤系统中是否存在不合理的线程同步方式⑥系统中是否存在不合理的资源竞争                
4.性能测试人员                
关注以上所有的性能点                
软件性能主要术语:                
1、响应时间:对请求作出响应所需要的时间                
网络传输时间:N1+N2+N3+N4                
应用服务器处理时间:A1+A3                
数据库服务器处理时间:A2                
响应时间=N1+N2+N3+N4+A1+A3+A2                
备注:                
客户端发出请求首先通过网络来到Web Server上(消耗时间为N1);                
Web Server将处理后的请求发送给APP Server(消耗时间为N2);                
APP Server将操作数据指令发送给DataBase(消耗时间为N3);                
DataBase服务器将查询结果数据发送回APP Server(消耗时间为N4);                
APP Server将处理后的数据发送回Web Server(消耗时间为N5);                
最后Web Server将HTML转发到客户端(消耗时间为N6);                
这里的Nx都是网络传输上的时间开销,没有计算业务处理所需花费的时间

2、并发用户数的计算公式                    
系统用户数:系统额定的用户数量,如一个OA系统,可能使用该系统的用户总数是5000个,那么这个数量,就是系统用户数。                    
同时在线用户数:在一定的时间范围内,最大的同时在线用户数量。                    
同时在线用户数=每秒请求数RPS(吞吐量)+并发连接数+平均用户思考时间                    
平均并发用户数的计算:C=nL / T其中C是平均的并发用户数,n是平均每天访问用户数(login session),L是一天内用户从登录到退出的
平均时间(login session的平均时间),T是考察时间长度(一天内多长时间有用户使用系统)并发用户数峰值计算:C^约等于C + 3*根号C ,其中C^是并发用户峰值,C是平均并发用户数,该公式遵循泊松分布理论                
3、吞吐量的计算公式                    
指单位时间内系统处理用户的请求数。                    
从业务角度看,吞吐量可以用:请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量                    
从网络角度看,吞吐量可以用:字节/秒来衡量                    
对于交互式应用来说,吞吐量指标反映的是服务器承受的压力,他能够说明系统的负载能力以不同方式表达的吞吐量可以说明不同层次的问题,例如,以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈;已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。当没有遇到性能瓶颈的时候,吞吐量与虚拟用户数之间存在一定的联系,可以采用以下公式计算:F=VU * R /    其中F为吞吐量,VU表示虚拟用户个数,R表示每个虚拟用户发出的请求数,T表示性能测试所用的时间系统服务端性能影响的因素                    
1、衡量服务性能的指标,主要有两个:                    
QPS(Query Per Second,每秒请求数)                    
响应时间(Response Time,RT),它可以理解为服务器处理响应的耗时。                    
正常情况下,响应时间越短,QPS则越高。在单线程的情况下,是呈线性关系。但也不是无限增长,RT总会有极限值。多线程时,总QPS = (1000ms/ 响应时间)* 线程数。                
2、响应时间与QPS的关系                    
对于Web系统,响应时间一般由CPU的处理时间和线程的等待时间组成。通过减少线程的等待时间,对于系统的性能提升并不是很大。真正对性能有影响的是 CPU 的执行时间。经过实际的测试,如果减少 CPU 一半的执行时间,就可以增加一倍的 QPS。            
3、线程数对QPS的影响                    
根据公式 总QPS = (1000ms/ 响应时间)* 线程数,直觉上,线程数增多QPS越高。实际上,线程数并不是越多越好。因为线程本身也占用资源,也受其他因素制约。例如,线程越多系统的线程切换成本就会越高,而且每个线程也都会耗费一定内存。(单线程语言,即使是在单台服务器上建立多个实例,也会受到服务器本身资源的限制。例如,nodeJS可以使用PM2,在一台服务器上启动多个线程,但是服务器本身资源的有限。)    
4、如何设置合理的线程数                    
通用公式如下:线程数 = 2 * CPU核数 + 1                    
最佳实践的公式:线程数 = [(线程等待时间 + 线程 CPU 时间) / 线程 CPU 时间] × CPU 数量当然,最好的办法是通过性能测试发现系统的最佳线程数。                
5、如何发现瓶颈                    
我们可以通过系统的监控工具,发现系统的性能瓶颈。通常会发生性能瓶颈的地方有CPU、内存、磁盘、网络、数据库等。常见地,缓存系统容易发生瓶颈的地方是内存,储存型系统则是I/O。如何简答判断CPU是否发生瓶颈了?我们可以观察,当 QPS 达到极限时,服务器的 CPU 使用率是不是超过了 95%,如果没有超过,那么表示 CPU 还有提升的空间。    
6、性能优化的过程                    
①发现短板②减少数据。事实上,有两个地方特别影响性能。一是服务端在处理数据时不可避免地存在字符到字节的相互转化,二是 HTTP 请求时要做 Gzip 压缩,还有网络传输的耗时,这些都和数据大小密切相关。    
③数据分级。首屏数据、重要信息优先,次级信息异步加载。    
④减少中间环节。

附:性能测试指标

并发 响应时间 应用服务器cpu 数据库服务器cpu TPS
50 1s 50% 20% 50

猜你喜欢

转载自blog.csdn.net/qq_36632174/article/details/108995865
今日推荐