性能测试方案

《Discuz VS Phpwind性能巅峰对决》测试方案

1、 测试目标

a) 对比目前两个人气最高的论坛程序 Discuz 和 Phpwind 的性能，从性能角度对工具进行评估和选型提供一些数据上的参考
b) 为初学性能测试和LoadRunner 的朋友在如何制定测试方案，开发测试脚本和分析测试结果方面
提供一些参考

2、 测试过程

a) 测试计划：暂不适用于本文档
b) 测试方案：
　　i. 用于制定测试策略，理清测试思路，为测试实施和执行提供技术上的参考
　　ii. 确定测试对象，测试场景和指标，避免在测试执行时临时抱佛脚
c) 测试实施：
　　i. 搭建 XAMPP服务器平台
　　ii. 安装 Discuz和 Phpwind论坛程序
　　iii. 开发LoadRunner测试脚本
d) 测试执行：
　　i. 根据方案中制定的场景策略运行场景，并监控相关指标
　　ii. 根据相关指标进行分析，确定二者的性能，达成本次测试的目的

3、 测试对象

 a) Discuz! 7.0.0 For PHP版
　　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 11英文版

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_string_encoding 函数来动态转换中文内容，增加了一个潜在的影响因素，所以不
使用中文)
iii. 不考虑对多个板块进行发帖，专门新建一个板块来进行发帖测试
iv. 帖子标题和内容使用一个唯一数加上一段固定的英文的方式来产生不同的标题和内容

d) 帖子回复模块：
i. 直接使用发帖操作中关联出来的客户端验证码
ii. 标题和内容设置与发帖相同
iii. 从本板块中随机抽取 100 个帖子作为回复的对象(100 个被回复帖子的 ID 号通过创建
Random Number类型参数并指定具体范围来实现)

7、 性能测试场景设计方案

a) 由于客户端与服务器端位于同一台电脑，经过预测试发现 CPU 很容易到达 100%，所以本次测
试准备测试50和100个虚拟用户两种负载
b) 同时，也由于 CPU 使用率偏高的问题，我们为所有测试步骤都设置思考时间，统一设置思考时
间为 2 秒，以此来降低 CPU 的负荷，并且将思考时间置于事务外，这样响应时间中将不包含思
考时间(如将思考时间置于事务内也可以，那么记得在 Analysis 中将思考时间扣除)。
c) 使用 Ramp Up 和Ramp Down策略，用于分析随着虚拟用户的增加两个系统在响应时间上的变
化情况。
d) 对于50虚拟用户，Ramp Up 设置为每30秒钟加5个用户，Ramp Down设置为每30秒钟减5
个用户
e) 对于 100虚拟用户，Ramp Up 设置为每30秒钟加 10个用户，Ramp Down设置为每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 -- 平均响应时间)和 90 Percent的响应时间
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) 由于需要测试登录模块，所以需要确保每次运行完成后都要将该用户登出，否则就会存在下一迭
代时被系统告知用户已经登录的情况。