- 易迪拓培训,专注于微波、射频、天线设计工程师的培养
RFID中间件基准性能测试平台研究与设计
录入:edatop.com 点击:
1 引言
RFID是自动识别技术中的一种, 它利用射频方式进行非接触双向通信以达到识别的目的。RFID 技术由于其独有的优点,吸引力与日俱增。出于对市场前景的预期和简化RFID 系统建设、维护工作的需求, 一些大的软件公司( 如IBM, BEA, Microsoft等) 相继推出了各自的RFID 中间件产品。
RFID 中间件扮演的是RFID 读写器和应用程序之间的中介角色, 从应用程序端使用中间件提供的一组共通的ApplicationInterface (应用接口程序, API), 即能连到RFID 解读器, 读取RFID 标签资料。如此一来, 即使储存RFID 标签情报的资料库软件或后端应用程序增加或改由其他软件取代, 或者RFID解读器种类增加等情况发生, 应用端不需要修改也能处理, 省去多对多连结复杂维护的麻烦。
出于对RFID 中间件的重视, 为企业在实施RFID 系统时选择RFID 中间件产品提供参考, 有必要对RFID 中间件的性能进行测试。性能测试包括中间件处理下层读写器数据和支持上层应用程序调用的能力。现有的性能测试工具( 如LoadRunner, JMeter, Benchmark Factory 等) 存在着测试对象单一、测试结果不易比较等问题, 并不能满足测试的需要, 这就需要一套针对RFID 中间件基准性能的测试方法和测试平台。
2 参数选取及其测试方法
对于RFID 中间件的使用者而言, 关心的无外乎以下几个方面: 支持的读写器; 提供的应用程序接口; 并发处理的读写器数量、应用程序客户端数量; 吞吐量; 响应时间。对于一定的应用环境, 前两个是能不能使用的问题, 而后四个是使用效果的问题, 也就是本文所论述的基准性能问题。下文分别就这四个基准性能参数作了解释, 并给出了测试方法。
并发处理的读写器数量( NoR, Number of Readers) : 在一定的系统开销和应用程序客户端响应时间限制下, RFID 中间件能够同时处理的读写器数量。这里的读写器是指与RFID 中间件相连接, 且同时向RFID 中间件以一定的频率发送标签数据的读写器。在测试过程中, 监控系统资源占用( cpu 和内存使用率) 和应用程序客户端响应时间, 逐步增加发送数据的读写器数量, 当系统资源占用和响应时间达到限制值时, 就得到了NoR。
并发处理的应用程序客户端数量(NoC, Number of Clients) : 在一定的系统开销和应用程序客户端平均响应时间限制下, RFID 中间件能够同时处理发送操作请求的客户端数量。测试方法与NoR 类似, 通过监控系统资源占用和应用程序客户端平均响应时间, 逐步增加发送操作请求客户端数量, 当系统资源占用和平均响应时间达到限制值时, 就得到了NoC。吞吐量( Throughput) : 在一定的系统开销和客户端响应时间要求下, RFID 中间件能够处理的读写器端发送标签数据的频率。类似的, 通过监控系统资源占用和应用程序客户端响应时间, 逐步增加读写器发送数据的频率, 当系统资源占用和平均响应时间达到限制值时, 就得到了Throughput。
响应时间(RT, Response Time) : 应用程序客户端发送事件请求到RFID 中间件完成操作的时间间隔。测试方法相对简单,只需要通过应用程序客户端发送需要测试的操作请求, 记录其响应时间即可。
3 RFID 中间件基准性能测试平台
对RFID 中间件的测试涉及到两方面的测试数据来源: 读写器端的标签数据和应用程序客户端的操作请求。使用实际的读写器和应用程序进行测试面临两方面的问题: 1) 测试工作需要大量的读写器设备, 这需要大量的资金; 2) 搭建这么多设备所组成的测试环境, 工作量将极其巨大、复杂。一个切实有效的解决办法就是通过软件对读写器和应用程序进行仿真, 由虚拟读写器(Virtual Reader) 和虚拟客户端(Virtual Client) 向RFID中间件发送测试数据。
3.1 总体框架
基于虚拟读写器和虚拟客户端的RFID 中间件基准性能测试平台分为以下四个模块:
1) 虚拟读写器: 对读写器进行仿真, 生成标签数据, 与RFID 中间件进行通信。
2) 虚拟客户端: 生成对RFID 中间件的操作请求, 并记录响应时间。
3) 测试控制台: 根据测试模式控制虚拟读写器和虚拟客户端的运行, 监视系统资源占用情况, 记录测试数据。
4) 报告生成器: 由测试数据生成图形化测试报告。
为了降低测试平台的运行对测试结果的影响, 系统采用分布式架构, 即虚拟读写器、虚拟客户端以及RFID 中间件分别运行在局域网的不同计算机上。虚拟读写器、虚拟客户端与测试控制台之间的通信通过Web Service 实现。系统整体软件框架如图1。
RFID是自动识别技术中的一种, 它利用射频方式进行非接触双向通信以达到识别的目的。RFID 技术由于其独有的优点,吸引力与日俱增。出于对市场前景的预期和简化RFID 系统建设、维护工作的需求, 一些大的软件公司( 如IBM, BEA, Microsoft等) 相继推出了各自的RFID 中间件产品。
RFID 中间件扮演的是RFID 读写器和应用程序之间的中介角色, 从应用程序端使用中间件提供的一组共通的ApplicationInterface (应用接口程序, API), 即能连到RFID 解读器, 读取RFID 标签资料。如此一来, 即使储存RFID 标签情报的资料库软件或后端应用程序增加或改由其他软件取代, 或者RFID解读器种类增加等情况发生, 应用端不需要修改也能处理, 省去多对多连结复杂维护的麻烦。
出于对RFID 中间件的重视, 为企业在实施RFID 系统时选择RFID 中间件产品提供参考, 有必要对RFID 中间件的性能进行测试。性能测试包括中间件处理下层读写器数据和支持上层应用程序调用的能力。现有的性能测试工具( 如LoadRunner, JMeter, Benchmark Factory 等) 存在着测试对象单一、测试结果不易比较等问题, 并不能满足测试的需要, 这就需要一套针对RFID 中间件基准性能的测试方法和测试平台。
2 参数选取及其测试方法
对于RFID 中间件的使用者而言, 关心的无外乎以下几个方面: 支持的读写器; 提供的应用程序接口; 并发处理的读写器数量、应用程序客户端数量; 吞吐量; 响应时间。对于一定的应用环境, 前两个是能不能使用的问题, 而后四个是使用效果的问题, 也就是本文所论述的基准性能问题。下文分别就这四个基准性能参数作了解释, 并给出了测试方法。
并发处理的读写器数量( NoR, Number of Readers) : 在一定的系统开销和应用程序客户端响应时间限制下, RFID 中间件能够同时处理的读写器数量。这里的读写器是指与RFID 中间件相连接, 且同时向RFID 中间件以一定的频率发送标签数据的读写器。在测试过程中, 监控系统资源占用( cpu 和内存使用率) 和应用程序客户端响应时间, 逐步增加发送数据的读写器数量, 当系统资源占用和响应时间达到限制值时, 就得到了NoR。
并发处理的应用程序客户端数量(NoC, Number of Clients) : 在一定的系统开销和应用程序客户端平均响应时间限制下, RFID 中间件能够同时处理发送操作请求的客户端数量。测试方法与NoR 类似, 通过监控系统资源占用和应用程序客户端平均响应时间, 逐步增加发送操作请求客户端数量, 当系统资源占用和平均响应时间达到限制值时, 就得到了NoC。吞吐量( Throughput) : 在一定的系统开销和客户端响应时间要求下, RFID 中间件能够处理的读写器端发送标签数据的频率。类似的, 通过监控系统资源占用和应用程序客户端响应时间, 逐步增加读写器发送数据的频率, 当系统资源占用和平均响应时间达到限制值时, 就得到了Throughput。
响应时间(RT, Response Time) : 应用程序客户端发送事件请求到RFID 中间件完成操作的时间间隔。测试方法相对简单,只需要通过应用程序客户端发送需要测试的操作请求, 记录其响应时间即可。
3 RFID 中间件基准性能测试平台
对RFID 中间件的测试涉及到两方面的测试数据来源: 读写器端的标签数据和应用程序客户端的操作请求。使用实际的读写器和应用程序进行测试面临两方面的问题: 1) 测试工作需要大量的读写器设备, 这需要大量的资金; 2) 搭建这么多设备所组成的测试环境, 工作量将极其巨大、复杂。一个切实有效的解决办法就是通过软件对读写器和应用程序进行仿真, 由虚拟读写器(Virtual Reader) 和虚拟客户端(Virtual Client) 向RFID中间件发送测试数据。
3.1 总体框架
基于虚拟读写器和虚拟客户端的RFID 中间件基准性能测试平台分为以下四个模块:
1) 虚拟读写器: 对读写器进行仿真, 生成标签数据, 与RFID 中间件进行通信。
2) 虚拟客户端: 生成对RFID 中间件的操作请求, 并记录响应时间。
3) 测试控制台: 根据测试模式控制虚拟读写器和虚拟客户端的运行, 监视系统资源占用情况, 记录测试数据。
4) 报告生成器: 由测试数据生成图形化测试报告。
为了降低测试平台的运行对测试结果的影响, 系统采用分布式架构, 即虚拟读写器、虚拟客户端以及RFID 中间件分别运行在局域网的不同计算机上。虚拟读写器、虚拟客户端与测试控制台之间的通信通过Web Service 实现。系统整体软件框架如图1。