tps

PS：下面是性能测试的主要概念和计算公式，记录下： 一．系统吞度量要素： 一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。 单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。 系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间 QPS（TPS）： 每秒钟request/事务 数量 并发数： 系统同时处理的request/事务数 响应时间： 一般取平均响应时间 （很多人经常会把并发数和TPS理解混淆） 理解了上面三个要素的意义之后，就能推算出它们之间的关系： QPS（TPS）= 并发数/平均响应时间 一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。 决定系统响应时间要素 我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。 系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间； 关键路径是有CPU运算、IO、外部系统响应等等组成。 二．系统吞吐量评估：

PS：下面是性能测试的主要概念和计算公式，记录下： 一．系统吞度量要素： 一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。 单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。 系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间 QPS（TPS）： 每秒钟request/事务 数量 并发数： 系统同时处理的request/事务数 响应时间： 一般取平均响应时间 （很多人经常会把并发数和TPS理解混淆） 理解了上面三个要素的意义之后，就能推算出它们之间的关系： QPS（TPS）= 并发数/平均响应时间 一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。 决定系统响应时间要素 我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。 系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间； 关键路径是有CPU运算、IO、外部系统响应等等组成。 二．系统吞吐量评估：

PS：下面是性能测试的主要概念和计算公式，记录下： 一．系统吞度量要素： 一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。 系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间 QPS（TPS）：每秒钟request/事务 数量 并发数： 系统同时处理的request/事务数 响应时间： 一般取平均响应时间 （很多人经常会把并发数和TPS理解混淆） 理解了上面三个要素的意义之后，就能推算出它们之间的关系： QPS（TPS）= 并发数/平均响应时间 或者 并发数 = QPS*平均响应时间 一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。 QPS = 1000/(30*60) 事务/秒 平均响应时间为 = 5*60 秒 并发数= QPS*平均响应时间 = 1000/(30*60) *(5*60)=166.7 一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降

我们在日常工作中经常会听到QPS/TPS这些名词，也会经常被别人问起说你的系统吞吐量有多大。这个问题从业务上来讲，可以理解为应用系统每秒钟最大能接受的用户访问量。或者每秒钟最大能处理的请求数； QPS: 每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。 TPS：每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多。 并发量：系统能同时处理的请求数 RT：响应时间，处理一次请求所需要的平均处理时间 计算关系： QPS = 并发量 / 平均响应时间 并发量 = QPS * 平均响应时间 来源： oschina 链接： https://my.oschina.net/u/3101476/blog/1625454

一、PV/UV/IP 1.1 名词解释 PV (Page View) 页面浏览量 用户每一次对网站中的每个页面访问均被记录1次。 用户对同一页面的多次刷新，访问量累计。 UV (Unique Visitor) 独立访客 通过访问电脑的cookies实现。 IP 通过访问电脑的ip实现。 1.2 UV、IP的区别 1. 比如你是ADSL拨号上网，拨一次号自动分配一个IP，进入了网站，就算一个IP；断线了而没清理Cookies，又拨号一次自动分配一个IP，又进入了同一个网站，又统计到一个IP，这时统计数据里IP就显示统计了2次。UV没有变，是1次。 2. 同一个局域网内2个人，在2台电脑上访问同一个网站，他们的公网IP是相同的。IP就是1，但UV是2。 二、QPS/TPS QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。 TPS：TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。 一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息来估计得分。客户机使用加权协函数平均方法来计算客户机的得分

在线用户数：用户同时在一定时间段的在线数量 并发用户数：某一时刻同时向服务器发送请求的用户数 一般而言，我们习惯以5-20的比率来推算并发用户与在线用户之间的关系。即，并发与在线的比例约为5%-20% 比如，某网站存在注册用户数为10W人，但同时在线最多1W人，但这1W个人，可能只有500人会浏览帖子，500人会进行发帖，只有这1000个人对服务器才有交易，那我们计算并发量的时候，就可以以1000为标准！ ----------------------------------------------------------------------------------------------------------------------------- 昨天读完了段念写的《软件性能测试过程详解与案例剖析》一书的第一章，感觉学到了不少东西，以下将该书中的我认为是精华的一篇过来给大家一起看看： 在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。 假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到

