博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
TPS分析
阅读量:5875 次
发布时间:2019-06-19

本文共 2208 字,大约阅读时间需要 7 分钟。

TPS(Transaction per Second)定义

TPS是Transactions Per Second 的缩写,也就是事务数/秒。它是结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反 应的过程。客户机在发送请求时开始计时, 收到服务器响应后结束计时,以此来计算使用的时间和完成的事务数,最终利用这些信息来估计得分。

TPSTransaction per Second)作用

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

TPSTransaction per Second)局限性

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

TPSTransaction per Second)与响应时间的关系

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

TPSTransaction per Second)在性能测试中的作用

  1. 一个系统的吞吐量(承压能力)与request对CPU的消耗、外部接口、IO等紧密关联。单个request对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高。
  2. 系统吞吐量几个重要参数:TPS、并发数、响应时间(TPS=并发数/平均响应时间)
  3. 利用TPS计算系统最高日吞吐量:
  4. 找出系统最高TPS和日PV,这两个要素有相对比较稳定的关系。
  5. 通过压力测试或者经验评估,得出最高TPS,然后跟进1的关系,计算出系统最高日吞吐量。例如:B2B中文和淘宝对的客户群不一样,这两个客户群的网络行为不应用,他们之间的TPS和PV关系比例也不一样。
  6. 淘宝

   淘宝的TPS和PV之间的关系通常为,最高TPS:PV大约为1: 11*3600(相当于按最高TPS访问11个小时,这个是商品详情的场景,不同的应用场景会有一些不同)

B)B2B中文站

B2B的TPS和PV之间的关系不同的系统不同的应用场景比例变化比较大,粗略估计在1 : 8个小时左右的关系(09年对offerdetail的流量分析数据)。旺铺和offerdetail这两个比例相差很大,可能是因为爬虫暂的比例较高的原因导致。

在淘宝环境下,假设我们压力出的TPS为100,那么这个系统的日吞吐量=100*11*3600=396万

这个是在简单(单一url)的情况下,有些页面,一个页面有多个request,系统的实际吞吐量还要小。     

  1. TPS与其他性能指标的关系

TPS和并发虚拟用户数(U_concurrent)、Loadrunner读取的交易响应时间(T_response)之间有以下关系(稳定运行情况下):TPS=U_concurrent / (T_response+T_think)。

TPSTransaction per Second)总结

  1. 利用并发用户数、期望响应时间,可以计算出TPS。
  2. TPS只是用来计算的是期望值,性能测试过程中的TPS无法单独作为性能指标。
  3. TPS数据范围理论值应在10-100之间,低于10和高于100都说明系统存在瓶颈点。
  4. 利用TPS与平均事务响应时间进行对比,可以分析事务数码对执行时间的影响。例:当压力加大,点击率/TPS曲线如果变化缓慢或者有平坦趋势,很有可能是服务器开始出现瓶颈。
  5. TPS是从客户端角度审视服务器处理能力,不能证明TPS可以达到什么程度就能支持多少并发,两者没有必然联系。
  6. 当增大系统的压力(或增加并发用户数)时,吞吐率和TPS的变化曲线呈正比变化,则系统基本稳定   
  7.  若压力增大时,吞吐率的曲线增加到一定程度后出现变化缓慢,甚至平坦,同时TPS也趋于平坦,查看系统资源使用,如果资源使用率比较高,则说明服务器硬件资源存在问题,需要拓展硬件或者优化应用。反之,则说明服务器硬件资源不存在问题,查看网络流量,估计网络带宽存在问题。    
  8. 点击率/TPS曲线出现变化缓慢或者平坦,很可能是服务器响应时间增加,观察服务器资源使用情况,确定是否是服务器问题或者应用问题

转载于:https://www.cnblogs.com/Darrenblog/p/8343145.html

你可能感兴趣的文章
[翻译]用 Puppet 搭建易管理的服务器基础架构(3)
查看>>
Android -- AudioPlayer
查看>>
Python大数据依赖包安装
查看>>
Android View.onMeasure方法的理解
查看>>
Node.js 爬虫初探
查看>>
ABP理论学习之仓储
查看>>
centos7下使用yum安装mysql
查看>>
How can I set ccshared=-fPIC while executing ./configure?
查看>>
2.移植uboot-添加2440单板,并实现NOR、NAND启动
查看>>
hadoop-2.6.5安装
查看>>
vmware虚拟机里的LINUX不能上网的原因一:虚拟网卡设置
查看>>
监控摄像机的区别和分类
查看>>
Java学习——对象和类
查看>>
ElasticSearch 组合过滤器
查看>>
HttpClient连接池的连接保持、超时和失效机制
查看>>
1-4 多文档界面处理(2)
查看>>
《Essential Linux Device Drivers》中文版第1章
查看>>
让远程传输大文件变得更快
查看>>
complex的小困惑
查看>>
十进制、十六进制、二进制的转换
查看>>