TPS和事务响应时间的关系、计算公式(转)
TPS和事务响应时间的关系、计算公式（转）
例⼦：⼀个⾼速路有10个⼊⼝，每个⼊⼝每秒钟只能进1辆车
1、请问1秒钟最多能进⼏辆车？
TPS=10
2、每辆车需要多长时间进⾏响应？
reponse time = 1
3、改成20辆车，每秒能进⼏辆？每辆车的响应时间是多长？
TPS = 10，reponse time = 1  (10个为⼀等份，分成两等份，平均tps (10/1+10/2)/2=7.5 平均响应时间(2+1)/2=1.5
4、⼊⼝扩展到20个，每秒能进⼏辆？每辆车的响应时间是多长？
TPS = 20，reponse time = 1
5、看看，现在TPS变了，响应时间没变，TPS和响应时间有关系吗？
⽊有关系
6、如何理解？
TPS和响应时间在理想状态下都是额定值(联想运⾏⼀个压⼒测试场景来考虑)，把⼊⼝看成线程池，如果有20个⼊⼝，并发数只有10的时候，TPS就是10，⽽响应时间始终是1，说明并发数不够，需要增加并发数达到TPS的峰值。
7、同样是20个⼊⼝，如果并发数变成100的话，TPS和响应时间会怎么样呢？
并发数到100的时候，就会出现堵车，堵车了平均每个车过去的时间就长了，把100个车按照20⼀份分成5份，第5份的等待时间就是最长的，从等待开始到这个车进去，实际花费了5秒，那100辆车都过去的响应时间就是（5+4+3+2+1）/5=3，平均的TPS就是
（20/1+20/2+20/3+20/4+20/5)/5=9.13（我怎么感觉应该是100/（5+4+3+2+1）=6.67 完成的事务总数/完成事务数的时间，使⽤该⽅法计算出来的tps会稍微⼩些，可以乘以1.5倍作为当前tps）
8、由此可知，TPS和响应时间宏观上是倒数关系，但是两者实际上⽊有直接的关系的，在上例中，系统只存在20个线程，100的并发就会造成线程的等待，引起平均响应时间从1秒增加到3秒，TPS从20下降到9，TPS和响应时间都是单独计算出来的，并不是互相算出来的！
9、同样可知，在并发量保持不变的情况下，提⾼TPS的⼿段有⼏种？
A、增加线程池的数量（⼊⼝）
B、降低每辆车⼊关的时间（也就是提⾼单个线程的处理效率）
10、从TPS和response time的定义查看这2者的区别？
TPS = 在场景或者灰化步骤运⾏的每⼀秒钟中，每个事务通过、失败以及停⽌的次数
也就是说，TPS = 总的通过、失败的事务总数/整个场景的运⾏时间；
reponse time = 每个事务完成实际需要的时间/事务处理数⽬
因此，这2个东西压根就是⽊有关系的！
-------------------------------------------------------------------------
Jmeter聚合报告中的，吞吐量=完成的transaction数/完成这些transaction数所需要的时间；平均响应时间=所有响应时间的总和/完成的transaction数；失败率=失败的个数/transaction数。
二十大开始时间性能测试中TPS的另外⼀种计算⽅法：
在性能测试过程中，制定性能测试⽅案是很重要的⼀个环节，其中就会涉及⼀些指标的制定，最主要的指标是TPS（每秒处理事务数），即是⽤来衡量系统的处理能⼒的⼀个指标，其次就是响应时间。下⾯谈谈在实际的⼯作中怎么定义这两个指标：
1、TPS指标，可以在⽣产环节选前⼀年中某个交易在某⼀天的最⼤值，然后在这⼀天中按分钟为单位，列出⼀个时间分别表，取交易量最⼤的⼀分钟，然后⽤这个交易量除以60，此时就能得TPS，然后再乘以1.5倍作为当前的TPS⽬标，在第⼆年和第三年再乘以⼀个1.5或2倍。
2、响应时间，根据业务的特点进⾏定义，插表交易⼀般在3秒内。
-------------------------------------------------------------------------------
TPS，每秒钟完成的事务数
"80/20"原理：
"80/20"原理是按事情的"重要程度"编排⾏事优先次序的准则是建⽴在"重要的少数与琐碎的多数"原理的基础上。这个原理是⼗九世纪末期与⼆⼗世纪初期的意⼤利经济学家兼社会学家维弗烈度·柏瑞图所提出。它的⼤意是：在任何特定体中，重要的因⼦通常只占少数，⽽不重要的因⼦则占多数，因此只要能控制具有重要性的少数因⼦即能控制全局。这个原理经过多年的演化，已变成当今管理学界所熟
知
的"80/20"原理--即百分之⼋⼗的价值是来⾃百分之⼆⼗的因⼦，其余的百分之⼆⼗的价值则来⾃百分之⼋⼗的因⼦.
"80/20"原理对所有⼈的⼀个重要启⽰便是：避免将时间花在琐碎的多数问题上，因为就算你花了80%的时间，你也只能取得20%的成效：你应该将时间花于重要的少数问题上，因为掌握了这些重要的少数问题，你只花20%的时间，即可取得80%的成效。
在软件测试⼯作中，"80/20"原理主要应⽤于缺陷分布分析与性能测试需求分析。缺陷分布分析中，它指的是80%的BUG是在20%的程序代码中发现，这其实也就是缺陷的“集现象”。下⾯主要说说"80/20"原理在性能测试需求分析中的应⽤。
在性能测试需求分析中，"80/20"原理被这样理解：每⽇80%的业务在20%的时间内完成。例如：每年业务量集中在8个⽉，每个⽉20个⼯作⽇，每个⼯作⽇8⼩时，即每天80%的业务量在1.6个⼩时内完成。
下⾯举个实际的例⼦来看"80/20"原理的应⽤于性能测试需求分析。
去年全年处理业务约100万笔，其中，15%的业务处理中，每笔业务需对应⽤服务器提交7次请求；70
%的业务处理中，每笔业务需对应⽤服务器提交5次请求；其余15%的业务处理中，每笔业务需对应⽤服务器提交3次请求。根据以往的统计结果，每年的业务增量为15%，考虑到今后3年业务发展的需要，测试需按现有业务量得两倍进⾏。
测试强度估算⽅法如下：
每年总的请求数为（100*15%*7+100*70%*5+100*15%*3）*2=1000万次/年
每天的请求数为1000/(8个⽉*20天)=6.25万次/天
每秒的请求数为（62500*80%）/（8⼩时*20%*3600秒）=8.68次/秒
即应⽤服务器处理请求的能⼒应达到9次/秒。
PS：下⾯是性能测试的主要概念和计算公式，记录下：
⼀．系统吞度量要素：
⼀个系统的吞度量（承压能⼒）与request对CPU的消耗、外部接⼝、IO等等紧密关联。
单个reqeust 对CPU消耗越⾼，外部系统接⼝、IO影响速度越慢，系统吞吐能⼒越低，反之越⾼。
系统吞吐量⼏个重要参数：QPS（TPS）、并发数、响应时间
QPS（TPS）：每秒钟request/事务 数量
并发数： 系统同时处理的request/事务数
响应时间：  ⼀般取平均响应时间
（很多⼈经常会把并发数和TPS理解混淆）
理解了上⾯三个要素的意义之后，就能推算出它们之间的关系：
QPS（TPS）= 并发数/平均响应时间
⼀个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有⼀个相对极限值，在应⽤场景访问压⼒下，只要某⼀项达到系统最⾼值，系统的吞吐量就上不去了，如果压⼒继续增⼤，系统的吞吐量反⽽会下降，原因是系统超负荷⼯作，上下⽂切换、内存等等其它消耗导致系统性能下降。
决定系统响应时间要素
我们做项⽬要排计划，可以多⼈同时并发做多项任务，也可以⼀个⼈或者多个⼈串⾏⼯作，始终会有⼀条关键路径，这条路径就是项⽬的⼯期。
系统⼀次调⽤的响应时间跟项⽬计划⼀样，也有⼀条关键路径，这个关键路径是就是系统影响时间；
关键路径是有CPU运算、IO、外部系统响应等等组成。
⼆．系统吞吐量评估：
我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。
⽽通常境况下，我们⾯对需求，我们评估出来的出来QPS、并发数之外，还有另外⼀个维度：⽇PV。
通过观察系统的访问⽇志发现，在⽤户量很⼤的情况下，各个时间周期内的同⼀时间段的访问流量⼏乎⼀样。⽐如⼯作⽇的每天早上。只要能拿到⽇流量图和QPS我们就可以推算⽇流量。
通常的技术⽅法：
1. 出系统的最⾼TPS和⽇PV，这两个要素有相对⽐较稳定的关系（除了放假、季节性因素影响之外）
2. 通过压⼒测试或者经验预估，得出最⾼TPS，然后跟进1的关系，计算出系统最⾼的⽇吞吐量。B2B中⽂和淘宝⾯对的客户不⼀样，这两个客户的⽹络⾏为不应⽤，他们之间的TPS和PV关系⽐例也不⼀样。
A)淘宝
淘宝流量图：
系统吞吐量评估⽅法
淘宝的TPS和PV之间的关系通常为  最⾼TPS：PV⼤约为 1 : 11*3600 （相当于按最⾼TPS访问11个⼩时，这个是商品详情的场景，不同的应⽤场景会有⼀些不同）
B) B2B中⽂站
B2B的TPS和PV之间的关系不同的系统不同的应⽤场景⽐例变化⽐较⼤，粗略估计在1 : 8个⼩时左右的关系（09年对offerdetail的流量分析数据）。旺铺和offerdetail这两个⽐例相差很⼤，可能是因为爬⾍暂的⽐例较⾼的原因导致。
在淘宝环境下，假设我们压⼒测试出的TPS为100，那么这个系统的⽇吞吐量=100*11*3600=396万
这个是在简单（单⼀url）的情况下，有些页⾯，⼀个页⾯有多个request，系统的实际吞吐量还要⼩。
⽆论有⽆思考时间（T_think），测试所得的TPS值和并发虚拟⽤户数(U_concurrent)、Loadrunner读取的交易响应时间
（T_response）之间有以下关系（稳定运⾏情况下）：
TPS=U_concurrent / (T_response+T_think)。
并发数、QPS、平均响应时间三者之间关系

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。