一、事务(Transaction)javascript
在web性能测试中,一个事务表示一个“从用户发送请求->web server接受到请求,进行处理-> web server向DB获取数据->生成用户的object(页面),返回给用户”的过程,通常的响应时间都是针对事务而言的。java
二、请求响应时间mysql
请求响应时间指的是从客户端发起的一个请求开始,到客户端接收到从服务器端返回的响应结束,这个过程所耗费的时间,在某些工具中,响应一般会称为“TTLB”,即"Time To Last Byte",意思是从发起一个请求开始,到客户端接收到最后一个字节的响应所耗费的时间,响应时间的单位通常为“秒”或者“毫秒”。一个公式能够表示:响应时间=网络响应时间+应用程序响应时间。ios
(1)在1秒钟以内,页面给予用户响应并有所显示,可认为是“很不错的”;web
(2)在1~2秒钟内,页面给予用户响应并有所显示,可认为是“好的”;sql
(3)在2~3秒钟内,页面给予用户响应并有所显示,可认为是“勉强接受的”;数据库
(4)超过3秒就让人有点不耐烦了,用户极可能不会继续等待下去;服务器
三、事务响应时间网络
事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念,是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数.架构
四、并发用户数
并发通常分为2种状况。一种是严格意义上的并发,即全部的用户在同一时刻作同一件事情或者操做,这种操做通常指作同一类型的业务。好比在信用卡审批业务中,必定数目的拥护在同一时刻对已经完成的审批业务进行提交;还有一种特例,即全部用户进行彻底同样的 操做,例如在信用卡审批业务中,全部的用户能够一块儿申请业务,或者修改同一条记录。
另一种并发是广义范围的并发。这种并发与前一种并发的区别是,尽管多个用户对系统发出了请求或者进行了操做,可是这些请求或者操做能够是相同的,也能够是不一样的。对整个系统而言,仍然是有不少用户同时对系统进行操做,所以也属于并发的范畴。
能够看出,后一种并发是包含前一种并发的。并且后一种并发更接近用户的实际使用状况,所以对于大多数的系统,只有数量不多的用户进行“严格意义上的并发”。对于WEB性能测试而言,这2种并发状况通常都须要进行测试,一般作法是先进行严格意义上的并发测试。严格意义上的用户并发通常发生在使用比较频繁的模块中,尽管发生的几率不是很大,可是一旦发生性能问题,后果极可能是致命的。严格意义上的并发测试每每和功能测试关联起来,由于并发功能遇到异常一般都是程序问题,这种测试也是健壮性和稳定性测试的一部分。
用户并发数量:关于用户并发的数量,有2种常见的错误观点。 一种错误观点是把并发用户数量理解为使用系统的所有用户的数量,理由是这些用户可能同时使用系统;还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不必定会和其余用户发生并发,例如正在浏览网页的用户,对服务器没有任何影响,可是,在线用户数量是计算并发用户数量的主要依据之一。
五、吞吐量
指的是在一次性能测试过程当中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.
对于交互式应用来讲,吞吐量指标反映的是服务器承受的压力,在容量规划的测试中,吞吐量是一个重点关注的指标,由于它可以说明系统级别的负载能力。
吞吐率:
单位时间内网络上传输的数据量,也能够指单位时间内处理客户请求数量。它是衡量网络性能的重要指标,一般状况下,吞吐率用“字节数/秒”来衡量,固然,你能够用“请求数/秒”和“页面数/秒”来衡量。其实,不论是一个请求仍是一个页面,它的本质都是在网络上传输的数据,那么来表示数据的单位就是字节数。
不过以不一样的方式表达的吞吐量能够说明不一样层次的问题。例如,以字节数/秒方式表示的吞吐量主要受网络基础设置、服务器架构、应用服务器制约;以请求数/秒方式表示的吞吐量主要受应用服务器和应用代码的制约。
六、TPS(transaction per second)
每秒钟系统可以处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.
七、点击率(Hit Per Second)
每秒钟用户向WEB服务器提 交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,因此点击是WEB应用可以处理的交易的最小单位.若是把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。
须要注意的是,这里的点击并不是指鼠标的一次单击操做,由于在一次单击操做中,客户端可能向服务器发出多个HTTP请求.
点击率能够看作是TPS的一种特定状况。点击率更能体现用户端对服务器的压力。TPS更能体现服务器对客户请求的处理能力。
八、资源利用率
指的是对不一样的系统资源的使用程度,例如服务器的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的命中状况 |
系统的瓶颈定义
性能项 |
命令 |
指标 |
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个页交换 |
坏 |
|
更多的页交换 |
不好 |
该要求不包括文件上传 等重量级接口
指标名称
|
要求
|
优先级
|
备注
|
---|---|---|---|
响应时间 | 500 millisecond | 1 | |
请求成功率 | 99% | 2 | |
TPS | 在知足预期要求的状况下服务器状态稳定,单台服务器TPS要求在1000左右 |
3 | |
资源使用率 | 要求在TPS正常幅度的状况下资源使用率幅度平稳,服务器状态平稳 | 3 | 要求接口的内部实现不能占用太多资源 |
数据库死锁 | 0,要求接口在使用过程当中不会形成数据库死锁 | 1 | |
CPU限制 | 要求接口在使用过程当中不会出现大量的计算 | 3 | |
内存 | 要求接口在使用过程当中不会出现内存大量消耗的状况 | 3 | |
指标名称
|
要求
|
优先级
|
备注
|
---|---|---|---|
响应时间 | 500 millisecond | 1 | |
请求成功率 | 99% | 2 | |
TPS | 在知足预期要求的状况下服务器状态稳定,单台服务器TPS要求在1000左右 |
3 | |
资源使用率 | 要求在TPS正常幅度的状况下资源使用率幅度平稳,服务器状态平稳 | 3 | 要求接口的内部实现不能占用太多资源 |
数据库死锁 | 0,要求接口在使用过程当中不会形成数据库死锁 | 1 | |
CPU限制 | 要求接口在使用过程当中不会出现大量的计算 | 3 | |
内存 | 要求接口在使用过程当中不会出现内存大量消耗的状况 | 3 |