2019, Vol. 28
随着大数据、云服务等新技术的出现, 原有传统型数据库, 很难满足新系统对数据操作的需求, 为提高数据访问速度, 内存非关系型数据库—实时库在新系统中的应用越来越广泛[1]. 评价一个实时库的好坏, 首先功能是否完备, 性能是否满足要求是两个至关重要的指标. 功能完备性是实时库的基本要求, 当前的主流实时库系统都能满足需要, 性能的优越性成了评价实时库的首要指标.
目前, 实时库测试特别是性能测试目前主要有两大难点: (1)在Linux系统上没有成熟实时库测试工具; (2)由于使用实时库的新系统规模庞大, 开发周期长, 短期内很难搭建集成测试环境, 即没有完善的测试环境. 针对以上情况, 根据实时库在新系统中的使用特性设计开发了实时库测试系统[2], 该测试系统能很好的支持实时库的性能测试和功能测试, 在一定程度上解决了目前实时库测试所面临的两大难题.
1 实时库实时性影响因素分析根据实际应用系统的业务特性及运行环境分析, 影响实时库实时性的因素主要包括: 批量读写、并发操作、内存占用情况和网络使用情况等, 接下来对以上几种因素做具体分析.
1.1 批量读写数据测试检验一次处理单条数据和一次处理多条数据对实时库模块的效率的影响, 具体影响程度需要进一步测试检验. 测试方法是改变测试用例, 把一定数量的数据如(100万条数据)按一次处理一条, 与一次处理多条, 并且一次处理条数逐渐增加, 统计处理完这100万条数据所用时间. 测试的目的就是要弄清楚批量和非批量处理之间的差别.
1.2 并发操作实时库一般为单线程处理, 面对高并发请求, 采用队列模式将并发访问变为串行访问,其本身没有锁的概念, 在实时库客户端对实时库服务器进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题, 这些问题均是由于客户端连接混乱造成[3,4]. 测试方法是采用几十个客户端同时向实时库服务器发送数据, 统计记录服务器处理时间.
1.3 内存占用测试检验系统内存余量对实时库服务器实时性的影响, 具体影响程度需要进一步测试检验[5]. 测试方法是改变测试用例, 分别在初始条件和满内存情况下进行基础实时性测试.
(1)初始条件: 刚启动实时库时进行, 内存占用900 MB/31.3 GB, 通过测试软件执行测试, 统计性能数据, 进行基础性能测试.
(2)满内存: 向实时库中写入数据使内存占用30.1 GB/31.3 GB, 通过测试系统执行测试, 统计性能数据, 进行基础性能测试.
1.4 网络使用测试检验实时库服务器网络部署对实时库模块的效率的影响, 具体影响程度需要进一步测试检验. 测试方法是改变测试用例, 通过网络部署实时库服务器与本机部署进行测试对比, 检验网络对实时库模块效率影响.
2 测试系统的设计及实现 2.1 测试系统整体结构设计实时库测试系统的整体结构如图1所示, 软件部分主要包括实时库测试软件, 实时库客户端和实时库服务端, (需要说明的是实时库客户端是以插件的形式嵌入到测试软件中了); 硬件部分包括部署测试软件和实时库客户端的PC机, 部署实时库服务的PC机, 以及连接服务端与客户端的千兆交换机. 具体使用时, 如果不考虑网络对实时库的影响, 也可以把测试软件、实时库客户端和服务端统一部署在一台PC机上, 这样可以不用千兆交换机.
|
图 1 实时库测试系统整体结构图 |
2.2 测试系统软件功能结构设计
测试系统软件的功能结构如下图2所示, 该实时库测试系统的软件部分主要包括测试用例编辑模块、测试用例执行模块、测试结果判定模块、性能指标统计模块和测试报告生成模块等五个功能模块[6,7], 以下具体介绍每个模块的功能及其实现机制.
|
图 2 实时库测试系统软件部分功能结构图 |
2.2.1 测试用例生成模块主要功能及实现机制
测试用例生成模块的主要功能是自动生成测试数据, 为了便于统计数据大小, 这里数据类型统一使用字符型, 可以单个添加数据, 也可以批量生成大量数据. 生成测试数据时, 按用户指定行数和每行字节数生成测试数据.
2.2.2 测试执行主要功能及实现机制测试执行送模块主要功能是通过调用客户端提供的接口实现与实时库服务器建立链接并写数据到服务器. 在执行用例时可以选择的测试项有: 功能测试、性能测试、同步测试、异步测试、并发测试和拷机等测试类型, 以及哈希、字符串、集合三种存储结构体的任一种进行测试执行.
当选择功能测试时, 测试执行结果打印到控制台上, 这样测试软件自动判定测试结果的同时, 测试人员也可以人工抽查判定, 能够增加测试的可靠性, 功能测试时, 三种存储结构可以同时测试. 选择性能测试时, 由于测试结果的打印会影响性能, 为了提高测试的精度, 就不在打印测试结果数据, 性能测试时, 需要统计性能数据, 只能选择一种存储结构进行测试. 同步测试与异步测试分别对应客户端提供的同步接口和异步接口, 实时库只有在写时才分同步和异步, 主要区别是同步写时, 写数据接口会有返回值, 通过返回值可以判断实时库是否写成功. 并发测试和拷机测试都是对实时库稳定性的测试, 测试时通常同时进行.
2.2.3 测试结果判定主要功能及实现机制测试结果判定模块主要功能是从服务器读数据并与写入数据进行比较, 若一致则实时库读写功能正常, 反之读写功能异常, 需要进一步判定是写异常或读异常. 其实现机制是调用实时库客户端提供的读接口, 读取数据并与测试数据进行比较, 自动判定测试结果.
2.2.4 性能指标数据统计功能及实现机制性能指标数据统计模块主要功能是自动统计并记录实时库处理数据的时间. 在性能测试时, 操作时间的统计, 是从下达操作命令开始, 到操作结束. 如果是同步写测试, 测试软件可以通过写数据接口的返回值判断写操作情况, 从而能精确的统计写操作时间; 异步写操作时, 由于接口函数没有返回值, 不了解写操作情况, 这里采用测试软件通过读到最后一条数据的时间判断写操作完成, 对于写上百级的数据, 操作一条数据的时间可以忽略. 统计读操作的时间是从下达读操作命令开始, 读到最后一条数据结束, 能够精确的统计.
2.2.5 测试报告生成模块的功能及实现机制该模块能够根据用户定制自动生word形式的成测试报告, 如, 按测试类型分, 可以生成性能测试报告, 功能测试报告; 按测试用例分可以生成单个用例的测试报告或多个用例的测试报告. 总之, 测试报告的形式多种多样, 用户可以灵活定制.
2.3 测试系统工作流程设计测试系统的工作流程如图3所示, 测试系统正常启动后, 首先设计测试用例即生成测试数据; 如果选择同步测试, 调用实时库客户端提供的同步写操作接口函数. 功能测试时, 调用实时库客户端提供的读操作接口函数; 判定读写的测试数据是否一致, 如果一致则实时库读写操作功能正常, 如果读写的测试数据不一致, 则实时库的读或写操作功能异常, 这时需要人工确认异常. 性能测试时, 测试系统自动统计读写操作时间. 拷机通常与并发测试同时进行, 调用实时库客户端提供的读操作接口函数; 判定读写的测试数据是否一致, 如果一致则实时库读写操作功能正常, 如果读写的测试数据不一致, 则实时库的读或写操作功能异常, 这时测试正常进行只是统计记录异常发生次数, 并统计拷机时间.
2.4 测试系统主界面的设计及实现测试系统的软件部分是在Linux系统上采用Qt/C++开发实现的, 开发环境使用Qt Creator. 系统主界面如图4所示, 主界面中有哈希、字符串、列表三种存储结构体的选择, 即向实时库服务器写数据时选择的存储结构; 发送次数是连续向服务器写的次数; 客户端数是并发测试时同时几个客户端向服务器写数据; 拷机延时是拷机时, 发送数据的时间间隔; 数据类型统一采用字符型, 可以单条生成数据也可以大批量生成数据; 最后就是时间统计, 即发送测试数据时间统计、接收测试数据时间统计和拷机时间记录.
3 测试系统的应用及效果本测试系统在某公司大型新系统的研发测试过程中得到广泛的应用并进行了不断的完善, 本次测试采用开源实时库redis-3.2.6为测试对象. 一台PC机做客户端部署测试软件和实时库客户端, 一台服务器部署redis服务, 一台千兆交换机, 系统整体部署结构如图1所示. 具体硬件信息如表1.
应用本测试系统分别对实时库进行大批量的读写操作, 测试其功能、性能, 以及并发、内存、网络对其性能的影响. 具体测试情况如下.
3.1 批量读写对性能的影响测试选择string存储结构体做测试对象, 应用测试系统进行测试, 测试结果如表2.
通过测试结果发现, redis实时库在处理数据时, 将一次处理单条数据改为一次处理多条, 读写性能显著提高. 所以在开发过程中建议使用批量处理, 即每次发送多条数据, 以提高实时库的性能.
3.2 并发对性能的影响测试选择string存储结构体做测试对象, 应用测试系统进行测试, 测试结果如表3.
经过测试发现, redis在并发操作中性能提高明显, 建议适当使用并发操作, 以提高redis时库模块读写性能.
|
图 3 实时库测试系统工作流程图 |
|
图 4 实时库测试软件框架主界面 |
|
表 1 测试系统硬件配置信息 |
|
|
表 2 String类型的value值为4字节(单位: ms) |
|
|
表 3 统计Redis进行1 000 000次访问的性能(单位: r/s每秒处理的请求个数) |
3.3 内存对性能影响测试
为测试系统内存余量对redis性能的影响, 分别在初始条件和满内存情况下进行基础性能测试, 具体测试如下 (该数据在单机模式下统计).
1)初始条件: 刚启动redis-server时进行, 内存占用900 MB/31.3 GB, 应用测试系统, 进行基础性能测试.
2)满内存: 向redis实时库中写入数据使内存占用30.1 G/31.3 G,应用测试系统, 进行基础性能测试.
3)单位: r/s(每秒处理请求个数).
具体测试结果如表4所示.
|
|
表 4 redis实时库在不同内存占用情况下的处理能力 |
经测试发现, 系统内存被耗尽时系统极不稳定, 满内存操作时命令执行失败一次. 性能较差, 建议使用4倍容量的内存.
3.4 网络对系统性能的影响不同部署方式下的服务器每秒处理请求数, 应用测试系统进行测试, 如表5所示.
|
|
表 5 网络部署和本机部署的性能比较 |
经测试发现, redis服务在处理数据时受网络影响非常大, 如果本机部署redis, 能获取10到20倍的性能. 集群情况下, 网络硬件、网速要求一定要高. 尽量减少远程写redis服务的情况, 采用本机部署redis服务可以提高redis写数据的速度.
3.5 应用效果使用本测试系统进行功能测试时, 发现两个典型问题: (1)大批量异步写操作时有写失败的情况存在,最终经多次测试验证得出, 异步写超过1000万条数据时, 实时库服务写服务出现异常, 有写失败情况. (2)非法写操作时, 实时库服务异常退出. 性能测试时, 除了掌握以上性能规律外, 还发现了一个有价值的问题, 当大批量异步写操作时, CPU占用100%, (当大批量异步写操作时实时库服务消耗CPU资源都比较多, 因为异步写操作两次操作之间没有时间间隔, 频繁写操作, 实时库服务出现异常)并提出很多宝贵的性能优化建议. 以上问题及建议得到了研发人员的高度认可, 充分体现了本测试系统的价值.
4 结论与展望影响实时库数据处理能力的因素有很多, 在对实时库(redis)为基础的实时库影响因素进行分析的基础上, 设计并开发了一套实用性很强的实时库测试系统. 经实际项目应用并完善, 目前, 该测试系统简单易用, 能在很大程度上提高测试的效率和可靠性, 从而进一步提升测试的整体质量. 并且该测试系统有较好的通用性, 其他类似软件的测试稍作修改也可以使用.
| [1] |
彭晖, 王瑾, 陶洪铸, 等. 适应横集纵贯智能电网调控系统实时数据库的设计. 电力系统自动化, 2016, 40(9): 118-123. |
| [2] |
张玉中, 姬希娜, 张超永, 等. 数字化保护装置自动测试系统. 计算机系统应用, 2015, 24(4): 90-95. DOI:10.3969/j.issn.1003-3254.2015.04.015 |
| [3] |
张磊, 陈宏君, 吴相楠, 等. 基于扩展103规约的保护装置通信与调试系统设计. 电力系统保护与控制, 2015, 43(21): 126-130. |
| [4] |
蒋湘涛, 贺建飚, 李楠. 电力信息采集的通用型通信规约解析系统研究与设计. 电力系统保护与控制, 2012, 40(9): 118-122. DOI:10.3969/j.issn.1674-3415.2012.09.021 |
| [5] |
王瑾, 彭晖, 侯勇. 基于共享内存的能量管理系统实时库非主键HASH索引. 电力系统自动化, 2011, 35(13): 72-76. |
| [6] |
王振华, 孙振华, 孙世杰. 继电保护CPU板卡自动测试系统及方法. 计算机系统应用, 2018, 27(12): 274-279. DOI:10.15888/j.cnki.csa.006642 |
| [7] |
温东旭, 杨辉, 王旭宁, 等. 电力保护装置保障性自动测试方案研究与实践. 电力系统保护与控制, 2015, 43(10): 135-138. DOI:10.7667/j.issn.1674-3415.2015.10.022 |