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个小时，这个是商品详情的场景，不同的应用场景会有一些不同）
- B2B中文站
B2B的TPS和PV之间的关系不同的系统不同的应用场景比例变化比较大，粗略估计在1 : 8个小时左右的关系（09年对offerdetail的流量分析数据）。旺铺和offerdetail这两个比例相差很大，可能是因为爬虫暂的比例较高的原因导致。
在淘宝环境下，假设我们压力测试出的TPS为100，那么这个系统的日吞吐量=100113600=396万
这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。
无论有无思考时间（T_think），测试所得的TPS值和并发虚拟用户数(U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运行情况下）：
TPS=U_concurrent / (T_response+T_think)。
并发数、QPS、平均响应时间三者之间关系
系统吞吐量评估方法
来源：http://www.cnblogs.com/jackei/
软件性能测试的基本概念和计算公式
一、软件性能的关注点
对一个软件做性能测试时需要关注那些性能呢？
我们想想在软件设计、部署、使用、维护中一共有哪些角色的参与，然后再考虑这些角色各自关注的性能点是什么，作为一个软件性能测试工程师，我们又该关注什么？
首先，开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。
对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间，当相应时间较小时，用户体验是很好的，当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。
用户关注的是用户操作的相应时间。
其次，我们站在管理员的角度考虑需要关注的性能点。
1、 相应时间
2、 服务器资源使用情况是否合理
3、 应用服务器和数据库资源使用是否合理
4、 系统能否实现扩展
5、 系统最多支持多少用户访问、系统最大业务处理量是多少
6、 系统性能可能存在的瓶颈在哪里
7、 更换那些设备可以提高性能
8、 系统能否支持7×24小时的业务访问
再次，站在开发（设计）人员角度去考虑。
1、 架构设计是否合理
2、 数据库设计是否合理
3、 代码是否存在性能方面的问题
4、 系统中是否有不合理的内存使用方式
5、 系统中是否存在不合理的线程同步方式
6、 系统中是否存在不合理的资源竞争
那么站在性能测试工程师的角度，我们要关注什么呢？
一句话，我们要关注以上所有的性能点。
二、软件性能的几个主要术语
1、响应时间：对请求作出响应所需要的时间
网络传输时间：N1+N2+N3+N4
应用服务器处理时间：A1+A3
数据库服务器处理时间：A2
响应时间=N1+N2+N3+N4+A1+A3+A2
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表示性能测试所用的时间
4、性能计数器
是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。
资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。
5、思考时间的计算公式
Think
Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。
在吞吐量这个公式中F=VU * R /
T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数，而其中的R又可以用时间T和用户思考时间TS来计算：R
= T / TS
下面给出一个计算思考时间的一般步骤：
A、首先计算出系统的并发用户数
C=nL / T F=R×C
B、统计出系统平均的吞吐量
F=VU * R / T R×C = VU * R / T
C、统计出平均每个用户发出的请求数量
R=u*C*T/VU
D、根据公式计算出思考时间
TS=T/R