SOA 项目示例性能指标与测试.docx
- 文档编号:25208107
- 上传时间:2023-06-06
- 格式:DOCX
- 页数:23
- 大小:478.76KB
SOA 项目示例性能指标与测试.docx
《SOA 项目示例性能指标与测试.docx》由会员分享,可在线阅读,更多相关《SOA 项目示例性能指标与测试.docx(23页珍藏版)》请在冰豆网上搜索。
SOA项目示例性能指标与测试
SOA项目示例
某航空公司A,为完善其信息系统,需要对航线服务产品、客户服务、业务流程等进行整合。
一方面,现有系统缺乏对信息共享性、系统兼容性和接口标准规范的统一考虑,造成子系统之间的连接比较困难,应用和数据无法得到全面共享,系统间网状连接普遍存在。
随着子系统的不断增加,在业务和流程方面的整合将会因业务领域间的信息沟通障碍及子系统之间的紧耦合面临越来越多的困难。
在经过广泛的调研之后,A公司决定采用基于SOA架构的信息共享体系结构(ESB)建设信息共享平台,将现有的各应用系统之间可以共享、共用的数据和服务发布到共享平台上供其它业务使用。
图1.基于SOA/ESB的架构
.
由于采用基于标准的接口定义方式,使得各子系统间的耦合度大大降低,而且服务请求者与服务提供者不产生直接依赖,双方的独立变化均可以不对对方造成任何影响。
另一方面,统一的接口和高度的模块化使得业务流程的组装变得极为容易。
对于企业级应用而言,灵活性和可扩展性固然是极其重要的设计原则,但是如果以极大地牺牲服务性能为代价,则显然是不可取的。
相对于点对点的服务连接方式,ESB的引入不可避免地会对整体服务性能造成或多或少的影响,因此ESB本身的性能要作为设计之初的重要考量以及验收的重要指标。
测试策略
测试性能指标
对于大部分ESB项目而言,通常都需要覆盖到以下性能指标:
∙最大并发请求数。
ESB在该并发请求数的访问下,在一段时间内可以正常提供服务(满足响应时间、吞吐量、稳定性等指标)。
该指标的制定主要以业务高峰时段的运营历史数据作为依据,以保证系统在业务高峰时段能正常提供服务。
∙平均并发请求数。
ESB在该并发请求数的访问下可以稳定运行较长时间(满足响应时间、吞吐量、稳定性等指标)。
该指标的制定主要以普通时段的运营历史数据作为依据,以保证系统在大部分时间可以持续稳定运行。
∙最大平均响应时间。
ESB中各服务在稳定运行的情况下,在ESB内部处理请求的平均时间不超过最大平均响应时间。
该指标的制定与特定服务的复杂程度,并发请求数有密切联系,一般而言,1s以下的平均响应时间是可以接受的。
如果平均响应时间较大,将无法满足交互性需求。
∙吞吐量。
ESB在单位时间内成功处理的请求数。
该指标的制定主要以实际业务数作为依据,以保证系统的业务处理能力满足生产需求。
∙稳定性。
在较长的时间内(如7*24小时),ESB可以持续提供服务,并且请求响应成功率较高(比如>95%)。
该指标包含了稳定持续时间、平均并发请求数、成功率三部分。
对于航空公司而言,7*24小时的稳定持续时间是必要的,请求响应成功率也往往需要达到95%甚至更高。
∙服务能承受的压力极限。
即超过这个压力之后,将会导致服务的崩溃(此处需要对服务崩溃定义,如响应成功率低于5%,或平均响应时间超过3s等)。
该指标受服务器硬件性能影响较大,因此很难在测试之前进行预估。
通常这是作为一个检验性(而非验证性)指标,为生产维护和系统更新(如硬件更新)提供参考和建议。
∙最佳并发请求数。
ESB在该并发请求数的访问下,在一段时间内可以正常提供服务(满足响应时间、吞吐量、稳定性等指标),且平均响应时间最接近最大平均响应时间指标。
与第一条指标不同的是,最大并发请求数是以实际的运营数据作为依据,而最佳并发请求数则是作为一个检验性指标,为生产维护提供参考。
那么,围绕这些性能指标,如何进行ESB的性能测试呢?
先来看看基于ESB的请求-响应模型。
测试对象模型
以短信单发服务和航班查询服务为例,在生产环境中,它们的服务消息流如下图所示:
图2.实际生产中的消息流
图中的client可能为终端用户或其它子系统。
可以看到,消息流分为两段。
第一段是client和ESB内部服务之间的消息流,第二段是ESB内部服务和后台服务之间的消息流。
诚然,在真实生产中,ESB内部服务和后台服务缺一不可。
但是如果按上述模型进行性能测试,将面临以下问题:
∙我们的测试目的是验证ESB的引入对整个系统的影响,而不是端到端的性能。
∙通常而言,ESB内部的服务逻辑较为简单,因此影响端到端性能的主要因素是后台服务。
而后台服务种类繁多,功能各异,针对每个不同服务制定性能指标显然是不合理的。
∙后台服务可能是遗留系统,已经过单独的性能测试和生产运营的验证,不需要再次进行测试。
∙ESB与后台服务在实现上是独立的,在测试的时候某些后台服务可能尚未接入。
因此针对性能测试,不妨对系统进行闭环改造:
图3.更改后的消息流
client的请求报文经过ESB内部服务的处理后,不再发送给后台服务,而是模拟后台服务的响应报文,再经过ESB内部服务的处理,返回给client。
为了降低开销,我们将模拟的后台服务的响应报文设为固定报文。
而对于client而言,这个改动从某种程度上讲是透明的,因为请求报文与响应报文的格式均与生产环境完全一致。
确定了测试模型,下面就以短信单发和航班查询为例,介绍如何使用RPTforSOA进行性能测试。
回页首
测试场景
在介绍RPT之前,结合之前提到的性能指标,我们不妨罗列几个针对上述测试对象的典型性能测试场景:
∙短信单发/航班查询/混合服务在最大用户数下的平均响应时间(容量测试)
∙发送混合类服务请求,将负载用户逐渐增加,直至服务端崩溃,以检测服务负载能力的临界点(压力测试)
∙在最大用户数下持续执行测试一段时间(如7*24小时)(稳定性测试)
对于以上测试场景,涉及到的问题或需要测试工具具备的功能可能有:
∙高负载生成
∙测试数据的实时监控
∙动态报文
∙分布式负载
∙自定义图表
RPTforSOA是否具备这些功能?
接下来我们就围绕上述测试场景,逐步了解RPTforSOA以及如何利用RPTforSOA的各项特性解决测试中的问题,完成测试。
测试准备
IBM®Rational®PerformanceTester(RPT)是一款性能测试工具,它通过模拟一定量用户的各种操作来实现实际生活中的用户负载的虚拟,并且提供实时监控,图表生成等功能。
IBM®Rational®TesterforSOAquality则是RPT面向SOA测试的一个扩展。
本文所述RPTforSOA均是以上两个组件的集合。
构建RPTforSOA测试环境
引入测试系统后,整个测试环境的网络拓扑结构如下所示:
图4.测试环境
可以看到,RPT采用workbench-agent的部署模型,可以对agent进行分布式部署(关于分布式部署的细节问题,请参照分布式负载)。
Workbench负责脚本、Schedule的创建,agent的控制,测试数据监控等,而agent则是真实客户的模拟,负责请求报文的发送和响应报文的接收。
完整的请求-响应消息流路径为:
1.Workbench将测试信息传达给agent(多台同时),驱动agent进行测试活动;
2.Agent发送请求至loadbalancer;
3.Loadbalancer对请求进行分发,以轮询的方式按1:
1发送至两台ESBServer;
4.ESB内部服务对DB进行数据读写操作;
5.ESB内部服务处理完请求报文后,生成响应报文,按(3)
(2)
(1)路径返回,更新workbench的实时图表。
为了构建一个完整的高负载的分布式测试环境,我们需要安装(导入)以下组件(license):
1.IBM®Rational®PerformanceTester(RPT主体文件,安装于workbench)
2.IBM®Rational®TesterforSOAquality(RPTforSOA扩展,安装于workbench)
3.IBM®Rational®LicenseServer(LicenseServer,安装于workbench)
4.IBM®Rational®PerformanceTesterExtensionforSOAFloatingLicense(导入LicenseServer)
5.IBM®Rational®TestXYZVirtualTesterPackFloatingLicenseKey(XYZ为相应的虚拟用户数,如5000,导入LicenseServer)
6.IBM®Rational®AgentController(每台Agent机上均需安装)
如果要对ESBserver进行系统资源监控,则需要在server上开启/安装系统资源监控服务/工具(如rstatd,Tivoli等)。
回页首
RPT图形用户界面
RPT构筑于Eclipse框架之上,如果接触过Eclipse或其它基于Eclipse的产品,应该不会对RPT的图形界面感到陌生。
图5.RPTGUI
图5大图
默认的视图为Test(在这个视图可以方便地创建/配置/运行测试资源,并提供图形化支持),在TestNavigator中进行测试资源的CRUD操作。
当然也可以切换回Java视图,对原生的Java类进行更改。
图6.视图选择窗口
回页首
创建SOA脚本
以混合服务的容量测试为例,首要任务就是创建WebService测试脚本(对于短信服务和航班服务需要分别创建独立的脚本)。
测试脚本是RPT的基础单元之一,封装了服务URL,请求报文,期望响应报文,验证点等核心的测试业务逻辑,是测试必不可少的组成部分。
在RPT中可以很方便地通过图形化的方式进行测试脚本的创建和配置。
通常来说,可以以录制或手动的方式来创建测试脚本。
对于SOA测试而言,手动创建脚本是个较好的选择。
以下就简要介绍一下手动创建SOA测试脚本的步骤:
1.首先创建一个 testproject。
在菜单栏中选择 File->New->Others…,并在弹出页面中选取 Test->TestAssets->NewWebServiceTest。
图7.创建WebService测试脚本
1.依照创建向导进行配置,直至 SelectserviceCallInterface 这一步。
若之前未曾导入过WSDL文件,则需通过 Add... 先导入短信(航班)服务的WSDL文件(如果没有WSDL文件,但是知道服务URL,完整的请求报文等信息,也可在此导入任意WSDL,然后在配置脚本时更改报文内容,具体参照配置测试脚本一节),并选择需要测试的接口(我们的短信服务的WSDL文件中一共包含了5个接口的描述,选择短信单发接口)。
图8.选择WebService调用接口
1.在下一步:
ConfigureProtocol 中可以对网络协议相关的配置进行更改,比如服务URL,协议类别,方法,版本等。
图9.配置协议
1.点击 finish,测试脚本就创建完成了。
可以在 TestNavigator 的相应 testproject 下看到类似于
的图标。
回页首
配置测试脚本
我们可以看到,在创建测试脚本的过程中,只指定了请求报文和服务URL;而对于本次测试来说,不仅有请求响应成功率的指标,而且对于稳定性测试来说,如果有大量请求响应失败,显然也是不能忍受的,因此我们还需要设定期望响应报文,对真实响应报文进行验证。
期望响应报文无法在测试脚本的测试过程中进行指定,但是我们可以在完成脚本的创建后对其进行配置。
双击 TestNavigator 下的 script 图标,可以打开脚本配置的主窗体。
图10.测试脚本主窗体
主窗体由 TestContents 和 TestElementDetails 两部分组成,TestContents 是一个树型结构,点击不同层次的元素可以进行相应的配置。
默认情况下选择的是根元素,可以进行脚本级别的配置。
通常情况下对于这一层次保持默认配置即可。
点击 TestContents 的一级子元素,可以对请求报文进行配置。
图11.配置请求报文
图11大图
对于本次测试来说,需要关心的有:
∙Overview/Source:
请求报文(XML)的不同显示形式,会根据导入的WSDL自动生成。
在我们的测试中,由于已知完整的请求报文,打开Source选项卡,将里边的内容替换掉即可。
∙Protocol:
包含了网络协议相关的一些配置,也可以在此修改服务URL。
如果在WSDL文件中已经包含了正确的URL(参照创建SOA脚本),则此处无需修改。
∙SecurityforCall/Return:
报文中安全相关的配置。
安全头可以直接写入到Source中。
右键点击 TestContents 中的请求报文,选择 Add->WebserviceReturn,可以创建该请求报文的期望响应报文。
图12.添加返回报文
创建过程中有两个选择:
∙如果服务尚不可用,则创建空响应报文,并手动进行填充。
∙如果服务可用,则通过 Update 方式获取真实响应报文(一般而言,功能测试会先于性能测试完成,因此通过这种方式获取的响应报文往往是正确的。
当然如果不正确也可以在创建完成后进行修改)。
期望响应报文创建完成后,TestContents 显示如下:
图13.返回报文添加成功
回页首
报文验证
通常来说,具备输入,期望输出,测试步骤(对于本项目而言就是简单的发送报文),一个测试用例就算是完整了。
但是对于SOA测试而言,有些时候我们的期望输出并不是一个固定的静态报文,我们可能需要:
∙真实响应报文只要包含指定的报文段即算测试通过。
∙忽略命名空间的验证。
响应报文中部分XML元素的命名空间可能不是固定的,但我们并不关心它。
∙某个字段的值只需匹配一个正则表达式即算测试通过。
RPT提供了验证点(VerificationPoint)的概念,来解决上述问题。
验证点可以通过右键点击期望响应报文->Add->选择VP类别进行添加。
图14.验证点类别
目前RPT中支持四类验证点:
∙ContainVerificationPoint:
响应报文只需包含指定的报文段即算测试通过。
在VP中指定被包含的报文段。
∙EqualVerificationPoint:
真实响应报文须与期望响应报文相同才算测试通过。
事实上可以通过设置忽略譬如命名空间的验证(见下面部分)。
∙QueryVerificationPoint:
根据XPath表达式对响应报文进行查询,若节点数与期望节点数的关系符合配置项(大于/等于/小于),则算测试通过。
∙AttachmentVerificationPoint:
依据报文附件进行验证。
为我们的脚本添加EqualsVerificationPoint后,TestContents 更新如下:
图15.验证点添加成功
对于ContainVP和EqualVP,在 TestElementDetails 中可以设定是否验证命名空间/文本节点/XML属性:
图16.验证选项
由于本次测试中包含动态的命名空间,因此将命名空间的验证去掉。
回页首
PerformanceSchedule
测试脚本已经包含了测试的必备条件,可以直接运行,但是有以下问题:
∙无法指定负载数量、测试持续时间、ThinkTime等调度信息,虚拟用户数固定为1个,只会发送和接收一次报文。
∙缺少系统资源监控配置项,无法生成相应图表。
∙无法实现分布式负载。
∙无法实现其它较复杂的部署和调度功能。
通过PerformanceSchedule,可以很好地解决这些问题。
创建PerformanceSchedule的步骤非常简单,选择菜单栏上的 File->New->PerformanceSchedule 即可。
创建完成后,双击打开其主窗体,初始界面如下:
图17.PerformanceSchedule主窗体
图17大图
窗体结构与测试脚本类似。
初始情况下,右侧显示的是schedule全局的配置项,包含了一系列小项。
常用的配置项有以下这些:
UserLoad:
设置虚拟用户数,测试持续时间,虚拟用户变化规律(一开始就将虚拟用户加到最大,或以一定的速率逐渐递增)。
对于最大/平均/最佳并发请求数指标的验证,都可以在此设定并发数。
ThinkTime:
设置从接收到响应报文到发送下一个请求报文之间的时间间隔。
适当地选取ThinkTime,既能准确地再现真实场景,也能在保证并发数的情况下,减轻服务器与客户机的压力。
ResourceMonitoring:
服务器系统资源监控相关配置(参照测试执行)。
目前支持的数据源有:
∙IBMTivoliMonitoring
∙Unixrstatdmonitor
∙WindowsPerformanceMonitor
涵盖了绝大多数的操作系统。
Statistics:
测试过程中实时数据相关的一些配置,包括取样间隔,取样对象(取所有或部分虚拟用户的数据)等。
如果测试持续时间较长(比如稳定性测试),则应适当延长取样间隔(如30分钟取样一次),以提高结果图表的可读性,不同降低workbench的压力。
通过schedule的全局配置项可以满足我们绝大部分的需求,但有些配置需要针对单个UserGroup进行。
点击 ScheduleContents 中的UserGroup,ScheduleElementDetails 显示如下:
图18.UserGroup配置
在此可以指定group的大小(绝对值/百分比),以及group的位置(在分布式负载一节对此做详细介绍)。
接下来就可以对UserGroup添加测试脚本了。
由于7.0版本的一个问题,直接添加测试脚本将不会按照脚本中设定的持续时间运行,可以在UserGroup下先添加一个Loop(Duration设为Infinite),然后再在Loop下添加脚本即可。
完成后的ScheduleContents如下所示:
图19.添加Loop
回页首
分布式负载
分布式负载是性能测试工具一个很重要的特性,通过分布式负载,可以达到以下目的:
∙使测试更接近现实。
在生产环境中,很少有请求均来自于同一个地址的情况。
∙有效地降低客户机(Agent所在机器)的负载。
在虚拟用户数较大的情况下,客户机性能可能成为瓶颈,导致请求发送堵塞,甚至崩溃(值得注意的是,如果一台客户机足以承受负载,则增加客户机未必能提高性能,甚至可能起反作用)。
∙突破网络限制。
Workbench和服务器可能分属两个不同的子网,两者交互要经过路由器和防火墙,导致最后得出的响应时间极大地收到网络开销的影响。
通过workbench远程控制一台与服务器处于同一子网的agent,就可以解决这个问题。
现在考虑测试混合服务在最大用户数下的平均响应时间这个场景。
局域网内有两台客户机(192.168.0.33/34,见构建RPTforSOA测试环境),现在分别用它们发送短信单发和航班查询请求。
首先为performanceschedule添加一个新的UserGroup和测试脚本。
根据以前的运营统计数据来看,短信请求和航班请求的比率约为4:
6,因此设定两个UserGroup的groupsize分别为40%和60%。
图20.添加新的UserGroup
然后分别为每个UserGroup设置location(目标机器上必须已安装agentcontroller,参照构建RPTforSOA测试环境)。
图21.设置UserGroup的location
在ResponseTimevs.TimeDetails图表(测试执行一章中包含了更多关于测试图表的信息)中,可以看到不同请求的响应情况。
图22.ResponseTimevs.TimeDetails
回页首
数据池
数据池用以为测试提供可变值。
在创建测试脚本的时候,我们提供了输入值,测试步骤及预期输出,在测试的每一个迭代,我们发送完全一致的请求报文。
完全一致的报文可能导致以下问题:
∙与真实的情况不符。
在生产环境中,请求报文不会一成不变。
∙缓存问题。
由于服务端一直保存着该请求的响应报文的缓存,使得响应时间偏小。
使用数据池可以解决或部分解决这些问题。
以下以短信单发服务的短信内容为例,介绍如何为其添加数据池:
1.通过 File->New->Datapool 新建数据池。
图23.创建数据池
1.打开datapool,为其添加数据条目。
图24.为数据池添加记录
1.打开短信测试脚本,在 TestContents 中选择请求报文;在 TestElementDetails 的Overviewtab中右键点击短信内容字段的值,然后在弹出菜单中选择 SubstituteFrom->Datapoolvariable。
图25.设置为从数据池获取数据
1.选择datapool和指定列。
图26.选择数据池和指定列
1.选择datapool的访问模式:
Sequential,Random或Shuffled。
图27.数据池访问模式
1.添加完datapool后,相应行标记为绿色背景。
图28.数据池已添加
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SOA 项目示例性能指标与测试 项目 示例 性能指标 测试