性能常用指标_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
性能常用指标
阅读已结束，下载文档到电脑
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，方便使用
还剩2页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢Google Chrome 23.0.1271.95
Windows 7关于你上面描述的
“ 并发数： 系统同时处理的request/事务数”
我觉得这也是很模糊的
所谓“同时处理的”
也应该有个单位时间啊
或者是平均值
“并发 PV QPS 吞吐量”等等描述和换算
网上有很多的说法
Google Chrome 27.0.1453.94
Windows 7 x64 Edition写的挺全面，了解了不少
Google Chrome 30.0.
Windows 7 x64 Edition同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数+平均用户思考时间
这个公式怎么看着这么蹊跷呢？是不是什么地方错了？能否给解释一下。
Google Chrome 30.0.
Windows 7 x64 Edition同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数/平均用户思考时间
应该是这样吧？
Windows 7 x64 EditionTPS和并发数关系应该有问题吧。 按照QPS（TPS）= 并发数/平均响应时间公式， 并发数成了单位时间内处理的request数，并没有区分是并行处理还是串行处理。
正确的应该为：并发数：同一时间能够处理的线程数N. 假设每条线程单位时间（秒）处理的request平均是m, 则 TPS=N*m。 即TPS本质上由线程并发数和，线程处理效率决定
Google Chrome 41.0.
Windows 7 x64 Edition写的不错
Google Chrome 49.0.
Windows 10 x64 Edition写的不错
Google Chrome 45.0.
Windows 7 x64 Edition深入浅出
Safari 9.1.1
10.11.5写的不错
Firefox 50.0
Windows 7 x64 Edition楼主写的不错，我们boss让我接手接口 性能测试，能给点指点?谢谢 我以前做的是功能测试
4个多月经验
Sogou Explorer
Windows 7 x64 Edition写的真棒
Google Chrome 57.0.2987.98
Windows 10 x64 Edition在很多地方都看到这篇文章了，这里应该就是原出处吧
电子邮件 *
博文浏览排名
- 340,363 views - 298,179 views - 164,644 views - 134,339 views - 101,552 views - 95,448 views - 88,871 views - 83,735 views - 81,815 views - 72,091 views - 71,602 views - 71,538 views - 62,185 views - 56,630 views - 55,119 views - 54,599 views - 49,493 views - 49,421 views - 48,637 views - 48,177 views
2017年十二月
11121314151617
18192021222324
25262728293031web性能测试的基本指标_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
web性能测试的基本指标
你可能喜欢性能的部分概况一般来说，一个Web请求的处理包括以下步骤：
（1）客户发送请求
（2）web 接受到请求，进行处理；
（3）web server向DB获取数据；
（4）webserver生成用户的object(页面)，返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间（第三步不包括在每次请求处理中）。
1.事务（Transaction）
在web中，一个事务表示一个&从用户发送请求-&web server接受到请求，进行处理-& web server向DB获取数据-&生成用户的object(页面)，返回给用户&的过程，一般的响应时间都是针对事务而言的。
2.请求响应时间
请求响应时间指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常会称为&TTLB&，即"time to last byte"，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应所耗费的时间，响应时间的单位一般为&秒&或者&毫秒&。一个公式可以表示：响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则：
（1）在3秒钟之内，页面给予用户响应并有所显示，可认为是&很不错的&；
（2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是&好的&；
（3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是&勉强接受的&；
（4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去；
3、事务响应时间
&&事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数.
4.并发用户数
并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件 事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有 用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。
　　另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。
　　可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行&严 格意义上的并发&。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在 使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。
用户并发数量：关于用户并发的数量，有2种常见的错误观点。 一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和用户发生并发，例如正在浏览网页的用户，对没有任何影响，但是，在线用户数量是计算并发用户数量的主要依据之一。
指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.
6、　TPS（transactionper second）
每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.
每秒钟用户向WEB提 交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应 用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性 能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个 HTTP请求.
8.资源利用率
指的是对不同的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率等.资源利用率是分析系统性能指标进而改善性能的主要依据,因此是WEB性能测试的重点.
资源利用率主要针对WEB服务器,,服务器,网络等,是测试和分析瓶颈的主要参考.在WEB性能测试中,更根据需要采集相应的参数进行分析。
通用指标（指应用服务器、服务器必需项)
ProcessorTime
服务器CPU占用率，一般平均达到70%时，服务就接近饱和
Memory Available Mbyte
可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重
Physicsdisk Time
物理磁盘读写时间情况
Web服务器指标
Requests Per Second（Avg Rps）
平均每秒钟响应次数＝总请求时间 / 秒数
Avg time to last byte per terstion （mstes）
平均每秒业务脚本的迭代次数 ,有人会把上面那个混淆
Successful Rounds
成功的请求
Failed Requests
失败的请求
Successful Hits
成功的点击次数
Failed Hits
失败的点击次数
Hits Per Second
每秒点击次数
Successful Hits Per Second
每秒成功的点击次数
Failed Hits Per Second
每秒失败的点击次数
Attempted Connections
尝试链接数
服务器性能指标
User 0 Connections
用户连接数，也就是数据库的连接数量
Number of deadlocks
数据库死锁
Butter Cache hit
数据库Cache的命中情况
系统的瓶颈定义
当%user+%sys超过80%时
磁盘I/O限制
当%iowait超过40%(AIX4.3.3或更高版本)时
应用磁盘限制
当%tm_act超过70%时
虚存空间少
当分页空间的活动率超过70%时
Iostat, stat
虚存逻辑卷%tm_act超过I/O(iostat)的30%，激活的虚存率超过CPU数量(vmstat)的10倍时
Vmstat, sar
页交换增大、CPU等待并运行队列
　　稳定系统的资源状态
&2*CPU数量
没有页交换
每个CPU每秒10个页交换
更多的页交换
　　通俗理解：
　　日访问量
　　常用页面最大并发数
　　同时在线人数
　　访问相应时间
　　案例：
　　最近公司一个项目，是个门户网站，需要做，根据项目特点定出了主要测试项和测试方案：
　　一种是测试几个常用页面能接受的最大并发数(用户名参数化，设置集合点策略)
　　一种是测试服务器长时间压力下，用户能否正常操作(用户名参数化，迭代运行脚本)
　　一种则需要测试服务器能否接受10万用户同时在线操作，如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须 要使用集群，通过多台机器做负载均衡来实现；如果是用websphere之类的应用服务器的话，单台可承受的最大并发数可以达到10万级，但为性能考虑还 是必须要使用集群，通过多台机器做负载均衡来实现；通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空 间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑程序也占用内存，所以准备的内存数量要求比这个还要多一些。还有10万个用户同时在线，跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢？这就必须要有大量的历史信息来支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计，对于1个开发的系统（别的我没统计过，给不出数据），一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个（这个状态下大部分操作都是超时报错而且服务器很容易宕机，其实没什么实际意义），可正常使用（单步非量 操作等待时间不超过20秒）的最大并发数不超过300个。假设你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不 少于30台。当然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。
　　另外暴寒1下，光设置全部进入运行状态就需要接近6个小时。具体的可以拿1个系统来压一下看看，可能会出现以下情况：
　　1、服务器宕机；
　　2、客户端宕机；
　　3、从某个时间开始服务器拒绝请求，客户端上显示的全是错误；
　　4、勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽，百兆/10000=10K，那每个用户只能得到10K，这个速度接近1个64K的MODEM上网的速度；另外以上分析全都没考虑系统的后台，比如、中间件等。
　　1、服务器方面：上面说的那样的PC SERVER需要50台；
　　2、网络方面：按每个用户50K，那至少5根百兆带宽独享，估计仅仅网络延迟就大概是秒一级的；
　　3、如果有数据库，至少是ORACLE，最好是SYSBASE，SERVER是肯定顶不住的。数据库服务器至少需要10台4CPU、16G内存的机器；
　　4、如果有CORBA，那至少再准备10台4CPU、16G内存的机器；再加上负载均衡、防火墙、路由器和各种软件等，总之没个1000万的资金投入，肯定搞不定。
　　这样的门户系统，由于有用户权限，所以并不象jackie所说大多是静态页面。但只要是多服务器的集群，那么我们就可以通过1台机器的测试结果 来计算多台机器集群后的负载能力的，最多额外考虑一下负载均衡和路由上的压力，比如带宽、速度、延迟等。但如果都是在1台机器上变化，那我们只能做一些指 标上的计算，可以从这些指标上简单判断一下是否不可行，比如10万并发用户却只有1根百兆带宽，那我们可以计算出每个用户只有1K带宽，这显然是不可行 的。但实际的结果还是需要测试了才知道，毕竟系统压力和用户数量不是线性变化的。
　　这一类系统的普遍的成熟的使用，以及很多软件在方案设计后就能够大致估算出系统的性能特点，都导致了系统在软件性能方面调优的比例并不大（当然 不完全排除后期针对某些代码和配置进行优化后性能的进一步提高），更多的都是从硬件方面来考虑，比如增加内存、硬盘做RAID、增加带宽、甚至增加机器 等。
　　网络技术中的10M 带宽指的是以位计算， 就是 10M bit /秒 ，而下载时的速度看到的是以字节（Byte）计算的，所以10M带宽换算成字节理论上最快下载速度为： 1.25 M Byte/秒!
阅读(...) 评论()事务（Transaction）
一个事务表示一个“从用户发送请求-&server接受到请求，进行处理-&server向DB获取数据-&生成并返回用户的所需数据/页面”的过程，是指完成一次完整的业务操作。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，一般的响应时间都是针对事务而言的
事务分为业务层面和技术层面两种定义。业务层面事务是指完成一次完整的业务操作，例如进行一次取款、查询操作。技术层面的事务是指进行一次应用程序至应用程序、或者应用程序至数据库的系统操作。一般的一笔业务事务由多笔技术交易组成，根据业务事务的复杂度和系统应用架构的不同，其比例大致为1：2-1：10。一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。
QPS：（Queries Per Second）查询数/秒是一台服务器每秒能够处理的相应的查询次数。
TPS：（TransactionsPerSecond）事务数/秒。TPS是估算应用系统性能的重要依据。系统整体处理能力取决于处理能力最低模块的TPS值。依据经验，应用系统的处理能力一般要求TPS在10-100左右。当系统没有达到性能瓶颈时，TPS随着负载的增加呈近似线性增长，当接近性能瓶颈时出现拐点；如果系统健壮性较好，在到达性能瓶颈后，TPS基本保持水平，不会再随着负载的增加而有显著增长；而如果系统存在比较严重的性能问题，当到达性能瓶颈后，TPS会出现明显的下降趋势。
Tps即每秒处理事务数，包括了1）用户请求服务器2）服务器自己的内部处理3）服务器返回给用户，这三个过程，每秒能够完成N个这三个过程。Qps基本类似于Tps，但是不同的是，对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求。
HPS：(Hits per Second) 点击数/秒，是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和，是B/S系统中非常重要的性能指标之一。它一般和TPS成正比关系，但不是必然关系。
HPS是用来衡量很多用户使用客户端进行操作，向服务器发送请求的效率，
是衡量在线负载程度的一个指标。而TPS表现的是服务器端的程序行为，是衡量服务器处理能力高低的一个主要指标。
响应时间（Response
响应时间指的是从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间。响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间= 网络响应时间 + 应用程序响应时间。标准可参考国外的3/5/10原则：
（1）在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”；
（2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”；
（3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”；
（4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去；
响应时间既有客观的成分，也有主观的成分。响应时间包含：用户响应时间、前端响应时间、服务器响应时间。服务器响应时间可被分解为网络传输时间和应用延迟时间，而应用延迟时间又可以分为数据库延迟时间和应用服务器延迟时间。响应时间一般包括最大响应时间和平均响应时间，响应时间不包括浏览器上的内容显示时间。
响应时间是可以判断一个被测应用系统是否存在性能瓶颈的最直观的要素。例如，在执行完性能测试后，发现某个交易的“平均响应时间”为8秒，超过了预先确定下来的性能指标“该交易的性能指标为平均响应时间要小于等于3秒”。此时，就可以认为被测应用系统存在性能瓶颈了，要利用一定的手段去探查被测应用系统中哪个地方引起了系统的处理效率低以及低的原因了。
事务响应时间
事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的。例如:跨行取款事务的响应时间就是由一系列的请求组成的。事务响应时间是直接衡量系统性能的参数。
吞吐量（Throughput）
吞吐量直接体现软件系统的性能承载能力，是指单位时间内系统处理的客户请求的数量。一般来说，吞吐量用请求数/秒、页面数/秒来、访问人数/天、处理的业务数/小时、字节数/天 来衡量。
对于交互式应用，用户直接的体验是“响应时间”，通过“并发用户数”和“响应时间”可以确定系统的性能规划；
对于非交互式应用，用“吞吐量”来描述用户对系统性能的期望可能更加合理。
一个系统吞吐量通常由TPS/QPS、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。
并发用户数(Concurrent
并发数是指同时进行请求的用户的数量，并发情况是对系统最大的考验。在性能测试工具中，一般称为虚拟用户数(Virutal User)。并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交。另外一种并发是广义范围的并发，即尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。
后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。
思考时间也被称为休眠时间，是用户操作每个请求之间的间隔时间。对交互式应用来说，用户在使用系统时，不大可能持续不断地发出请求，一般是用户在发出一个请求后，等待一段时间，再发出下一个请求。如果测试的目的是为了验证应用系统具有预期的能力（能力验证），就应该尽量模拟用户在试用业务时的真实思考时间；如果目的是进行更一般的研究，例如了解系统在压力下的性能水平或系统承受压力的能力（能力规划），则可以采用0思考时间。
Web前端性能
Web应用的前端响应时间指浏览器的页面加载时间，包括：HTML的解析、对页面上的图片及CSS等文件的获取和加载、客户端脚本的执行时间以、页面进行展现所花费的时间。这部分性能体现就被称为前端性能。前端性能与并发用户量的大小并无非常直接的关系。如何提高浏览器下载和执行资源的并发性，如何让浏览器尽快开始渲染页面，如何让浏览器尽可能充分地利用缓存等问题是前端性能关注的主要问题。
1、响应时间计算公式
网络传输时间：N1+N2+N3+N4
应用服务器处理时间：A1+A3
数据库服务器处理时间：A2
响应时间=N1+N2+N3+N4+A1+A3+A2
平均响应时间=响应时间/事务数
2、并发用户数计算公式
并发用户数 = 系统最大在线用户数的8%到12%
平均并发用户数的计算：C=nL / T
其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间，T是考察时间长度（一天内多长时间有用户使用系统）
并发用户数峰值计算：C^≈C+3*
其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。
假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。那么，
&&& 并发用户数: C=0
&&平均并发用户数为：C = 400*4/8 = 200
&&并发用户数峰值为：C‘ = 200 + 3*根号200 = 243
3、吞吐量的计算公式
指单位时间内系统处理用户的请求数
从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天、处理业务数/小时等单位来衡量
从网络角度看，吞吐量可以用：字节/秒来衡量
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU
其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间
4、TPS计算公式
TPS（QPS）=&并发数/平均响应时间
5、思考时间的计算公式
在吞吐量这个公式中F=VU * R/T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数，其中的R又可以用时间T和用户思考时间TS来计算：R = T/TS
下面给出一个计算思考时间的一般步骤：
A、首先计算出系统的并发用户数
C=nL/T &&&F=R×C
B、统计出系统平均的吞吐量
F=VU * R/T &&&&R×C = VU * R/T
C、统计出平均每个用户发出的请求数量
R=u*C*T/VU
D、根据公式计算出思考时间
6、性能计数器
性能计数器（Counter）是描述服务器或操作系统性能的一些数据指标。例如：对Windows系统来说，使用内存数和进程时间等都是常见的计数器。单一的性能计数器只能体现系统性能的某一个方面，对性能测试结果的分析必须基于多个不同的计数器。性能计数器在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。
7、资源利用率
指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。资源利用率通常以占用最大值的百分比n%来衡量。
8、STD是标准偏差值（Standard Deviation），主要用来反应样本空间分布情况。各个样本越接近平均值，STD越小， 在LR中，STD越小，说明测试时的原始分布比较集中，基本接近平均值。所以这个值很小时，一定程度上可以表明系统更加稳定。计算方法如下：S2= Σ(Xi- X )2/n - 1式中X ： 样本平均值S ： 标准偏差n ： 样本数量
阅读(...) 评论()