独立核心模块并发测试的目的是尽量发现核心算法或者功能方面的问题
在测试中,我们一般要面对的问题有:
1、性能测试点的选取
性能测试点的选取有以下原则:
需要选取发生频率非常高的(例如:某邮箱核心业务系统中的登录、收发邮件等业务,它们在每天的业务总量中占到90%以上)
需要选取关键程度非常高的(产品经理认为绝对不能出现问题的,如登录等)
需要选取资源占用非常严重的(导致磁盘I/O非常大的,例如某个业务进行结果提交时需要向数十个表存取数据,或者一个查询提交请求时会检索出大量的数据记录)
2、并发用户数设计
并发用户数的设计可以参考如下公式进行计算平均的并发用户数和峰值作为参考:
(1) 计算平均的并发用户数: C = nL/T
(2) 并发用户数峰值: C’ ≈ C+
公式(1)中,C是平均的并发用户数;n是同时在线用户的数量;L是用户在线的平均长度;T指考察的时间段长度。
公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
实例:
假设有一个系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。
则根据公式(1)和公式(2),可以得到:
C = 400*4/8 = 200
C’≈200+ = 242
3、并发测试监控点的选择
指标 | 说明 |
%ProcessorTime | CPU平均利用率,通常 不高于75%为正常,如果持续高于95%,表明CPU存在瓶颈 |
%User Time | 用户态CPU平均利用率, 非核心态操作消耗的CPU时间,如果该值较大一般是应用程序存在问题,需要优化 |
Memory Available Mbyte | 可用内存数,如果测试时发现内存有变化情况也要注意,如果是内存泄露则比较严重 |
Free | 可用物理内存数. 如果该值很小(4 MB 或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存 |
Percent of time the disk is busy | 所选磁盘驱动器忙于为读或写入请求提供服务所有时间的百分比,如果该值太大,说明磁盘可能是瓶颈 |
Disk rate | 磁盘交换率, 如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统 |
Page/sec | 硬件页面错误而从磁盘取出的页面数或由于页面错误而写入磁盘以释放工作集空间的页面数 |
Physical Disk Time | 物理磁盘利用率 |
Physical Disk, Avg Disk Queue Length | 物理磁盘平均磁盘I/O队列长度 |
web服务器指标
指标 | 说明 |
Number of Concurrent Users (NCU) | 并发用户数,方案运行中,如果出现了大于3个用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数 |
Requests Per Second (RPS) | 每秒处理请求数 |
Response Time | 响应时间,事务的响应时间 |
Hits Per Second | 点击率(每秒向WEB服务器提交的HTTP请求数 ),点击率越大对服务器的压力越大;一次鼠标“点击”操作可能向服务器发出多个http请求。点击率和吞吐率一般成正比 |
Transactions Per Second(TPS) | 每秒系统处理的交易或事务数,如果把每次点击定义为一个交易(事务),点击率和TPS就是一个概念 |
客户端指标:
指标 | 说明 |
Response Time | 响应时间 |
Think Time | 思考时间 |
Hits per Second | 每秒点击次数 |
Number of Concurrent Users (NCU) | 并发用户数 |
数据库指标
指标 | 说明 |
User 0 Connections | 用户连接数,也就是数据库的连接数量 |
Number of deadlocks | 数据库死锁,越小越好 |
Butter Cache hit | 数据库Cache的命中情况,用来缓存用户最近在数据库中访问过的段数据块的副本 ,通过Database Buffer Cache(数据库缓冲区的高速缓存区)使用户可以在内存找到他们所请求的数据 。缓存区命中率表示可以从高速缓存中找到而不需去磁盘读取的百分比,大一些较好,达到90%以上最好,可以通过增加内存实现 |
4、请求响应时间标准
请求响应时间指的是从客户端发起的一个请求开始,到客户端接收到从服务器端返回的响应结束这个过程所耗费的时间,一个公式可以表示:响应时间=网络传输时间*2+服务器处理时间+客户端显示时间。标准可参考国外的3/5/10原则:
(1)在3秒钟之内,页面给予95%用户响应并有所显示,可认为是“很不错的”;
(2)在3~5秒钟内,页面给予95%用户响应并有所显示,可认为是“好的”;
(3)在5~10秒钟内,页面给予95%用户响应并有所显示,可认为是“勉强接受的”;
(4)超过10秒就让人有点不耐烦了,用户很可能不会继续等待下去;
注意:请求响应时间区分于事务响应时间,事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念
5、系统瓶颈定义
性能项 | 命令 | 指标 |
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等待并运行队列 |