QPS、TPS、RT、并发数、吞吐量理解和性能优化深入思考

吞吐量

在了解qps、tps、rt、并发数之前，首先我们应该明确一个系统的吞吐量到底代表什么含义，一般来说，系统吞吐量指的是系统的抗压、负载能力，代表一个系统每秒钟能承受的最大用户访问量。

一个系统的吞吐量通常由qps（tps）、并发数来决定，每个系统对这两个值都有一个相对极限值，只要某一项达到最大值，系统的吞吐量就上不去了。

QPS

Queries Per Second，每秒查询数，即是每秒能够响应的查询次数，注意这里的查询是指用户发出请求到服务器做出响应成功的次数，简单理解可以认为查询=请求request。

qps=每秒钟request数量

TPS

Transactions Per Second 的缩写，每秒处理的事务数。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

针对单接口而言，TPS可以认为是等价于QPS的，比如访问一个页面/index.html，是一个TPS，而访问/index.html页面可能请求了3次服务器比如css、js、index接口，产生了3个QPS。

tps=每秒钟事务数量

RT

Response Time缩写，简单理解为系统从输入到输出的时间间隔，宽泛的来说，他代表从客户端发起请求到服务端接受到请求并响应所有数据的时间差。一般取平均响应时间。

并发数

简而言之，系统能同时处理的请求/事务数量。

计算方式

QPS=并发数/RT 或者 并发数=QPS*RT

举个栗子：

假设公司每天早上9点到10点1个小时内都有员工要上厕所，公司有3600个员工，平均每个员工上厕所时间为10分钟，我们来计算一下。

QPS = 3600/60*60 1

RT = 10*60 600秒

并发数 = 1 * 600 600

这样就意味着如果想达到最好的蹲坑体验，公司需要600个坑位来满足员工需求，否则的话上厕所就要排队等待了。

性能思考

按照QPS=并发数/RT公式，假设我们现在是单线程的场景，那么QPS公式应该是这样：QPS=1/RT，实际上RT应该=CPU time + CPU wait time，如果将线程数提高到2，那么QPS=2/(CPU time + CPU wait time)，那么是否意味着我们只要单纯提高线程数就能提高QPS呢？

最佳线程数计算

假设CPU time是49ms，CPU wait time是200ms，那么QPS=1000ms/249ms=4.01，这里200ms的wait时间我们可以认为CPU一直处于等待状态啥也没干，理论上来说200ms还可以接受200/49≈4个请求，不考虑上下文切换和其他开销的话，可以认为总线程数=(200+49)/49=5，如果再考虑上CPU多核和利用率的问题，我们大致可以认为：最佳线程数=RT/CPUTime * CPU核心数 * CPU利用率

那么最大QPS公式推导为：

最大QPS=最佳线程数*单线程QPS=（RT/CPU Time * CPU核心数 * CPU利用率）*（1/RT) = CPU核心数*CPU利用率/CPUTime

那么这样是否意味着我们只要不停增加CPU核心数就能无限提高QPS呢？

阿姆达尔定律Amdahl

G.M.Amdahl在1967年提出了Amdahl’s law，针对并行处理的scalability给出了一个模型，指出使用并行处理的提速由问题的可并行的部分所决定。我们可以简单理解为程序通过额外的计算资源，理论上能获得的加速值。

par为并行计算所占的比例，p为并行处理节点个数

假设你想从望京去顺义，坐一辆车需要3小时，虽然现在有3辆车，你也不能1小时就到。这里无法并行，所有Par=0%，p=3，加速比还是等于1，并没有提高速度。

古斯塔夫森定律Gustafson

斯塔夫森定律又被称为扩展的加速比(scaled speedup)，他说明处理器个数、串行比例和加速比之间的关系，只是和阿姆达尔定律侧重角度有所不同。

按照阿姆达尔定律和QPS计算公式，在CPUtime 和 CPU利用率不变的情况下，增加CPU核心数就能增加最大QPS，在par不为0即并行的时候，增加并行数量p就能提升效率，但是实际上随着请求数量的增加，带来大量的上下文的切换、gc和锁变化。qps更高，产生对象越多，gc越频繁，cpu time和利用率都受到影响，尤其在串行的时候，锁自旋、自适应、偏向等等也成为影响par的因素。

总结，为了提升达到最好的性能，我们需要不断的进行性能测试，调整小城池大小，找到最合适的参数来达到提高性能的目的。

参考： http://javahao123.com/?p=772 https://cloud.tencent.com/developer/article/1106559 https://www.cnblogs.com/caishunzhe/p/13056105.html https://www.jianshu.com/p/8532ac88ce72 https://zhuanlan.zhihu.com/p/66929848 https://www.cnblogs.com/lupeng2010/p/12705795.html