因为要写一个 slides，所以再次上网翻了下一些相关的资料，看到 TPS 的计算方法时，有点疑惑。
TPS 的意思是每秒处理的事务。
但是我看到一篇文章是这样的：
（同样是 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 秒吗？那么 TPS 不应该是 100/5=20 吗？
另外关于并发，RT 和 TPS 的关系，网上很容易看到是写着 TPS=并发数/平均响应时间。
但是根据理发店模型来看的话，这个公式好像并不成立啊...比如 1 个来理发，用时一小时，那么 TPS 为 1，并发为 1，响应时间 1.如果三个来理发，响应时间 1，并发 3（最优），TPS，是 3. 如果是 6 个用户来理发，此时进入 heavy load 区域，此时 throughput 应该是基本稳定不再大幅增长，长时间运行时必然会导致部分用户离开（出错），但是此时如果按照 TPS 的算法的话，并发数为 6，平均响应时间为 1.5，那么 TPS 应该是 4，好像并不符合理发店模型啊？
1、理想情况：公式成立情况
TPS=并发数/平均响应时间
前提是服务器处理能力足够优秀，没有任何排队的情况下，网络耗时占响应时间极小的情况下，该公式成立。
2、实际情况：
TPS 只跟服务器处理能力有关系，处理能力每秒多少，QPS 或 TPS 就是多少 (暂不考虑：因为排队导致资源紧张，导致服务处理能力下降)。
并发和 tps、响应时间是关联关系，没有固定的公式、比例关系。更多的并发只能证明可能发出更多的请求，不能证明有更多的请求成功和服务器建联。
图中数字只是为了说明，并发、TPS 并无直接联系，跟实际情况有关系。
1 楼主摘选的文章没显示出来。
2 “TPS=并发数/平均响应时间” 这个公式不是用来计算 TPS 的，只是表明了他们三者之间的影响。
比如说，100 个车在 100s 钟内通过（峰值）。那么 TPS 就是 100/100=1。因为我们采样时间是 100s。
如果增大并发量，发了 1000 个车，TPS 是 1 不变（上面假设了 1 就是峰值），那么平均响应时间必然会增大。
所以说这个公式只是表面他们之间的关系，而非具体的算式。
TPS 在服务器达到处理门限时，增加并发数 TPS 不会增加，而是响应时间会延长；服务器的处理能力没有提高的前提下 TPS 是相对固定的；
这里 100 个车，总得通过时间不应该是最后一排车通过的时间，即 5 秒吗？那么 TPS 不应该是 100/5=20 吗？
响应时间应该是获得服务器响应的时间。前 20 个车的响应时间是 1s，后面的响应时间肯定会加长。
Bianca
回复
我知道响应时间会变大，不同批次响应时间已经不一样了，但是我只是想说，现在相当于 100 个车的话，最后全部通过是 5 秒，即 5 秒处理完了 100 个事务，那么 TPS 不应该就是 100/5=20 吗？
在路上
回复
所以我的理解是 100 个车通过 20 个口子的话，需要 5 秒，TPS 极限是固定的都是 20，只是因为后面几批的车辆通过时间（响应时间）变得越来越大，从整个样本上来说，无论是 99%line，平均响应时间，都是变得越来越大的。对吧？所以我想说的是，看到的很多资料里面，tps 的算法是有问题的。是不是？
是的，TPS 是相对固定的，相信自己实践的数据，资料有的说的不完整；
得来全不费工夫
回复
你要理解 TPS 不是通过并发和响应时间来算的，虽然他们三者有一定的关系。
TPS 也就是单位时间的事务处理能力，比如一百个闸机，每台车过去要 1 秒，那么它的 TPS 就是 100，如果车辆有序通过，这个闸机的每秒通过车辆都是 100，TPS 也就是 100。
但是如果车辆越来越多，造成闸机堵塞，或者其它意外情况，会造成 TPS 降低少于 100 的情况，所以压力持续增加，TPS 会小于理想值。但是它的计算方法不是你这样算的。
雨夜狂奔
回复
我的算法和你是一样的，所以我才会有疑惑，因为看了很多帖子都是那种算法，感觉有点问题，因为无论是理发店模型还是高速口子的模型，TPS 好像算出来应该是个固定值，而对于总样本的平均/99% 等响应时间是会逐渐变大的，而跳出理想模型的话，实际中会出现 tps 衰减
TPS 的计算和平均响应时间没有关系。
我个人感觉那张经典的图比较清晰。
这个算式不太好。好多文章光贴这个算式出来，又不解释它含义，非常不负责。
如果非得强行解释这个算式的话，只能这样理解：
1）当系统处理能力没有达到峰值时：并发量和 TPS 成正比关系，增大并发量，TPS 会升高。因为系统资源没有耗尽，此时平均响应时间基本不变（实际可能略有上升）。
2）当系统资源耗尽时：此时 TPS 会维持稳定（实际可能略有下降），并发量和响应时间成正比关系，增大并发量的时候，平均响应时间一定会增大。
TPS=并发数/平均响应时间是对的
TPS=总请求数/总请求耗时。
总请求数=并发量 * 总请求耗时/平均响应时间。
华全
回复
那如果按照高速入口这个模型的话，比如 8 辆车，4 个口，那么第二排通过肯定是 2 秒，从 TPS 上来算，就是 8/2=4，这样对不对？但是从并发数/平均响应时间来算的话，这里平均响应时间是（1X4+2X4）/8=1.5 秒，按照你给出的算法的话，那么并发难道是 8/1.5？
得来全不费工夫
回复
并发是 TPS* 平均响应时间，2*1.5 =3 啊。
并发 3 是意味着一直保持有三辆车在过闸口。
要是你说一共只有 8 量车，那并发量其实是根据时间在递减的。
你想啊，过了 1 秒后，还剩 4 量车，这时候并发还是 8 么？
得来全不费工夫
回复
感觉你的视角有问题，要测路口，关注的只是这个条路每秒能过几辆车。 每辆用时多久。
并发数只是用来保证这条路是饱和的，每个口子都有车在过。四个口子的话只要保持 4 的并发即可。
就算加到一万辆车一起过，除了在过口子的车，其他车都是无效的压力。因为对于四个口子的路口来说他们当前也只承受了 4 个并发而已，后面的车他们感知不到的。
只有这条路有 1W 个口子可以并排开过 1W 辆车的时候，并发才算是 1W
华全
回复
其实我的想法是，假设车子十秒还没通过口子，就不可接受（类似于系统的响应时间限制），这种情况下，就好知道最大可以承受多少并发吧？虽然对于入口来说他只能承受 4 个车通过，但是对于整个高速系统来说，他是可以接受线程在排队的
那到底哪个是正确的呢
恒温
回复
我问了不同的人，答案都是不同...但是 Stack Overflow 上回答也是 TPS=并发数/响应时间，只是这里的响应时间指的是所有 threads 经历完的时间段，还是平均响应时间，并没有指出。
我觉得吧，括号里的 2 个计算没有太多意义，尤其是第 2 个；
TPS=并发数/响应时间，这个在没有到峰值时，是正确的，不管是总的响应时间还是平均响应时间，因为它是同一个值；
当我们知道峰值 TPS 的时候，在去用这个公式，显然没有太大意义，可能这时更多应该关注的是平均响应时间
得来全不费工夫
回复
对于你说的 100/5，我认为仅限于第 1s 的并发（或者说第一轮的并发，假如 100/s 的话，第 1 个 100 是 5s，第 2 个 100 是 9s，依次 +4），因为此时已经超过峰值，这样算出来的值应该就是最大的 TPS，然而现实中，做性能测试应该也不会这么（仅设 1 轮）去设置吧；像 #11 所说，还是应该理解每个值代表的意义，他们之间的影响关系
首先：
tps=每秒业务处理量=业务并发
你们讨论的线程并发是工具层产生的数据没有什么实际意义。
其次：
一般性能测试工具每个线程都是阻塞模型，一次 res 后才会进行下一次 req，所以得到的数据必然是
- 请求数量=测试并发线程/响应时间
最后：
如果调整策略 每秒固定请求个 req，在测试线程里使用异步接收 res 话你就会发现你所谓的公式不对了。
得来全不费工夫
回复
你连工具的实现都没弄明白吗？主流工具哪个不是阻塞模型？
我说的模型是内部的执行逻辑不是你的测试模型，至于工具层为什么这么设计 要细讲就要写一大篇了。
你只要明白性能测试 目标是找出 tps 峰值 并找出瓶颈点就行了，往这个目标做多半不会出差错，而新手性能人员的目标往往是压垮服务器，然后研究研究着就整歪了
心向东
回复
工具我知道目前都是阻塞的，没记错的国产有个麒麟还是什么名字的说是实现不一样。但是这里没有说工具，而是单指网上摘抄的例子里举得模型里，理想状态下他的 tps 是哪种算法？全部线程数/总时间，还是全部线程数（这个场景下的并发数）/平均响应时间
得来全不费工夫
回复
我在解释最后一遍 所谓公式：tps=并发线程/响应时间 中的 tps 是指 工具这边每秒发出的 req 的数量，如果工具的线程是阻塞型的那么这个 req 的 tps==服务器的处理能力 res 。
如果工具是非阻塞型的线程 每秒固定发出 xxx 个 req 的话 如果服务器处理不过来 你觉得服务器的处理能力等于你的请求数量吗
心向东
回复
所以在这个模型里面，入口就是服务端处理啊，已经限制了口子数和处理速度了，所以这个应该是固定的，而来车子多少只是 client 端的请求数
得来全不费工夫
回复
....你觉得你都测试到峰值了 你会拿不到 response time 吗？？我说的是测试目标 不是测试结果 讨论问题能不能在一个层次
得来全不费工夫
回复
我的意思是把 tps 数据和线程中的并发扯到一起本来就是错误的行为会误导新人，而这个公式实际是计算美妙请求数的 ，在大多数时候恰好等于 tps。所以讨论这个公式没有意义，只要把每个数据是什么怎么来的弄清楚自然没有问题了
1、理想情况：公式成立情况
TPS=并发数/平均响应时间
前提是服务器处理能力足够优秀，没有任何排队的情况下，网络耗时占响应时间极小的情况下，该公式成立。
2、实际情况：
TPS 只跟服务器处理能力有关系，处理能力每秒多少，QPS 或 TPS 就是多少 (暂不考虑：因为排队导致资源紧张，导致服务处理能力下降)。
并发和 tps、响应时间是关联关系，没有固定的公式、比例关系。更多的并发只能证明可能发出更多的请求，不能证明有更多的请求成功和服务器建联。
图中数字只是为了说明，并发、TPS 并无直接联系，跟实际情况有关系。
