此文章是转载网络一些语言,主要为后续我们讲解loadrunner做铺垫,若有意学习loadrunner或者性能测试的童鞋,可以提前了解和阅读
Web性能测试的部分概况一般来说,一个Web请求的处理包括以下步骤:
(1)客户发送请求
(2)web server接受到请求,进行处理;
(3)web server向DB获取数据;
(4)webserver生成用户的object(页面),返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间(第三步不包括在每次请求处理中)。
在web性能测试中,一个事务表示一个“从用户发送请求->web server接受到请求,进行处理-> web server向DB获取数据->生成用户的object(页面),返回给用户”的过程,一般的响应时间都是针对事务而言的。
请求响应时间指的是从客户端发起的一个请求开始,到客户端接收到从服务器端返回的响应结束,这个过程所耗费的时间,在某些工具中,响应通常会称为“TTLB”,即"time tolast byte",意思是从发起一个请求开始,到客户端接收到最后一个字节的响应所耗费的时间,响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示:响应时间=网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则:
(1)在3秒钟之内,页面给予用户响应并有所显示,可认为是“很不错的”;
(2)在3~5秒钟内,页面给予用户响应并有所显示,可认为是“好的”;
(3)在5~10秒钟内,页面给予用户响应并有所显示,可认为是“勉强接受的”;
(4)超过10秒就让人有点不耐烦了,用户很可能不会继续等待下去;
事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念,是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数.
并发一般分为2种情况。一种是严格意义上的并发,即所有的用户在同一时刻做同一件事情或者操作,这种操作一般指做同一类型的业务。比如在信用卡审批业务中,一定数目的拥护在同一时刻对已经完成的审批业务进行提交;还有一种特例,即所有 用户进行完全一样的操作,例如在信用卡审批业务中,所有的用户可以一起申请业务,或者修改同一条记录。
另外一种并发是广义范围的并发。这种并发与前一种并发的区别是,尽管多个用户对系统发出了请求或者进行了操作,但是这些请求或者操作可以是相同的,也可以是不同的。对整个系统而言,仍然是有很多用户同时对系统进行操作,因此也属于并发的范畴。
可以看出,后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况,因此对于大多数的系统,只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言,这2种并发情况一般都需要进行测试,通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中,尽管发生的概率不是很大,但是一旦发生性能问题,后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来,因为并发功能遇到异常通常都是程序问题,这种测试也是健壮性和稳定性测试的一部分。
用户并发数量:关于用户并发的数量,有2种常见的错误观点。 一种错误观点是把并发用户数量理解为使用系统的全部用户的数量,理由是这些用户可能同时使用系统;还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户发生并发,例如正在浏览网页的用户,对服务器没有任何影响,但是,在线用户数量是计算并发用户数量的主要依据之一。
指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.
每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.
每秒钟用户向WEB服务器提 交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性 能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个 HTTP请求.
指的是对不同的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率等.资源利用率是分析系统性能指标进而改善性能的主要依据,因此是WEB性能测试工作的重点.
资源利用率主要针对WEB服务器,操作系统,数据库服务器,网络等,是测试和分析瓶颈的主要参考.在WEB性能测试中,更根据需要采集相应的参数进行分析。
指标 |
说明 |
ProcessorTime |
服务器CPU占用率,一般平均达到70%时,服务就接近饱和 |
Memory Available Mbyte |
可用内存数,如果测试时发现内存有变化情况也要注意,如果是内存泄露则比较严重 |
Physicsdisk Time |
物理磁盘读写时间情况 |
指标 |
说明 |
Requests Per Second(AvgRps) |
平均每秒钟响应次数=总请求时间 / 秒数 |
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个页交换 |
坏 |
|
更多的页交换 |
很差 |