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次/秒。