大佬可以，我也沉淀了这些内容，用来给新人培训用

thoughtworks 年度技术雷达里面也提及过这个，说推荐

都报 500 了。。。看下代码咯

登录

哎...感觉相互没在一个频道上啊...

response time 啊

所以在这个模型里面，入口就是服务端处理啊，已经限制了口子数和处理速度了，所以这个应该是固定的，而来车子多少只是 client 端的请求数

另外不应该只是找出 tps 峰值，最终的结果没法抛开可接受的 RT 来谈 tps

工具我知道目前都是阻塞的，没记错的国产有个麒麟还是什么名字的说是实现不一样。但是这里没有说工具，而是单指网上摘抄的例子里举得模型里，理想状态下他的 tps 是哪种算法？全部线程数/总时间，还是全部线程数（这个场景下的并发数）/平均响应时间

但是在模型中实际上是没有在考虑阻塞，不需要等前车 res 啊？愿闻其详

摘抄自网上的资料，第二个算法我觉得是不对的

我问了不同的人，答案都是不同...但是 Stack Overflow 上回答也是 TPS=并发数/响应时间，只是这里的响应时间指的是所有 threads 经历完的时间段，还是平均响应时间，并没有指出。

其实我的想法是，假设车子十秒还没通过口子，就不可接受（类似于系统的响应时间限制），这种情况下，就好知道最大可以承受多少并发吧？虽然对于入口来说他只能承受 4 个车通过，但是对于整个高速系统来说，他是可以接受线程在排队的

4 个口子啊，8 辆车通过的话第二批需要 2 秒，总的时间就是 2 秒，而线程数有 8，那么就是 8/2=4 啊

TPS 是 4，并发应该是 6，但是这里不太对吧？从 11 楼的图上来看，不线性

gatling 加 grafana 也是美的很

那如果按照高速入口这个模型的话，比如 8 辆车，4 个口，那么第二排通过肯定是 2 秒，从 TPS 上来算，就是 8/2=4，这样对不对？但是从并发数/平均响应时间来算的话，这里平均响应时间是（1X4+2X4）/8=1.5 秒，按照你给出的算法的话，那么并发难道是 8/1.5？

这个图知道的，所以才对网上看到的各种公式有疑问

多谢

我的算法和你是一样的，所以我才会有疑惑，因为看了很多帖子都是那种算法，感觉有点问题，因为无论是理发店模型还是高速口子的模型，TPS 好像算出来应该是个固定值，而对于总样本的平均/99% 等响应时间是会逐渐变大的，而跳出理想模型的话，实际中会出现 tps 衰减

所以我的理解是 100 个车通过 20 个口子的话，需要 5 秒，TPS 极限是固定的都是 20，只是因为后面几批的车辆通过时间（响应时间）变得越来越大，从整个样本上来说，无论是 99%line，平均响应时间，都是变得越来越大的。对吧？所以我想说的是，看到的很多资料里面，tps 的算法是有问题的。是不是？

我知道响应时间会变大，不同批次响应时间已经不一样了，但是我只是想说，现在相当于 100 个车的话，最后全部通过是 5 秒，即 5 秒处理完了 100 个事务，那么 TPS 不应该就是 100/5=20 吗？

就是那个括号里面的内容，就是摘抄的文章的，所以上面那个例子里，TPS 的算法是对的吗？

被 google 评价为可能是最好的游戏 app 自动化测试工具，牛逼的

postman+newman+jenkins
当然啦，其实 python 的 requests 库也很好写