每秒能完成的事务数越多，那么每分钟能完成的事务就越多，每天完成的事务数就越多 --
那么他直接能影响到一个应用服务每天平均能承受的访问量/请求量，以及业务高峰期能承受的压力。
平均响应时间：那么有哪些因素会影响到TPS数值？
有两个主要的维度：
单个事务响应速度
同一时间能并行执行的事务
第二点我们说了，它主要跟服务器资源配置，线程池容量，线程调度等相关。
第一点换一个说法就是：事务平均响应时间。单个事务平均下来完成的速度越快，那么单位时间内能完成的事务数就越多，TPS就越高 --
所以在进行性能调优时，除了服务器容量资源，单个事务响应速度是另一个关注的重点。
要关注事务响应速度/时间，可以考虑在事务内部逻辑节点添加“耗时探针”的方式，来探测每个步骤分别花费的时间，从而找出可优化的部分。
吞吐量
吞吐量
简单的结论就是，吞吐量是站在“量”的角度去度量，是一个参考指标。
但是光有“量”的数据有时候并无太大价值，一家餐厅1个小时卖出100份餐品和一个月才卖出100份餐品，单从“量”的维度衡量肯定不行，时间维度很重要！
所以，性能测试领域的吞吐量通常会结合上时间维度进行统计。
如果吞吐量的“量”以“事务”为统计单位的话，结合时间维度，转化以后可以很容换算成TPS。
4. 最后，关于性能测试的一些碎碎念
测试类型
由于测试目标的不同，性能测试可能存在很多种形式。
比如明确了解日访问量和巅峰访问量，测试服务器是否能够承受响应压力的测试。
比如用于探测系统负载极限和性能拐点的测试。
比如衡量系统在高负载情况下，长时间运行是否稳定的测试。
这许多种形式我们暂且不做讨论，不过所有以上测试的基础都是它 -- “并发测试”。
制造并发，是性能测试的基本实现办法。
进一步细化理解客户端线程数和并发量的关系设服务器并发能力为每秒完成1个事务，即TPS=1/s。且服务器使用单核处理器，现用Jmeter启动5个线程循环进行并发测试，那么每个切片时间（每秒）都发生了什么？
我们可以用如下图表来分析：
其中，
假设其他条件不变，增加服务器并行处理数为2（增加CPU核数为2，以及合理的线程调度机制）那么变为：
这里真实的并发数（服务器单位时间完成的事务数）就是图中每一秒钟完成的事务数。
而客户端启动的其他未处理的线程则在“排队等待”。
线程并发数量那么制造多少并发，换言之，我应该用多少并发线程数去进行测试？
实际上客户端发起的线程数与服务器可达到的并发数并无直接关系，但你应该使用足够的线程数，让服务器达到事务饱和。