PS：下面是性能测试的主要概念和计算公式，记录下： 一．系统吞度量要素： 一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。 单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。 系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间 QPS（TPS）： 每秒钟request/事务 数量 并发数： 系统同时处理的request/事务数 响应时间： 一般取平均响应时间 （很多人经常会把并发数和TPS理解混淆） 理解了上面三个要素的意义之后，就能推算出它们之间的关系： QPS（TPS）= 并发数/平均响应时间 一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。 决定系统响应时间要素 我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。 系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间； 关键路径是有CPU运算、IO、外部系统响应等等组成。 二．系统吞吐量评估：

iostat 是I/O statistics（输入/输出统计）缩写iostat工具将对系统磁磁盘活动进行监视iostat属于sysstat软件包可以用yum install sysstat 直接安装。 命令参数： -C 显示CPU使用情况 -d 显示磁盘使用情况 -k 以KB为单位显示 -m 以M为单位显示 -N 显示磁盘阵列（LVM）信息 -n 显示NFS使用情况 -p 显示磁盘和分区的情况 -t 显示终端和CPU的信息 -x 显示详细信息 -V 显示版本信息 使用实例： 1)显示所有设备负载情况 iostat [root@natasha etc]# iostat Linux 2.6.32-431.el6.i686 (natasha) 11/24/2015 _i686_ (4 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 0.01 0.13 0.45 1.04 0.00 98.37 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda 7.91 253.69 221.92 1740248 1522344 scd0 0.01 0.05 0.00 360 0 dm-0 35.80 249.51 221.89 1711602 1522160 dm-1 0.05 0

1.性能评估模型概述 我们的系统性能到底能不能够支撑线上真实大量的订单交易？ 我想，这是我们每一个互联网交易或者负责大并发项目的同学都很关心的问题，也是性能评估模型篇需要解答的最终问题。所以我们就带着这个问题来一步步深入性能测试。本问题的难度不在于一个简单的结果，而在于答案背后的一系列性能测试的评估数据和算法，以及如何建立一个良好可持续的“性能评估模型”。 通常来讲，性能测试是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。 而要回答“能否支撑线上真实 大量的订单交易 ”这样带有预测性的问题，实际上还需要用上另一种手段，即“ 性能预测 ”，而“在线性能评估模型”就是用来做性能预测的。 在预测之前，我们先来做一个数据分析，通过这个分析我们可以大概了解线上与线下的推算过程。 2013年11月11日，支付宝实现了当天交易总金额 350 亿元 ，订单总数 1.8 亿笔 （其中手机支付占24%），活跃用户 1.2 亿 。（来源：支付宝官方微博 http://weibo.com/1627897870/AiiAjEwHO ） 显然这是一个非常震惊的数字，它见证着电商的今天也预示着电商的未来。针对这个数字，下面我们就一起来剖析数字背后的性能情况。 双11当天，支付宝的订单数是1.8亿笔，意味着每小时订单数达到1.8亿 / 24 = 750万笔

近来我有在和SimpleChain团队的大佬交流一些提升公链效率的方案，感到受益匪浅。 我作为一名区块链爱好者，先前对于项目提升tps的方案也有所了解，大多采用的是分片技术、先进的共识、压缩区块等，平时和非从业人员交流的时候也能说上一些。但是，这次SimpleChain的同学却给我介绍了不同的角度。 举例来说，一个公链如果已经选好了共识，为了去提升tps而改共识就比较困难，同样，引入分片等技术开发周期较长。那么这种情况下，或许就可以从一些更小的地方进行调优。比如区块的大小。区块大，一次发送的交易就多，但同时传送也慢。这就需要开发人员耐心调试，来找到这个最优点。再比如，一些api、消息传输的接口可以通过优化来缩减，减少消息传输的大小等等。 当然，除此之外还有很多其他的方案。我还听说他们在申请相关专利，可以说是很厉害了。 不论是从大家关心的币价角度还是从团队的靠谱程度上，SimpleChain都表现很好，一直没有让大家失望。我个人会一直关注这个团队，持续看好！ 来源： https://www.cnblogs.com/simplechain/p/11640395.html