学习记录:jmeter添加jp@gc - Transactions per Second性能测试指标TPS

78 阅读 0 评论 52 点赞

我是靠谱客的博主仁爱帆布鞋，最近开发中收集的这篇文章主要介绍学习记录:jmeter添加jp@gc - Transactions per Second性能测试指标TPS，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

#TPS(Transaction Per Second) :每秒事务数，通常指每秒成功的事务数，性能测试中重要的综合性性能指标，代表着服务器的处理能力。一个事务是一个业务度量单位，有时一个事务会包括多个子操作，为了统计方便，会把着多个子操作记为一个事务。

普通视图
在这里插入图片描述 监听动态TPS，用来分析吞吐量。其中横坐标是运行时间，纵坐标是TPS值。

聚合视图
在这里插入图片描述

****转https://www.cnblogs.com/Lydia25/p/10194333.html

TPS（Transaction per Second）定义：
　　tps是Transaction per Second的缩写，也就是事物数/秒。它是软件测试结果的测量单位，一个事物是指一个客户机向服务器发送请求饭后服务器做出反应的过程。
　　客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用时间和完成的事物数，最终利用这些信息来估计得分。

TPS（Transaction per Second）作用：
　　反映了系统在同一时间内处理业务的最大能力，这个数据越高，说明处理能力越强，描述（看到系统的TPS随着时间的变化逐渐变大，而在不到多少分钟的时候系统
　　每秒可以处理多少个事物。这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。）
　　而在几分钟以后开始出现少量的失败事物）

TPS（Transaction per Second）局限性：
　　1、tps是从客户端角度审视服务器处理能力，并不是说TPS可以达到什么程度就能支持多少并发（例如：一个业务100个交易，另一个业务10个交易）。
　　2、TPS = 脚本运行期间所有事物总数 / 脚本运行时长，如果使用集合点策略，在脚本执行前的等待时间过程中，服务器没有处理事务，那么这个时候的TPS和理想中的结果不一致。
　　3、限制TPS的原因：服务器本身性能、代码结构、客户端施加的压力以及网卡等。

TPS（Transaction per Second）与响应时间的关系：
　　1、TPS和响应时间在理想状态下的额定值。如果20个入口，并发数只有10的时候，TPS就是10，而响应时间始终都是1，说明并发不够，需要增加并发数达到TPS的峰值。
　　2、如果增加到100并发，则造成了线程等待，引起平均响应时间从 1 秒变成 3 秒，TPS也从20下降到9；TPS和响应时间都是单独计算出来的，两者不是互相计算出来的。
　　3、响应时间和TPS在宏观上是反比的关系，但是两者之间没有直接关系。

TPS（Transaction per Second）在性能测试中的作用：
　　1、一个系统的吞吐量（承压能力）与request 对CPU的消耗、外部接口、IO等紧密关联。单个request对CPU消耗越高，外部系统接口、IO营销速度越慢，系统吞吐能力越低，反之越高。
　　2、系统吞吐量几个重要参数：TPS、并发数、响应时间（TPS = 并发数 / 平均响应时间）
　　3、利用TPS计算系统最高日吞吐量；
　　4、找出系统最高TPS和日PV，这两个要素有相对比较稳定的关系。
　　5、通过压力测试或者经营评估，得出最高TPS，然后跟进1的关系，计算出系统最高日吞吐量。例如：B2B中文和淘宝对客户群不一样，这两个客户群的网络行为不应用，他们之间的TPS
　　和PV关系比例也不一样。
　　6、淘宝
　　A)淘宝的TPS和PV之间关系通常为，最高TPS:PV大约为 1:113600（相当于按最高的TPS访问11个小时，这个是商品详情的场景，不同的应用场景会有一些不同）B2B中文站
　　B)B2B的TPS和PV之间的关系不同的系统不同的应用场景比例变化比较大，粗略估计在1:8个小时左右的关系（09年对offerdateil的流量分析数据）。旺铺和offerdetail这两个比例相差很大，
　　可能是因为爬虫占得比例比较高的原因导致的。
　　在淘宝环境下，假设我们压力测试出的TPS为100，那么这个系统的日吞吐量=10011*3600=396万
　　这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。

TPS（Transaction per Second）与其他性能指标的关系：
　　TPS和并发虚拟用户数（U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运行情况下）：TPS=U_concurrent / (T_response+T_think)。

TPS（Transaction per Second）总结：
　　1、利用并发用户数、期望响应时间，可以计算出TPS。
　　2、TPS只是用来计算的是期望值，性能测试过程中的TPS无法单独作为性能指标。
　　3、TPS数据方位理论值赢在10-100之间，低于10和高于100都说明系统存在瓶颈点。
　　4、利用TPS与平均事物响应时间进行对比，可以分析事物数码对执行时间的影响。例：当压力加大，点击率/tps曲线如果变化缓慢或者有平坦趋势，很有可能是服务器开始出现瓶颈。
　　5、TPS是从客户端角度审视服务器处理能力，不能证明TPS可以达到什么程度就能支持多少并发，两者没有必然联系。
　　6、TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。