TPS(Transaction per Second)定义
TPS是Transactions Per Second 的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反 应的过程。客户机在发送请求时开始计时， 收到服务器响应后结束计时，以此来计算使用的时间和完成的事务数，最终利用这些信息来估计得分。
TPS（Transaction per Second）作用
反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。描述（看到系统的TPS随着时间的变化逐渐变大，而在不到多少分钟的时候系统每秒可以处理多少个事务。这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。而在几分钟以后开始出现少量的失败事务）
TPS（Transaction per Second）局限性
- TPS（Transaction per Second）是从客户端角度审视服务器处理能力，并不是说TPS可以达到什么程度就能支持多少并发（例如一个业务100个交易，另一个业务10个交易）。
- TPS=脚本运行期间所有事务总数/脚本运行时长，如果使用集合点策略，在脚本执行前的等待时间过程中，服务器没有处理事务，那么这个时候的TPS和理想中的结果不一致。
- 限制TPS的原因：服务器本身性能、代码结构、客户端施加的压力以及网卡等。
TPS（Transaction per Second）与响应时间的关系
- TPS（Transaction per Second）和响应时间在理想状态下都是额定值。如果20个入口，并发数只有10的时候，TPS就是10，而响应时间始终都是1，说明并发不够，需要增加并发数达到TPS的峰值。
- 如果增加到100并发，则造成了线程等待，引起平均响应时间从1秒变成3秒，TPS也从20下降到9；TPS和响应时间都是单独计算出来的，两者不是互相计算出来的。
- 响应时间和TPS在宏观上是反比的关系，但是两者之间没有直接关系。
TPS（Transaction per Second）在性能测试中的作用
- 一个系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等紧密关联。单个request对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
- 系统吞吐量几个重要参数：TPS、并发数、响应时间（TPS=并发数/平均响应时间）
- 利用TPS计算系统最高日吞吐量：
- 找出系统最高TPS和日PV，这两个要素有相对比较稳定的关系。
- 通过压力测试或者经验评估，得出最高TPS，然后跟进1的关系，计算出系统最高日吞吐量。例如：B2B中文和淘宝对的客户群不一样，这两个客户群的网络行为不应用，他们之间的ＴＰＳ和ＰＶ关系比例也不一样。
- 淘宝
B）B2B中文站
B2B的TPS和PV之间的关系不同的系统不同的应用场景比例变化比较大，粗略估计在1 ： 8个小时左右的关系（09年对offerdetail的流量分析数据）。旺铺和offerdetail这两个比例相差很大，可能是因为爬虫暂的比例较高的原因导致。
在淘宝环境下，假设我们压力测试出的TPS为100，那么这个系统的日吞吐量=100*11*3600=396万
这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。
- TPS与其他性能指标的关系
TPS和并发虚拟用户数（U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运行情况下）：TPS=U_concurrent / (T_response+T_think)。
TPS（Transaction per Second）总结
- 利用并发用户数、期望响应时间，可以计算出TPS。
- TPS只是用来计算的是期望值，性能测试过程中的TPS无法单独作为性能指标。
- TPS数据范围理论值应在10-100之间，低于10和高于100都说明系统存在瓶颈点。
- 利用TPS与平均事务响应时间进行对比，可以分析事务数码对执行时间的影响。例：当压力加大，点击率/TPS曲线如果变化缓慢或者有平坦趋势，很有可能是服务器开始出现瓶颈。
- TPS是从客户端角度审视服务器处理能力，不能证明TPS可以达到什么程度就能支持多少并发，两者没有必然联系。
</div>
TPS(Transaction per Second)定义
TPS是Transactions Per Second 的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反 应的过程。客户机在发送请求时开始计时， 收到服务器响应后结束计时，以此来计算使用的时间和完成的事务数，最终利用这些信息来估计得分。
TPS（Transaction per Second）作用
反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。描述（看到系统的TPS随着时间的变化逐渐变大，而在不到多少分钟的时候系统每秒可以处理多少个事务。这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。而在几分钟以后开始出现少量的失败事务）
TPS（Transaction per Second）局限性
- TPS（Transaction per Second）是从客户端角度审视服务器处理能力，并不是说TPS可以达到什么程度就能支持多少并发（例如一个业务100个交易，另一个业务10个交易）。
- TPS=脚本运行期间所有事务总数/脚本运行时长，如果使用集合点策略，在脚本执行前的等待时间过程中，服务器没有处理事务，那么这个时候的TPS和理想中的结果不一致。
- 限制TPS的原因：服务器本身性能、代码结构、客户端施加的压力以及网卡等。
TPS（Transaction per Second）与响应时间的关系
- TPS（Transaction per Second）和响应时间在理想状态下都是额定值。如果20个入口，并发数只有10的时候，TPS就是10，而响应时间始终都是1，说明并发不够，需要增加并发数达到TPS的峰值。
- 如果增加到100并发，则造成了线程等待，引起平均响应时间从1秒变成3秒，TPS也从20下降到9；TPS和响应时间都是单独计算出来的，两者不是互相计算出来的。
- 响应时间和TPS在宏观上是反比的关系，但是两者之间没有直接关系。
TPS（Transaction per Second）在性能测试中的作用
- 一个系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等紧密关联。单个request对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
- 系统吞吐量几个重要参数：TPS、并发数、响应时间（TPS=并发数/平均响应时间）
- 利用TPS计算系统最高日吞吐量：
- 找出系统最高TPS和日PV，这两个要素有相对比较稳定的关系。
- 通过压力测试或者经验评估，得出最高TPS，然后跟进1的关系，计算出系统最高日吞吐量。例如：B2B中文和淘宝对的客户群不一样，这两个客户群的网络行为不应用，他们之间的ＴＰＳ和ＰＶ关系比例也不一样。
- 淘宝
B）B2B中文站
B2B的TPS和PV之间的关系不同的系统不同的应用场景比例变化比较大，粗略估计在1 ： 8个小时左右的关系（09年对offerdetail的流量分析数据）。旺铺和offerdetail这两个比例相差很大，可能是因为爬虫暂的比例较高的原因导致。
在淘宝环境下，假设我们压力测试出的TPS为100，那么这个系统的日吞吐量=100*11*3600=396万
这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。
- TPS与其他性能指标的关系
TPS和并发虚拟用户数（U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运行情况下）：TPS=U_concurrent / (T_response+T_think)。
TPS（Transaction per Second）总结
- 利用并发用户数、期望响应时间，可以计算出TPS。
- TPS只是用来计算的是期望值，性能测试过程中的TPS无法单独作为性能指标。
- TPS数据范围理论值应在10-100之间，低于10和高于100都说明系统存在瓶颈点。
- 利用TPS与平均事务响应时间进行对比，可以分析事务数码对执行时间的影响。例：当压力加大，点击率/TPS曲线如果变化缓慢或者有平坦趋势，很有可能是服务器开始出现瓶颈。
- TPS是从客户端角度审视服务器处理能力，不能证明TPS可以达到什么程度就能支持多少并发，两者没有必然联系。
</div>