huawei IBM OpenPower应用服务器性能测试报告Word文档格式.docx
《huawei IBM OpenPower应用服务器性能测试报告Word文档格式.docx》由会员分享，可在线阅读，更多相关《huawei IBM OpenPower应用服务器性能测试报告Word文档格式.docx（16页珍藏版）》请在冰豆网上搜索。
2.1.2被测系统测试组网6
2.1.3被测系统的硬件7
2.1.4被测系统软件7
2.2测试工具和资源8
2.2.1测试工具的主要组件8
3测试计划和执行情况8
3.1测试计划情况8
3.1.1呼叫控制测试目标8
3.1.2呼叫控制测试用例9
3.1.3呼叫控制测试方法9
3.1.4UI相关测试目标9
3.1.5UI相关测试用例10
3.1.6UI相关测试方法10
3.1.7录音性能测试10
3.2测试执行情况11
3.2.1呼叫控制11
3.2.2UI相关11
4测试重点及测试设计评估11
4.1呼叫控制性能测试11
4.2UI界面性能测试11
4.3录音性能测试11
5测试结果12
5.1UI测试-创建立即会议的性能12
5.1.1测试目的12
5.1.2操作说明12
5.1.3测试结果12
5.1.4测试结果说明和分析13
5.2UI测试-结束会议的性能13
5.2.1测试目的13
5.2.2操作说明14
5.2.3测试结果14
5.2.4测试结果说明和分析15
5.3UI测试-预订会议的性能15
5.3.1测试目的15
5.3.2操作说明：
15
5.3.3测试结果16
5.3.4测试结果说明和分析16
5.4UI测试-取消预订会议的性能17
5.4.1测试目的17
5.4.2操作说明17
5.4.3测试结果17
5.4.4测试结果说明和分析18
5.5UI测试-锁定会议、呼集的性能18
5.5.1测试说明18
5.6呼叫控制-系统日志打开，每分钟30个用户接入会议系统18
5.6.1测试过程18
5.6.2测试结果说明和分析19
关键词Keywords：
MEDIAX3600系统，UI，呼叫控制，会议管理
摘要Abstract：
本文描述了对MEDIAX3600系统性能测试所用的方法，环境，测试结果，及相关数据；
分析了性能测试的结果，总结了本次性能测试的经验，为下次性能测试提供了必要的建议。
缩略语清单Listofabbreviations：
Abbreviations缩略语
Fullspelling英文全名
Chineseexplanation中文解释
1文档说明
由于测试对象为华为新近研发的产品，目前尚未对外进行正式发售，因此该文档中所描述的系统名称、测试结果以及组网图在未经华为允许的情况下，不得对外扩散。
本文档只允许在IBM内部负责OpenPower产品的相关人员间进行传递，在未经华为许可的前提下，不得传递给其它IBM人员参阅。
2测试目的
MEDIAX3600系统性能测试用于发现系统的性能瓶颈，为开发人员优化系统提供参考；
发现系统的功能缺陷,了解系统的稳定性也是一个附带的目的。
同时验证系统在高性能高压力要求下功能是否正常。
3测试环境
3.1被测系统
3.1.1被测系统的主要组件
1MEDIAX3600系统服务器；
直接的被测系统电话会议系统的应用服务器；
通过调用MRS6100/SOFTX3000等的功能实现电话会议的功能；
属于应用服务器；
2MRS6100；
NGN网络的媒体资源服务器；
3SOFTX3000；
NGN网络的媒体网管控制器；
4NFS服务器；
MRS6100录音文件存放服务器；
5数据库服务器；
MEDIAX3600系统用数据库服务器；
3.1.2被测系统测试组网
图1MEDIAX3600系统性能测试组网图（被测系统）
3.1.3被测系统的硬件
MEDIAX3600系统服务器是直接的被测对象，MRS6100,SOFTX3000是间接的被测对象。
在本次的测试中数据库服务器，NFS服务器和MEDIAX3600系统共用相同的服务器硬件。
被测系统由以下硬件组成：
硬件环境
说明
数量
1
IBMOpenPower710服务器;
数据库服务器;
NFS服务器
2*1.65GHz-2G-73GBSCSIDisk
2
MRS6100
机框（XXX板*4）
3
SOFTX3000
机框
4
SOFTX3000BAM
windows2000server/PC
表1被测系统硬件表
3.1.4被测系统软件
被测系统软件部分主要由MEDIAX3600系统服务程序，Oracle数据库系统，NFS服务器等组成。
其中整个MEDIAX3600系统服务器后台由3个部分组成，分别是：
呼叫控制模块，会议管理模块，UI界面模块。
1呼叫控制模块
呼叫控制模块，通过协议层（SIP协议）调用MRS6100,SOFTX3000等的接口实现电话拨入会议，完成会议中的操作，会议中的通话，录音等呼叫控制功能。
2会议管理模块
会议管理模块，提供会议创建，结束，会场中的操作等功能，端口管理等功能，所有的操作实际上都是对MRS6100资源的管理，主要通过调用MRS6100提供的接口实现。
3UI界面模块
UI界面模块，提供对系统的管理和配置功能，为用户使用系统提供基本的基于浏览器的界面。
其客户端程序是IEweb浏览器，后台是Tomcatweb服务器。
实现方式是使用J2EE的技术框架。
通过JSP实现页面表示层，EJB实现业务逻辑，Oracle数据库存储数据,通过JDBC连接数据。
3.2测试工具和资源
3.2.1测试工具的主要组件
13GLT性能测试环境（硬件系统/软件系统）；
2LoadRunerV8.0（windows版本）；
3UMG8900机框；
4性能测试用脚本：
包括LoadRuner用的性能测试脚本，在Solaris上收集性能数据的测试脚本；
测试工具由以下系统组成：
说明（使用的计算机）
3GLT性能测试环境
UCC运行环境
运行在windows2000server上
UMG8900
机框，供3GLT与SOFTX3000连接
LoadRunerV8.0Controller
5
IAD
4个
6
PSTN电话
10部
表2测试工具和测试环境
4测试计划和执行情况
下面简单介绍测试计划和测试执行等情况，测试执行的具体结果和分析在1.5说明。
4.1测试计划情况
测试从3个方面分别进行：
呼叫控制，UI界面，录音性能。
其中会议管理的基本功能是后台程序，是通过呼叫控制和UI界面调用来体现的，所以不直接测试会议管理的功能，而是通过测试UI界面来间接测试。
4.1.1呼叫控制测试目标
1持续运行时间30分钟，每秒钟可以有多少电话接入会议；
2在系统允许的接入速度情况下，每个用户参加会议需要的时间，系统性能指标（内存，CPU，网络，磁盘等）；
3分别测试在系统日志关闭和打开的情况下，系统的性能指标（内存，CPU，网络，磁盘等）；
4.1.2呼叫控制测试用例
根据当前的测试资源和系统的可能表现，计划测试500路电话参加会议情况下的性能指标，考虑到电话加入会议的速度对系统的性能会有明显的影响，所以每个测试用例输入包括表格要素，一是接入的电话数量，一是接入的速度。
用例简单说明如下：
20电话/分钟
30电话/分钟
40电话/分钟
50电话/分钟
60电话/分钟
500电话
1
表3呼叫控制性能测试的用例表
1500路电话以每分钟20个电话的速度加入会议；
2500路电话以每分钟30个电话的速度加入会议；
3500路电话以每分钟40个电话的速度加入会议；
4500路电话以每分钟50个电话的速度加入会议；
5500路电话以每分钟60个电话的速度加入会议；
4.1.3呼叫控制测试方法
1创建4个120方的立即会议；
2通过3GLT连接SOFTX3000模拟电话接入，电话以一定的速度接入会议系统；
3等待会议系统运行一段时间（一般30分钟），然后关闭立即会议；
4等系统CPU恢复正常后，重复执行上面的操作；
总共2次；
4.1.4UI相关测试目标
测试验证会议相关的基本功能的性能指标，页面点击率/秒；
也就是系统可以支持的同时操作的用户数量；
完成每一个操作的平均时间；
已经系统的性能指标（内存，CPU，网络，磁盘等）；
4.1.5UI相关测试用例
UI部分综合了系统的多个模块的功能，包括呼叫控制，会议管理，会议录音等多个模块，能够间接的体现整个系统的性能。
计划列入重点测试对象，测试的内容主要包括以下测试内容：
1创建立即会议，系统的性能指标（内存，CPU，网络，磁盘等）；
2结束立即会议，系统的性能指标（内存，CPU，网络，磁盘等）；
3预定会议，系统的性能指标（内存，CPU，网络，磁盘等）；
4结束语定会议，系统的性能指标（内存，CPU，网络，磁盘等）；
5锁定/解锁会议，系统的性能指标（内存，CPU，网络，磁盘等）；
6通过web呼集电话，系统的性能指标（内存，CPU，网络，磁盘等）；
4.1.6UI相关测试方法
1通过LoadRuner录制单项操作的脚本，根据需要修改脚本，插入控制元素和参数等,以供Test使用；
2通过LoadRuner执行测试脚本Test；
3观察测试的结果，收集性能数据；
4等待系统CPU恢复正常，并确认系统还是出于正常运行的状态，重复上面的测试，连续2次。
4.1.7录音性能测试
理论上，录音不应该成为系统的性能瓶颈，其主要涉及磁盘和网络操作。
关键是每一路录音的流量较小，所以理论上性能要求较低。
计划测试50个会议同时录音情况下的系统性能。
测试方法如下：
1通过LoadRuner工具自动创建50个2方的立即会议，会议时长2小时，自动开始录音；
2通过3GLT输入配置100个任务模拟100路电话，全部加入会议系统，每个会议有两个用户加入，在第2个用户加入电话会议系统的时候，会有广播音播放；
3该广播音已经被替换成长度为30分钟的语音片，所以50个会议都会自动开始录音，长度为30分钟；
4.2测试执行情况
4.2.1呼叫控制
主要执行了以下几个用例：
1系统日志打开的情况下，每分钟有30个电话接入系统；
2系统日志打开的情况下，每秒钟1个电话接入系统；
3系统日志关闭的情况下，每秒钟1个会议接入系统；
4.2.2UI相关
测试基本按照计划执行，并准确收集了系统的性能指标。
详细结果参加第5节。
不同的是测试以任务数量为基准进行测试，每个功能按100个操作数量进行测试，如同时创建100个立即会议。
没有考虑执行的速度和每个任务需要的时间。
5测试重点及测试设计评估
5.1呼叫控制性能测试
是测试的重点，测试的目标明确，测试的方法容易实施。
但是需要熟悉测试工具3GLT的使用。
5.2UI界面性能测试
是测试的重点，测试的目标应该重新调整，应该关注的不是是否可以完成单项操作，而是系统实际的处理能力，如单位时间的点击数。
本次测试不易度量系统的性能，不易发现系统的规格和性能指标。
测试方法明确简单，容易实施，同样需要熟悉测试工具LoadRuner8的使用。
5.3录音性能测试
需要测试，但是因为测试资源和工具的原因，测试执行有一定的难度。
测试目标和方法都比较明确。
对测试工具有较高的要求，对测试的资源有较高的要求。
6测试结果
6.1UI测试-创建立即会议的性能
6.1.1测试目的
该部分内容主要是验证MEDIAX3600系统召开立即会议的性能。
此功能通过调用呼叫控制来创建会议，通过会议管理来调度创建会议操作。
性能结果体现了会议管理和呼叫控制的性能。
6.1.2操作说明
由于测试资源较少，为预订成功，每个会议只预订2方的会议，一共创建100方会议。
在LoadRuner8中通过集合点一次发出创建100方会议的请求。
按照测试方法中的步骤执行，重复操作2次，记录每次操作的服务器性能指标CPU,内存占用等，数据记录关系：
第一次占用CPU1/占用内存1
第二次占用CPU2/占用内存2
6.1.3测试结果
图1立即会议CPU占用
图2立即会议内存占用
6.1.4测试结果说明和分析
数据说明：
从中可以看到：
1两次的操作平均耗时约100秒时间，2估计CPU占用率应该是在计算端口数时达到最大，大致可达35%，3相应的，内存的增长主要是在这个时期。
可能存在的问题或性能提高：
1从内存占用图上，可以看到系统内存持续增长，这有可能是应用程序处理还存在一些问题。
2连续的执行过程中，第二次执行比第一次执行的CPU占用率略微高一点。
说明随着业务量的加大，硬件CPU没有出现雪崩式的增长。
这说明硬件内部有较好的控制。
6.2UI测试-结束会议的性能
6.2.1测试目的
该部分内容主要是验证MEDIAX3600系统结束会议的性能。
本功能相对操作简单，对性能的要求不高。
6.2.2操作说明
在LoadRuner8中通过集合点一次发出结束100方会议的请求。
6.2.3测试结果
图3结束会议CPU占用
图4结束立即会议占用
6.2.4测试结果说明和分析
同创建会议操作一样，CPU占用率基本控制在35％左右，内存基本稳定在700M左右，没有出现明显的内容都增现象。
6.3UI测试-预订会议的性能
6.3.1测试目的
该部分内容主要是验证MEDIAX3600系统预订会议的性能。
6.3.2操作说明：
本用例与创建立即会议相似，由于MRS扣板较少，为预订成功，每个会议只预订2方的会议，一共创建100方会议。
按照测试方法中的步骤执行，重复操作2次，记录每次操作的性能指标CPU,内存占用等，数据记录关系：
6.3.3测试结果
图5预定会议CPU占用
图6预定会议内存占用
6.3.4测试结果说明和分析
从中可以看到，两次的操作平均耗时约110秒时间。
CPU占用率，第一次由于资源分配和计算问题，CPU占用率较高，当第二次进行测试时，发现CPU占用率下降，保持在60％左右。
根据这个测试结果可以看出，在一定范围之内，随着业务的增加，CPU占用率呈现一种下降趋势，估计会在50％左右保持稳定。
6.4UI测试-取消预订会议的性能
6.4.1测试目的
该部分内容主要是验证MEDIAX3600系统取消预订会议的性能。
6.4.2操作说明
在LoadRuner8中通过集合点一次发出取消100方会议的请求。
6.4.3测试结果
图7取消预定会议CPU占用
图8取消预定会议内存占用
6.4.4测试结果说明和分析
数据说明
数据分析
内存和CPU占用率趋势与预定会议操作差不多，这里就不用再复述了。
6.5UI测试-锁定会议、呼集的性能
6.5.1测试说明
1.销定会议的操作，由于只是对相关会议状态进行置位，所以CPU占用及内存增长不明显。
6.6呼叫控制-系统日志打开，每分钟30个用户接入会议系统
6.6.1测试过程
总共3次；
6.6.2测试结果说明和分析
一般情况下，系统CPU会持续在65%以上，内存会持续增长，内存使用量控制在700M左右。
升级会员 