吞吐量
在了解qps,tps,rt,并发数之前，首先我们应该明白一个系统的吞吐量代表什么含义，一般来说，系统吞吐量指系统的抗压，负载能力。代表一个系统每秒能承受的最大用户访问量。
一个系统的吞吐量，通常由qps，tps，并发数来决定，每个系统对这两个值都有一个相对极限值，只要某一项达到最大值，系统的吞吐量就上不去了。
qps
query per second 每秒查询数，即每秒能够响应的查询次数，注意这里的查询是指用户发出请求到服务器做出响应成功的次数，简单理解可以认为查询=请求request。每秒钟request数量
tps
transaction per second 每秒处理的事务数。一个事务是指一个客户机向服务器发送请求，然后服务器做出反应的过程。客户机在发送请求开始计时，收到服务器响应后停止计时，以此来计算使用的时间和完成事务个数。针对单接口而言，TPS可以认为等价于qps的。比如访问一个页面index.html，是一个tps。而访问index.html页面可能请求了3次服务器比如css,js,index接口，产生了三个qps
rt （平均响应时间）
response time 简单理解为系统从输入到输出的时间间隔，他代表从客户端发起请求，到服务端收到请求，并响应所有数据的时间差，一般取平均响应时间。
并发数（同时发起的数量）
简而言之，系统能同时处理的请求，事务数量。计算方式：并发数 = qps * rt。
举个栗子，假设公司每天早上9点到10点都有员工要上厕所，公司有3600个员工，平均每个员工上厕所时间为10分钟。计算一下。
qps=3600/60*60 = 1
rt = 10 * 60 = 600秒
并发数= 1 * 600 = 600
如果想要达到最好的蹲坑体验，公司需要准备600个坑位。否则上厕所就要排队等待了
性能思考
按照qps = 并发数 / rt。假设我们现在是单线程的场景。如果是单线程场景 qps=1/rt。rt =cpu time ＋ cpu wait time。是不是意味着，只要提高线程数就可以提高qps了呢。最佳线程数计算。假设cpu time是49ms,cpu wait time是200ms。
qps = 1000/249=4.01
这里200ms时间可以认为是cpu一直处于等待状态，啥也没干，理论上还是可以接受200/49=4个请求，不考虑上下文切换和其他开销的话。
可以认为总线程数是(200+49)/49=5，如果再考虑上cpu多核和利用率的问题，我们大致可以认为，最佳线程数 = rt /cpu time * cpu核心 * cpu利用率，那么最大qps公式推导为
最大线程数 = 最佳线程数*单线程qps = cpu核心*cpu利用率/cpu time
是否意味着我们只要增加cpu核心数就能无限提高qps呢
两大并行定律
阿姆达尔定律 (强调可并行部分)
1967年，针对并行处理的scalability给出了一个模型，指出使用并行处理的提速由问题的可并行的部分所决定的。我们可以简单的理解为，程序通过额外的计算资源，理论上能获得的加速值par为并行计算所占的比例，p为并行处理节点个数。
假设你想从望京去顺义，坐一辆车需要三个小时，虽然现在有三辆车，你也不能1小时到达，这里无法并行，所以par=0%，p = 3，加速比还是等于1，并没有提高速率。
古斯塔夫森定律 gustafson（强调不是简单的增加cpu核心就能增加qps）
又被称为扩展的加速比 scaled speedup，他说明处理器个数，串行比例和加速比之间的关系，只是和阿姆达尔定律侧重角度有所不同。按照阿姆达尔定律和qps计算定律。在cpu time和cpu 利用率不变的情况下，增加cpu核心数，就能增加最大qps，在par不为0时即并行的时候，增加并行数量p就能提升效率，但是实际上随着请求数量的增加，带来大量的上下文切换，gc和锁的变化。qps更高，产生对象越多，gc越频繁，cpu time和利用率都收到影响，尤其是在串行的时候，锁自旋，自适应，偏向等等也成为影响par的因素。
总结
为了提升达到最好的性能，我们需要不断的进行性能测试，调整线程池大小，找到最合适的参数来达到提高性能的目的。
