网络游戏之性能测试规划（二）——如何建立有效的基准数据及环境（拟稿）
建立有效的基准数据及环境
建立有效基准数据及环境，是为了解决现有测试环境与测试数据无法与实际生产环境进行对比与估量的问题。在测试方法上，我们仍然采用负载与压力并行的方式（有关负载测试与压力测试的区别，请查阅相关性能测试书籍）。建立有效的基准数据模型，可以为我们提供较为可靠的版本性能预警机制、为测试数据提供较为精确的阀值标准、建立统一的数据分析体系，并在一定程度上提高了对现有版本的控制力度，在一定程度上规避了版本发布的风险，为实际生产提供了有力保证。
1) 建立有效的基准测试环境，及度量方式：
1. 拓扑结构：
1) 生产模式
根据以上整体拓扑结构，我们知道可能造成GameServer服务器性能瓶颈的硬件设备有：
a) 硬件防火墙阵列的吞吐量
b) 交换机机柜的数据包处理极限
c) 内网网络环境（吞吐量、带宽、稳定性….）
d) 潜在因素（服务器版本、补丁、停电、容错…）
排除以上因素，我们对内网服务器架构进行分析：
根据以上更为细致的内网结构图，我们可以知道可能造成GameServer服务器性能瓶颈的硬件设备有：
a) 交换机设备吞吐量
2) 测试模式
2. 硬件环境：
1) 生产模式
GameServer服务器：
|
|
应用服务器 |
数据库服务器 |
| 机器型号 |
|
|
| CPU |
|
|
| Ｍemory |
|
|
| Disk |
|
|
| 网卡 |
|
|
| 操作系统 |
|
|
| 数据库 |
|
|
| 系统版本 |
|
|
RoleServer服务器：
|
|
应用服务器 |
数据库服务器 |
| 机器型号 |
|
|
| CPU |
|
|
| Ｍemory |
|
|
| Disk |
|
|
| 网卡 |
|
|
| 操作系统 |
|
|
| 数据库 |
|
|
| 系统版本 |
|
|
TongServer服务器
|
|
应用服务器 |
数据库服务器 |
| 机器型号 |
|
|
| CPU |
|
|
| Ｍemory |
|
|
| Disk |
|
|
| 网卡 |
|
|
| 操作系统 |
|
|
| 数据库 |
|
|
| 系统版本 |
|
|
LogServer服务器
|
|
应用服务器 |
数据库服务器 |
| 机器型号 |
|
|
| CPU |
|
|
| Ｍemory |
|
|
| Disk |
|
|
| 网卡 |
|
|
| 操作系统 |
|
|
| 数据库 |
|
|
| 系统版本 |
|
|
MonitorServer服务器
|
|
应用服务器 |
数据库服务器 |
| 机器型号 |
|
|
| CPU |
|
|
| Ｍemory |
|
|
| Disk |
|
|
| 网卡 |
|
|
| 操作系统 |
|
|
| 数据库 |
|
|
| 系统版本 |
|
|
备用服务器
网络设备：
| 网络类型 |
带宽 |
设备 |
数量 |
| 局域网 |
100Mb |
Xingnet nes-1016 16 port N-way Switch |
1 |
网络结构：
| 网络结构 |
带宽 |
连接设备 |
| 星型 |
|
|
数据库及服务器参数：
| 参数名 |
建议值 |
| 数据库连接池 最大值 |
|
| Servlet高速缓冲 |
启用 |
| 允许线程分配超过最大线程大小 |
不允许 |
2) 测试模式
GameServer服务器：
|
|
应用服务器 |
数据库服务器 |
| 机器型号 |
|
|
| CPU |
|
|
| Ｍemory |
|
|
| Disk |
|
|
| 网卡 |
|
|
| 操作系统 |
|
|
| 数据库 |
|
|
| 系统版本 |
|
|
RoleServer服务器：
|
|
应用服务器 |
数据库服务器 |
| 机器型号 |
|
|
| CPU |
|
|
| Ｍemory |
|
|
| Disk |
|
|
| 网卡 |
|
|
| 操作系统 |
|
|
| 数据库 |
|
|
| 系统版本 |
|
|
TongServer服务器
|
|
应用服务器 |
数据库服务器 |
| 机器型号 |
|
|
| CPU |
|
|
| Ｍemory |
|
|
| Disk |
|
|
| 网卡 |
|
|
| 操作系统 |
|
|
| 数据库 |
|
|
| 系统版本 |
|
|
MonitorServer服务器
|
|
应用服务器 |
数据库服务器 |
| 机器型号 |
|
|
| CPU |
|
|
| Ｍemory |
|
|
| Disk |
|
|
| 网卡 |
|
|
| 操作系统 |
|
|
| 数据库 |
|
|
| 系统版本 |
|
|
备用服务器
网络设备：
| 网络类型 |
带宽 |
设备 |
数量 |
| 局域网 |
100Mb |
Xingnet nes-1016 16 port N-way Switch |
1 |
网络结构：
| 网络结构 |
带宽 |
连接设备 |
| 星型 |
|
|
数据库及服务器参数：
| 参数名 |
建议值 |
| 数据库连接池 最大值 |
|
| Servlet高速缓冲 |
启用 |
| 允许线程分配超过最大线程大小 |
不允许 |
3. 软件环境：
1) 生产模式
GameServer版本：
| 版本名 |
SVN路径 |
|
|
|
更新资源列表：
| 更新内容 |
SVN路径 |
|
|
|
2) 测试模式
GameServer版本：
| 版本名 |
SVN路径 |
|
|
|
更新资源列表：
| 更新内容 |
SVN路径 |
|
|
|
4. 登陆模式：
1) 实际用户
待确定（登陆的过程及逻辑流）
2) 测试用户
待确定（登陆的过程及逻辑流）
备注：
测试机器人通过测试账户进行加载，加载前务必保证所使用的机器人账户，已经在测试环境中的账户服务器内。若账户服务器内不存在需要加载的机器人账户，则在实际加载过程中，服务器因需要重新创建账户资源，在用户以特定加载方式登录服务器后，其稳定时间需要较长时常。
5. 环境度量：
1) 度量标准
a) 通过标准硬件设备的TPC-C值进行度量
b) 通过每百人加载的标准资源消耗进行度量
c) 通过数据传输介质的最大瓶颈进行度量（后期）
2) 度量计算
a) 实际测试结果＝测试预期结果*综合度量系数
b) 综合度量系数＝可实现度量标准(b)
2) 建立有效的基准测试数据
1. 数据指标
1) 筛选指标压测方案
a) 测试策略
使用压力与负载测试方法，主要对服务器各压力点下系统资源进行有效度量与评估，并在持续加压过程中确定服务器在最大负载下的各指标阀值。通过建立测试评估标准，缩小服务器性能指标范围，最终确定较为准确的测试指标。
b) 测试方法
手工监测方法：主要使用Linux自带的参数命令（如：top、free、ps、df等）
、使用CentOS对应版本的Sysstat性能测试包（如：sar、iostat、mpstat、sadc等）。
自动监测方法：主要使用LoadRunner对gameserver服务器、dbserver服务器（mysql）、monitor本机、robot压力机进行监控，使用cacti对局域网内所有服务器进行资源监控。（如：各服务器、交换机、集线器等）
c) 测试环境
硬件设备：（如本档开头所示）
软件环境：（本次测试指标，均参考该版本作为性能基线）
GameServer版本：
| 版本名 |
SVN路径 |
|
|
|
更新资源列表：
| 更新内容 |
SVN路径 |
|
|
|
d) 测试场景
模拟目标用户进入测试服务器，并在登陆动作结束后判定其
| 并发人数 |
加压方式 |
| 100人 |
以比例单位时间方式进行加载（预计加载方式如：1：2：3：4…….，单位时间为10分钟） |
用户分布：
为了排除加载在同一个地图（理论的最大负载），出现的Obj峰值，而导致测试数据与外网数据无法对比的问题，我们调整了其加压的方式，以求更大限度的模拟外网服务器的性能消耗。虽在服务器初期加载时，所有地图资源及任务py脚本以随服务器完全加载完成。但在实际调用过程中，由于机器人登陆到某地图场景，服务器需要以此响应该地图周围9格内的数据地图信息。由此，我们判断由于存在更大流量的数据交互，则对应服务器的压力也会相应增加。
| 出身城市 |
地图号 |
加压比例（预计总并发用户：1200人） |
| 成周 |
|
40％ |
| 新手城 (晋阳) |
|
5％ |
| 新手城 (姑苏) |
|
5％ |
| 新手城 (纪南) |
|
5％ |
| 新手城 (临) |
|
5％ |
| 师门任务 （8个职业） |
|
每个师门5% |
备注：有关加载时间估量方法，也在本次试验数据内进行测试。
有关更为准确的服务器负载加载方式，待研发方面提供了详细Log日志后，在进行相应的数据分析。
e) 测试范围
预计监测性能指标：
1) Cpu（使用率）
2) Cpu（使用时间）
3) LoadAverage（系统平均负载）
4) Mem（使用率）
5) Network card（负载平衡，发送与接受数据平衡）
6) I/O（磁盘I/O，读取与写入数度及倍速关系）
7) Swap（磁盘交换空间）
f) 测试准备
1) 测试环境准备完成
2) 测试数据调试完成（备注：根据服务器数据备份周期，本次性能指标选取测试及基准数据测试，均建立在备份周期中最大数据量得基础上进行有效测试。）
g) 测试用例
| 基础数据量 |
场景编号 |
对应功能点 |
并发数 |
运行方式 |
监控指标 |
监控方式和工具 |
| 0年数据量 |
1 |
Cpu 使用率 |
1200人 |
每20分钟增加100个用户直到1200个 |
Sar –u –t 5 12 iostat -t -c 1 |
通过LoadRunner、Linux Sysstat、 Cacti等方式进行自动化监控并予以分析 |
| 2 |
Cpu 使用时间 |
LR监控 System |
||||
| 3 |
LoadAverage 平均负载 |
LR监控 0 5 10 |
||||
| 4 |
Mem 使用率 |
vmstat -S K 1(单位：kb) |
||||
| 5 |
I/O 磁盘 |
Iostat –d 1 |
||||
| 6 |
NetWork 网卡 |
|
||||
| 7 |
|
|
||||
| 8 |
|
|
||||
| 9 |
|
|
||||
| 10 |
|
|
||||
| 11 |
|
|
h) 归纳统计
2) 建立长期外网监控
a) Cacti数据监控
b) LoadRunner数据监控
c) Shell脚本的数据监控
2. 数据量
1) 建立有效的测试模式数据度量标准
a) 按照前一周的数据量进行估算，提取本周数据量
b) 分析增长量较大的表与字段，建立等量数据预估模型
3. 行为模式
1) 以周为单位， 分析当前玩家的行为模式，以前一周的数据作为本周性能测试用例的设计标准：
a) 城市（玩家数量分布、怪物数量（新的刷怪机制））
b) 动作（每个职业使用量前3的技能，后期对技能服务性能消耗进行统计）
c) 喊话（平均玩家的各频道的喊话条数）
d) 任务（根据本周任务的特点及常规任务完成数、并发点击数模拟网外玩家进行数据库操作。
4. 用户与加载时间比例
负载测试机器人稳定周期比例，恒定的标准吞吐量（现有的标准cpu、mem平均值）。