性能测试

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

《Discuz VS Phpwind 性能巅峰对决》测试方案
1、测试目标
a)对比目前两个人气最高的论坛程序Discuz和Phpwind 的结果性能,从性能角度对
工具进行评估和选型提供一些数据上的参考
b)为初学性能测试盒LoadRuner的朋友在如何制定测试方案,开发测试脚本和分析测
试结果方面提供一些参考
2、测试过程
a)测试计划:暂不适合本文档
b)测试方案:
i.用于制定测试策略,理清测试思路,为测试实施和执行提供技术上的参考
ii.确定测试对象,测试场景很指标,避免在测试执行时临时抱佛脚
c)测试实施:
i.搭建XAMPP服务平台
ii.安装Discuz和Phpwind论坛程序
iii.开发LoadRunner测试脚本
d)测试执行:
i.根据方案中制定的场景策略运行场景,并监控相关指标
ii.根据相关指标进行分析,确定二者的性能,达成本次的测试目的
3、测试对象
a)Discuz 7.0.0PHP版
i.现有帖子数:30377,现有回复数:15049,数据库大小:22.1M
b)Phpwind 7.3.2
i.现有帖子数:31064,现有回复数:15796,数据库大小:26.7M
4、测试平台
a)软件:Windows XP SP3 + XAMPP 1.6.8(Apache 2.2.9 + MySQL 5.0.67 + PHP 5.2.6)
b)硬件:CPU:P8400 2.26GHz,MEM:3GB,网卡:千兆网卡
c)客户端:由于机器限制,本次测试的客户端服务器位于同一台电脑,由于只是对比
测试,未牵涉到性能调优,所以硬件平台对于二者的结果判断是公平的
d)测试工具:LoadRunner 9.5.0英文版
5、被测模块
a)论坛登录
b)论坛发帖
c)帖子回复
6、性能测试脚本开发方案
a)总体方案:
i.手工定义事物,事物状态由LR自动判断,不使用web_reg_find进行手工
检查(经预测试发现几个功能的出错率很小,所以不能考虑脚本本身的健
壮性,使脚本简单化)
ii.只关注三个POST请求(使用web_submit_data函数提交POST请求),为减少测试结果的干扰因素,不考虑打开某个页面的性能(使用web_url函
数提交的GET请求),不模拟真实用户需要打开首页,打开登录页面才能
登录。

或者必须进入某个版块才能发帖等真实操作
iii.不使用集合点策略
iv.为避免两个系统在运行性能测试时的干扰因素,要确保两个测试脚本完全一致,需要实现如下要求:
1.相同的参数设置
2.相同的事物定义
3.相同的关联
4.相同的思考时间设置
5.相同的场景设计
6.每执行一次测试,都重启一下XAMPP服务器,清理服务器环境
b)论坛登录模块:
i.预先注册50个用户(密码相同),使用For循环来产生一个1-50的序列,
注册用户名为lruser1,lruser2...Lruser50
ii.从lruser1...Lruser50中每次迭代随机取一个用户名(产生一个1-50说我随机数并与lruser字符串拼在一起即可)可作登录用户名
iii.直接发送POST请求道服务器登录处理界面,不用先打开首页很登录页面
c)论坛发帖模块:
i.需要使用管理来解决客户端验证问题
ii.由于Phpwind使用UTF-8编码,而Discuz使用GBK编码,为降低影响因素,同意使用英语作为帖子的标题和内容(如果使用中文,在Phpwind上
则需要使用lr_convert_encoding函数来动态转换中文内容,增加了一个
潜在的影响因素,所以不使用中文)
iii.不考虑对于多个板块进行发帖,专门新建一个板块来进行发帖测试
iv.帖子标题和内容使用一个唯一数加上一段固定的英文的方式来产生不同的标题和内容
d)帖子回复模块:
i.直接使用发帖操作中关联出来的客户端验证码
ii.标题和内容设置于发帖相同
iii.从本板块中随机抽取100个帖子作为回复的对象(100个被回复帖子的ID 号通过创建Random Numver 类型参数并指定具体范围来实现)
7、性能测试场景设计方案
a)由于客户端与服务器位于同一台电脑,经过预测试发现CPU很容易达到100%,所以
本次测试准备测试50和100虚拟用户两种负载
b)同时,也由于CPU使用率偏高的问题,我们为所有测试步骤都设置了思考时间,统
一设置思考时间为2秒,以此来降低CPU的负荷,并且将思考时间置于事物外,这样响应时间中将不包含思考时间(如将思考时间置于事物内也可以,那么记得在Analysis中将思考时间扣除)
c)使用Ramp Up 和Ramp Dowm 策略,用于分析随着虚拟用户的增加两个系统在响应
时间上的变化情况
d)对于50虚拟用户,Ramp Up设置为每30秒钟加5个用户,Ramp Down设置为每30
秒钟减5个用户
e)对于100虚拟用户,RampUp设置为每30秒钟加10个用户,Ramp Dowm 设置为每
30秒钟减10个用户
f)Ramp Up 完成后持续时间为5分钟,这样总体运行时间约为15分钟
g)不使用集合点,不使用IP欺骗,一次运行只测试一个脚本,负载生成器为本机
8、重要分析指标
a)监控CPU:%Processor Time 和Processor Queue Length 两个指标
b)监控内存:总体内存可用数
c)Web页面的HPS(Hits Per Second –每秒点击数,即每秒请求数)
d)Web页面的吞吐量(Throughput)
e)登录,发帖和回复的RT(Response Time –平均响应时间)和90Percent的响应
时间
f)登录,发帖和回复的TPS(Transaction Per Second –每秒事物数)
g)帖子数和回复数:相同场景下比较二者发送成功的帖子数量和回复数据,量多者胜
9、其他考虑
a)Discuz和Phpwind 自身都带了一些针对不同用户数数量的优化参数供使用,对比
测试时不使用任何优化设置,保持默认的设置即可
b)Discuz和Phpwind 对发帖时间间隔由限制,请取消该限制,确保发帖没有时间间

c)使用机器名或者真实的IP地址访问服务器而非127.0.0.1或者localhost
d)为避免Apache 和Mysql 内存释放不完全,每次测试完成后重启一下XAMPP
e)由于需要测试登录模块,所以需要确保每次运行完成后都将该用户登录,否则就会
存在下一迭代时被系统告知用户已经登录得情况。

相关文档
最新文档