QPS
原理:每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间。
公式:( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。
机器:峰值时间每秒QPS / 单台机器的QPS = 需要的机器 。
每天300w PV 的在单台机器上,这台机器需要多少QPS?
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。
一般需要达到139QPS,因为是峰值。
QPS
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
每秒查询率
因特网上,经常用每秒查询率来衡量域名系统服务器的机器的性能,其即为QPS。
对应fetches/sec,即每秒的响应请求数,也即是最大吞吐能力。
计算机语言
一种计算机编程语言。用于数据分析和报表产出。运作的平台是MRDCL。支持的数据文件包括ASC格式和CSI格式。
其中CSI格式为QPS独有数据格式。是极其专业的用于数据分析、数据清理和报表产出的语言,目前应用最广的是市场调研行业。中国国内运用的相对比较少。
开发的原因,需要对吞吐量(TPS)、QPS、并发数、响应时间(RT)几个概念做下了解,查自百度百科,记录如下:
1. 响应时间(RT)
响应时间是指系统对请求作出响应的时间。直观上看,这个指标与人对软件性能的主观感受是非常一致的,因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能,而不同功能的处理逻辑也千差万别,因而不同功能的响应时间也不尽相同,甚至同一功能在不同输入数据的情况下响应时间也不相同。所以,在讨论一个系统的响应时间时,人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然,往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
对于单机的没有并发操作的应用系统而言,人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是,响应时间的绝对值并不能直接反映软件的性能的高低,软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说,响应时间小于100毫秒应该是不错的,响应时间在1秒左右可能属于勉强可以接受,如果响应时间达到3秒就完全难以接受了。而对于编译系统来说,完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间,但这些响应时间对于用户来说都是可以接受的。
2. 吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言,吞吐量与响应时间成严格的反比关系,实际上此时吞吐量就是响应时间的倒数。前面已经说过,对于单用户的系统,响应时间(或者系统响应时间和应用延迟时间)可以很好地度量系统的性能,但对于并发系统,通常需要用吞吐量作为性能指标。
对于一个多用户的系统,如果只有一个用户使用时系统的平均响应时间是t,当有你n个用户使用时,每个用户看到的响应时间通常并不是n×t,而往往比n×t小很多(当然,在某些特殊情况下也可能比n×t大,甚至大很多)。这是因为处理每个请求需要用到很多资源,由于每个请求的处理过程中有许多不走难以并发执行,这导致在具体的一个时间点,所占资源往往并不多。也就是说在处理单个请求时,在每个时间点都可能有许多资源被闲置,当处理多个请求时,如果资源配置合理,每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上,不同系统的平均响应时间随用户数增加而增长的速度也不大相同,这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言,吞吐量是一个比较通用的指标,两个具有不同用户数和用户使用模式的系统,如果其最大吞吐量基本一致,则可以判断两个系统的处理能力基本一致。
3. 并发用户数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比,并发用户数是一个更直观但也更笼统的性能指标。实际上,并发用户数是一个非常不准确的指标,因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例,假设用户只有注册后才能使用,但注册用户并不是每时每刻都在使用该网站,因此具体一个时刻只有部分注册用户同时在线,在线用户就在浏览网站时会花很多时间阅读网站上的信息,因而具体一个时刻只有部分在线用户同时向系统发出请求。这样,对于网站系统我们会有三个关于用户数的统计数字:注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站,使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言,以在线用户作为性能指标更直观些,而以同时发请求用户数作为性能指标更准确些。
4. QPS每秒查询率(Query Per Second)
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,在因特网上,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec,即每秒的响应请求数,也即是最大吞吐能力。 (看来是类似于TPS,只是应用于特定场景的吞吐量)
总结
到此这篇关于吞吐量(TPS)、QPS、并发数、响应时间(RT)概念的文章就介绍到这了,更多相关吞吐量并发数响应时间内容请搜索小牛知识库以前的文章或继续浏览下面的相关文章希望大家以后多多支持小牛知识库!
我对193个示例运行了一个JMeter测试,平均响应时间为5915ms,Throghput为1.19832。 我只想知道它们到底有什么关系
我运行jmeter脚本将近一周,今天观察到一件有趣的事情。以下是场景: 概述:我正在逐渐增加应用程序的负载。在上一次测试中,我给应用程序加载了100个用户,今天我将加载增加到150个用户。 150名用户测试结果: > 与上次测试相比,请求的响应时间减少了。(这是个好兆头) 吞吐量急剧下降到上一次测试的一半,负载更少。 我的问题是: > 当我的许多请求失败时,我得到了好的响应时间吗? 注:直到100
用户:100 平均Res:2.4秒 吞吐量:10/分钟 错误%:0 通过关闭所有监听器,在非GUI模式下运行测试。Jmeter实例和应用服务器的CPU、内存利用率良好。不超过30%的使用率。
我一直在使用SpringIntegration调用RESTAPI,但是SpringIntegration默认附带的http客户端不支持连接池或可重用性,因此我定制了使用PoolighttpClientConnectionManager 但是现在Spring集成停止在我的类路径中拾取JKS文件,所以我构建了自己的SSL上下文,但是构建这个SSL上下文导致了性能的显著下降 对于100个并发线程, 使用
我得到了以下结果,吞吐量没有变化,即使我增加了线程数。 场景#1: 线程数:10 加速期:60 吞吐量:5.8/s 平均值:4025 场景#2: 线程数:20 加速期:60 吞吐量:7.8/s 平均值:5098 场景#3: 线程数:40 加速期:60 吞吐量:6.8/s 平均: 4098 我的JMeter文件包含一个单一的ThreadGroup,其中包含一个GET。 当我执行对响应时间更快(小于3
给出了jmeter为10个线程生成的摘要报告(并发请求)。 我们能否从我们为10个用户获得的报告中计算并找到50个线程的响应时间和吞吐量。我必须运行负载测试的Restapi触发电子邮件和短信通知。我想知道他们是否有办法找到大约50个线程的响应时间和吞吐量,如果我们有10个线程的报告。