性能测试TPS、响应时间和最佳线程数的实践

看了一篇梳理TPS、RT、Concurrent之间关系的文章，总结的不错，把其中的一些要点提出来，便于后续性能测试结果分析：

关于TPS和响应时间的关系，对于大部分应用来说，响应时间一般由CPU执行时间，线程等待时间(IO等待，sleep和wait)组成，表面上看，TPS应该和RT是反比的关系，但是实际上则不是。

减少响应时间，并不能有效的提升TPS；
如果要提升服务器端的响应时间，减少IO时间能达到最佳效果；如果要提升TPS，采用优化CPU时间能达到最佳优化效果。

回到之前做应用服务优化的地方，改变了取数据的方式（注：从内存取，之前是从磁盘取），只是减少了IO时间，但是并没有使CPU的时间得到大规模减少，所以瓶颈依然存在，TPS并没有提升太多；但是改变了异步存消息的方式，使异步的线程的时间减少，在压测时，CPU的时间得到了成倍的释放，因此最佳并发线程数得到了提升，TPS得到大幅度提升，而由于是两个消息处理都是异步操作，对整体的响应时间，影响很小。

在软件测试中对并发如何处理和理解呢？受应用系统本身和网络延时的影响，绝对意义上的并发是没有的。 比如在实际应用中用户端向服务器同时发送相同的100个请求。由于网络传输延时的不等因素到底服务器时就不一定是100个请求同时落地。如果我们是想通过压力机模拟100个用户的请求，模拟器本身需要创建100个线程来实现100个并发请求。但目前的计算机还只能做到同步创建线程， 即使在客户端通过设置集合点的方式将100个请求同时提交，经过网络上的传输消耗，可能它们并不是同时到达，而即便100个请求同时到达服务器端，受到中间件和应用系统、数据库的各种连接池、缓冲区， CPU处理队列等的限制，也可能在服务器端产生等待。那么如何做到保证并发呢。这样看具体的业务或者操作了。如果是测试某个方法或者功能的是否存在并发性能问题，用模拟软件中的集合点可以满足需要。如果是涉及到业务的并发能了，那么集合点并不适用。只要对业务的场景设计合理就好了。另外，想知道某时刻的并发，可以通过压测工具进行实施监控，逐渐增加并发用户达到实时的并发。 如果是测试DB，可以通过监控DB的session得到并发数量。

其实我整理一下就是两个要点：
1.RT与CPU执行时间、线程等待时间有关（+网络传输时间）；
RT = Thread CPU Time + Thread Wait Time
2.TPS与RT不成反比关系，优化CPU处理时间可以有效提升TPS；