一、性能测试分类
1、 负载测试load testing:测试系统能达到的峰值指标;
2、 压力测试stress testing:强调在极端条件下系统的稳定性,确定什么条件下系统性能处于失效状态;
3、 容量测试volume testing:数据库最佳容量、最大容量,服务器连接能力等;
4、 配置测试configuration testing:获得不同配置下的性能指标;
5、 基准测试benchmark testing:基于配置测试的调优测试;
6、 并发测试concurrency testing
备注:负载测试、压力测试的区别,举例“
百度查询的响应时间不超过5秒。
负载测试:确认当查询的响应时间不超过5秒时,系统支持的最大并发用户数;
压力测试:确认当系统的最大并发用户数超过多少时,查询的响应时间不可接受(如1分钟)
二、性能测试指标
1、 响应时间:通过事务函数来统计响应时间
2、 吞吐量TPS transaction per second:每秒处理事务/请求/单位数据的数量
3、服务器资源占用:cpu占用率、内存使用率、查询Cache命中率
4、点击数:向webservice发起的http请求书(鼠标点击一次可发多个请求)
三、怎样定性能指标
http://my.oschina.net/dlpinghailinfeng/blog/186161
1、80~20原理:每个工作日中80%业务在20%的时间内完成
2、 估算并发数的公示:
(1) 计算平均的并发用户数: C = nL/T
(2) 并发用户数峰值: C’ ≈ C+3根号C
公式(1)中,C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度泊松分布估算系统的性能目标
一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。最大的并发用户数乘上一个值,2或者3
3、响应时间:
在互联网上对于用户响应时间,有一个普遍的标准。2/5/10秒原则。 也就是说,在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验,在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应,那么大多用户会认为这次请求是失败的
另:标准可参考国外的3/5/10原则:
(1)在3秒钟之内,页面给予用户响应并有所显示,可认为是“很不错的”;
(2)在3~5秒钟内,页面给予用户响应并有所显示,可认为是“好的”;
(3)在5~10秒钟内,页面给予用户响应并有所显示,可认为是“勉强接受的”;
(4)超过10秒就让人有点不耐烦了,用户很可能不会继续等待下去;
指标 |
说明 |
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个页交换 | 坏 | |
更多的页交换 | 很差 |
四、TPS、响应时间、吞吐量的理解
TPS是衡量服务处理能力的指标;
事务的概念是一个过程中各个环节组成的过程的整体;
用事务的概念来看TPS中的T,一次网络访问中从服务接收到请求(起),到服务完成响应(止)的整个过程就是一个事务;
在这个过程中,可能会包含很多环节,例如服务还需要从另外的数据库服务中获取数据,从其他中间件、网络中获取资源,服务内部的程序逻辑需要做数据处理、计算等等,但无论怎样,这些过程都会包含在请求和响应之间;
服务完成客户端的这样的一个过程就是完成一次事务,单位时间内(通常用秒)服务能完成多少个这样的事务就是TPS,就是衡量服务处理能力的指标。
响应时间可以理解为是用于衡量单次事务所花费的时间,但是也不绝对如此,不同的场景下也会用于衡量单次请求的时间……不论如何都是衡量都是统计单次的。既然是单次的这就有个问题,对于同一个过程,单次的时间也可能不同,所以响应时间又会衍生出最大响应时间,最小响应时间,平均响应时间,90%响应时间等等;
很多时候,吞吐量和TPS可以看做是等价的,都是单位时间里完成任务的数量。但在特定的场景的概念定义又会有些小差别。不同的工具的叫法也不同,Jmeter里就是吞吐量Throughput,貌似没有TPS。
很多概念背后的本质是相同的,只是定义得角度不同,关注得细节不同。山就是那座山,远看成岭侧成峰,人站的位置不同看到的景色也不同。