web性能指标

Web性能测试的部分概况通常来讲，一个Web请求的处理包括如下步骤：

（1）客户发送请求

（2）web server 接受到请求，进行处理；

（3）web server 向DB获取数据；

（4）web server生成用户的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秒就让人有点不耐烦了，用户极可能不会继续等待下去；

三、事务响应时间

  事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数.

4.并发用户数

并发通常分为2种状况。一种是严格意义上的并发，即全部的用户在同一时刻作同一件事情或者操做，这种操做通常指作同一类型的业务。好比在信用卡审批业务中，必定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即全部用户进行彻底同样的 操做，例如在信用卡审批业务中，全部的用户能够一块儿申请业务，或者修改同一条记录。

　　另一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操做，可是这些请求或者操做能够是相同的，也能够是不一样的。对整个系统而言，仍然是有不少用户同时对系统进行操做，所以也属于并发的范畴。

　　能够看出，后一种并发是包含前一种并发的。并且后一种并发更接近用户的实际使用状况，所以对于大多数的系统，只有数量不多的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发状况通常都须要进行测试，一般作法是先进行严格意义上的并发测试。严格意义上的用户并发通常发生在使用比较频繁的模块中，尽管发生的几率不是很大，可是一旦发生性能问题，后果极可能是致命的。严格意义上的并发测试每每和功能测试关联起来，由于并发功能遇到异常一般都是程序问题，这种测试也是健壮性和稳定性测试的一部分。

用户并发数量：关于用户并发的数量，有2种常见的错误观点。 一种错误观点是把并发用户数量理解为使用系统的所有用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不必定会和其余用户发生并发，例如正在浏览网页的用户，对服务器没有任何影响，可是，在线用户数量是计算并发用户数量的主要依据之一。

5.吞吐量

指的是在一次性能测试过程当中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.

六、　TPS（transaction per second）

每秒钟系统可以处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.

七、点击率

每秒钟用户向WEB服务器提 交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,因此点击是WEB应用可以处理的交易的最小单位.若是把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。须要注意的是,这里的点击并不是指鼠标的一次单击操做,由于在一次单击操做中,客户端可能向服务器发出多个HTTP请求.

8.资源利用率

指的是对不一样的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率等.资源利用率是分析系统性能指标进而改善性能的主要依据,所以是WEB性能测试工做的重点.

资源利用率主要针对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的命中状况

系统的瓶颈定义

性能项

命令

指标

CPU限制 vmstat 当%user+%sys超过80%时

磁盘I/O限制 Vmstat 当%iowait超过40%(AIX4.3.3或更高版本)时

应用磁盘限制 Iostat 当%tm_act超过70%时

虚存空间少 Lsps，-a 当分页空间的活动率超过70%时

换页限制 Iostat, stat 虚存逻辑卷%tm_act超过I/O(iostat)的30%，激活的虚存率超过CPU数量(vmstat)的10倍时

系统失效 Vmstat, sar 页交换增大、CPU等待并运行队列

　　稳定系统的资源状态

性能项

资源

评价

CPU占用率 70% 好

85% 坏

90%+ 不好

磁盘I/0 <30% 好

<40% 坏

<50%+ 不好

网络 <30%带宽 好

运行队列 <2*CPU数量 好

内存 没有页交换 好

每一个CPU每秒10个页交换 坏

更多的页交换 不好

　　通俗理解：

　　日访问量

　　经常使用页面最大并发数

　　同时在线人数

　　访问相应时间

　　案例：

　　最近公司一个项目，是个门户网站，须要作性能测试，根据项目特色定出了主要测试项和测试方案：

　　一种是测试几个经常使用页面能接受的最大并发数(用户名参数化，设置集合点策略)

　　一种是测试服务器长时间压力下，用户可否正常操做(用户名参数化，迭代运行脚本)

　 　一种则须要测试服务器可否接受10万用户同时在线操做，若是是用IIS作应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必需要使用集 群，经过多台机器作负载均衡来实现；若是是用websphere之类的应用服务器的话，单台可承受的最大并发数能够达到10万级，但为性能考虑仍是必需要 使用集群，经过多台机器作负载均衡来实现；一般有1个简单的计算方式，1个链接产生1个session，每一个session在服务器上有个内存空间大小的 设置，在NT上是3M，那么10万并发就须要300G内存，固然实际使用中考虑其余程序也占用内存，因此准备的内存数量要求比这个还要多一些。还有10万个用户同时在线，跟10万个并发数是彻底不一样的2个概念。这个楼上已经说了。但如何作这个转换将10万个同时在线用户转换成多少个并发数呢？这就必需要有大量的历史日志信息来支撑了。系统日志须要有同时在线用户数量的日志信息，还须要有用户操做次数的日志信息，这2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计，对于1个JAVA开发的WEB系 统（别的我没统计过，给不出数据），通常1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个（这个状态下大部分操做都是超时报错并且服务 器很容易宕机，其实没什么实际意义），可正常使用（单步非大数据量操做等待时间不超过20秒）的最大并发数不超过300个。假设你的10万同时在线用户转 换的并发数是9000个，那么你最少须要这样的机器18台，建议很多于30台。固然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千 兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。

　　另外暴寒1下，光设置所有进入运行状态就须要接近6个小时。具体的能够拿1个系统来压一下看看，可能会出现如下状况：

　　一、服务器宕机；

　　二、客户端宕机；

　　三、从某个时间开始服务器拒绝请求，客户端上显示的全是错误；

　　四、勉强测试完成，但网络堵塞或测试结果显示时间很是长。假设客户端和服务器之间百兆带宽，百兆/10000=10K，那每一个用户只能获得10K，这个速度接近1个64K的MODEM上网的速度；另外以上分析全都没考虑系统的后台，好比数据库、中间件等。

　　一、服务器方面：上面说的那样的PC SERVER须要50台；

　　二、网络方面：按每一个用户50K，那至少5根百兆带宽独享，估计仅仅网络延迟就大概是秒一级的；

　　三、若是有数据库，至少是ORACLE，最好是SYSBASE，SQLSERVER是确定顶不住的。数据库服务器至少须要10台4CPU、16G内存的机器；

　　四、若是有CORBA，那至少再准备10台4CPU、16G内存的机器；再加上负载均衡、防火墙、路由器和各类软件等，总之没个1000万的资金投入，确定搞不定。

　 　这样的门户系统，因为有用户权限，因此并不象jackie所说大可能是静态页面。但只要是多服务器的集群，那么咱们就能够经过1台机器的测试结果来计算多 台机器集群后的负载能力的，最多额外考虑一下负载均衡和路由上的压力，好比带宽、速度、延迟等。但若是都是在1台机器上变化，那咱们只能作一些指标上的计 算，能够从这些指标上简单判断一下是否不可行，好比10万并发用户却只有1根百兆带宽，那咱们能够计算出每一个用户只有1K带宽，这显然是不可行的。但实际 的结果仍是须要测试了才知道，毕竟系统压力和用户数量不是线性变化的。

　 　这一类系统的广泛的成熟的使用，以及不少软件在方案设计后就可以大体估算出系统的性能特色，都致使了系统在软件性能方面调优的比例并不大（固然不彻底排 除后期针对某些代码和配置进行优化后性能的进一步提升），更多的都是从硬件方面来考虑，好比增长内存、硬盘作RAID、增长带宽、甚至增长机器等。

　　网络技术中的10M 带宽指的是以位计算， 就是 10M bit /秒 ，而下载时的速度看到的是以字节（Byte）计算的，因此10M带宽换算成字节理论上最快下载速度为： 1.25 M Byte/秒!