CN101990225A - 一种对版本上报消息处理流程的性能优化方法及装置 - Google Patents

Abstract

本发明公开了一种对版本上报消息处理流程的性能优化方法及装置，所述方法包括：当网管平台运行时，在内存中维护基站的基本信息；网管平台在通信层收到基站的版本上报消息后，提取其中的标识信息，并根据所述标识信息在内存中查询该基站的基本信息；若成功查询到该基站的基本信息，则采用此基本信息构造一个阻止版本继续上报消息发向基站。本发明通过将基站的基本信息存在统一网管平台的内存中，查询基站的基本信息只需在内存中进行，并且生成版本阻止上报消息只需在通信层中构造就可发向基站，从而优化了统一网管平台版本上报消息处理流程，有效提高版本上报消息处理效率并同时减少资源消耗。

Description

一种对版本上报消息处理流程的性能优化方法及装置

技术领域

本发明涉及通信技术领域，尤其涉及一种通信系统中对版本上报消息处理流程的性能优化方法及装置，尤其适用于处理大量同时上报的版本消息。

背景技术

在移动通信系统无线接入网络中，小型基站具有很多优势，适合于热点地区的信号覆盖，但这种小型基站覆盖区域较小，所以一般情况下都会有部署大量基站。

基站启动后会向统一网管平台中的版本管理模块发送当前的运行版本信息。统一网管平台的版本管理模块负责全网所辖基站的版本比较及更新，是保证基站稳定运行的关键手段。版本管理模块收到版本信息后向基站返回一个阻止继续上报消息。

网管平台方面应该尽早向基站发送反馈消息，这样一方面可以及时阻止基站继续上报版本信息，另一方面基站可以尽早结束上报线程，达到节省网管平台以及基站宝贵系统资源的目的。

在旧有处理流程中，参照图1所示，为现有的无线接入网络系统框图。如图中所示，版本管理模块的版本上报消息处理流程是通信层接到基站的上报消息将其转发给逻辑处理层，然后逻辑处理层通过查询数据库得到基站的基本信息再生成反馈消息通过通信层发送到基站。

网管平台从接收到基站的版本上报消息到将反馈消息发向网元，需要通过6个类的处理。处理版本上报消息和生成反馈消息所需时间较长，并且处理过程也需要创建多条线程导致资源占用也较大。反馈消息的构成需要基站的基本信息。为了获得基站的基本信息，需要在逻辑处理层从数据库读取该信息，导致版本上报信息需要在通信层和逻辑处理层转发多次，并且在转发中大多数类没做复杂的加工处理，大量的时间和资源浪费在了转发过程中。转发的过程中还创建了大量的对象实例和多条线程并且采用了Java的反射机制，导致网管平台宝贵资源的浪费，更使得反馈消息生成时间延长。

而且，基站侧在收到网管平台反馈消息之前都会维护一个发送线程，所以收到反馈消息的时间越长基站侧浪费的资源也就越多。

在极端情况下，大量基站同时启动并上报版本信息，此时网管平台服务器在短短几分钟内需要处理数千甚至数万条版本上报信息，对于优化前的处理流程来说，每条上报信息需要数秒的处理时间和多条处理线程，将会使服务器资源非常紧张甚至拖垮服务器。

发明内容

本发明所要解决的技术问题是提供一种对版本上报消息处理流程的性能优化方法及装置，有效提高版本上报消息处理效率并同时减少资源消耗。

为了解决上述技术问题，本发明提供了一种对版本上报消息处理流程的性能优化方法，包括：

当网管平台运行时，在内存中维护基站的基本信息；

网管平台在通信层收到基站的版本上报消息后，提取其中的标识信息，并根据所述标识信息在内存中查询该基站的基本信息；

若成功查询到该基站的基本信息，则采用此基本信息构造一个阻止版本继续上报消息发向基站。

进一步来说，所述标识信息为地址信息。

进一步来说，所述方法还包括：

将版本上报消息转发到逻辑处理层进行后续操作。

进一步来说，所述后续操作，包括：版本入库和版本下载。

进一步来说，所述方法还包括：

若在内存中无法查询到该基站的基本信息，则结束流程，放弃处理所述基站的版本上报消息。

为了解决上述技术问题，本发明还提供了一种对版本上报消息处理流程的性能优化装置，设置于网管平台，包括：

维护模块，用于当网管平台运行时，在内存中维护基站的基本信息；

查询模块，用于在网管平台通信层收到基站的版本上报消息后，提取其中的标识信息，并根据所述标识信息在内存中查询该基站的基本信息；

发送模块，用于在成功查询到该基站的基本信息，则采用此基本信息构造一个阻止版本继续上报消息发向基站。

进一步来说，所述查询模块提取的标识信息为地址信息。

进一步来说，所述装置还包括：

转发模块，用于将版本上报消息转发到逻辑处理层进行后续操作。

进一步来说，所述后续操作，包括：版本入库和版本下载。

进一步来说，所述查询模块，还用于当在内存中无法查询到该基站的基本信息，则结束流程，放弃处理所述基站的版本上报消息。

本发明通过将基站的基本信息存在统一网管平台的内存中，查询基站的基本信息只需在内存中进行，并且生成版本阻止上报消息只需在通信层中构造就可发向基站，从而优化了统一网管平台版本上报消息处理流程，有效提高版本上报消息处理效率并同时减少资源消耗。

附图说明

图1是现有的无线接入网络系统框图。

图2是本发明的对版本上报消息处理流程的性能优化方法流程图。

图3A-图3B是版本上报消息处理时序图及优化方案。

图4是原有流程与优化后返回阻止上报消息所用时间比较。

图5是原有流程与优化后在不同时刻JVM中的线程数量比较。

图6是本发明的对版本上报消息处理流程的性能优化装置结构示意图。

具体实施方式

本发明的主要思想是：当网管平台运行时，在内存中维护基站的基本信息，当需要基站的基本信息时无需读取数据库，而是直接从内存中取出相应信息。在构成反馈消息时利用内存中的基本信息直接构造反馈消息，从而不用经过逻辑处理层即可成功构造反馈消息。通过这种改进减少了读取数据库和网管平台内消息转发的时间消耗和资源消耗。

为使本发明的目的、技术方案和优点更加清楚，以下结合附图及具体实施例，对本发明作进一步地详细说明。

参照图2所示，为本发明的对版本上报消息处理流程的性能优化方法流程图，所述方法包括以下步骤：

步骤201：当网管平台运行时，在内存中维护基站的基本信息；

步骤202：网管平台在通信层收到基站的版本上报消息后就立即提取其中的标识信息，根据所述标识信息在内存中查询该基站的基本信息；

需要指出的是，所述标识信息是对基站进行唯一识别的信息，具体可以为地址信息，当然也可以是其他的可以对基站进行唯一识别的信息，比如还可以是网元的MAC(Mdium Access Control，媒体接入控制)地址或EID(电子序列号/Electronical ID)，本发明对此不加以限定。

步骤203：若成功查询到该基站的基本信息，则利用此基本信息构造一个阻止版本继续上报消息发向基站；

若无法查询到该基站的基本信息，则证明此基站没有在此网管平台注册，则无需处理此消息。

步骤204：阻止版本继续上报消息发送成功，将版本上报消息转发到逻辑处理层进行后续操作，如版本入库和版本下载。

需要说明的是，“组织版本继续上报消息发送成功”与“版本上报消息转发到逻辑处理层进行后续操作”是并行执行的，也就是说先启动“组织版本继续上报消息发送成功”动作，然后立即启动“版本上报消息转发到逻辑处理层进行后续操作”动作。在技术上实现是采用的多线程技术。

可见，通过上述的步骤，本发明生成版本阻止上报消息只需在通信层中构造就可发向基站，查询基本信息也只需在内存中进行。

具体来说，在具体实现中需要修改两个类：通信层的消息监听类和逻辑处理层的版本上报消息处理类。首先在逻辑处理层的版本上报消息处理类中将发送阻止上报消息的代码去掉。然后在通信层的消息监听类中添加发送阻止上报消息相关代码，这些代码可以从逻辑处理层的版本上报消息处理类中的相关代码进行修改得来。

在全部实现中，生成阻止上报消息有关代码与原有代码有较大区别。其原因是原有流程的上报消息从通信层到逻辑处理层又返回到通信层，在流转期间进行多次封装。而优化后流程只需从基站的上报的SNMP(Simple Network Management Protocol，简单网络管理协议)消息中直接提取基本信息，即可生成阻止上报消息。

如图3A所示，图中的线为原处理流程中消息转发的路径，可以看到在原流程中消息需要转发到逻辑处理层的版本上报消息处理类，在此类中查询数据库获得基站基本信息后再构造阻止上报消息。

如图3B所示，优化后的流程为在通信层的消息监听类中直接读取内存提取出基站的基本信息，并构造出阻止上报消息通过通信层SNMP消息处理类将阻止上报消息发回给基站。

通过对比图3A与图3B所示，可以清晰的看出优化后的流程减少了大量的消息转发，以达到节省资源和缩短消息生成的时间。另外，读取内存相对读取数据库所需的时间也减少了很多。

下面通过应用中的实例对优化前后所需的系统资源和时间进行测试统计。

对优化前后的消息反馈时间和系统资源两方面进行数据统计，实验使用的环境如下：

硬件环境：AMD双核2.5G主频；2G内存

软件环境：Windows XP SP3；网管平台版本V3.02.01.00B3；基站使用仿真基站(也在服务器本地运行)。

在本次测试中只模拟一个基站上电后上报版本数据的情况。网管平台服务器没有任何其他负载。基站使用的是仿真程序(只是用程序模拟基站进行一些必要消息的返回)，所以网络通信延迟和基站内部处理时间的长度都将比真实环境大大减少。

下面是优化前后在时间上的比较。

因为优化后反馈消息机制的性能基本不受上述因素的影响，而原有流程反馈消息机制的性能受上述因素影响较大，所以上面提供的理想环境将会使原有流程反馈消息机制的性能达到最好效果。图4中的数据就是在这种对原有流程十分有利的环境下两种性能参数对比。

图4是从统一网管平台的通信层监听器收到基站上报消息到反馈消息发送完为止的时间(纵轴)，共进行了4次试验(横轴)。从图表可以看到第一线条401所示的原有流程反馈消息所需时间至少都在3秒以上，而第二线条402所示的优化后反馈消息所需时间最多也只需半秒。

所述数据是在比较理想的测试环境下得到的，可以推断的是当服务器的负载压力上来后，原有流程的反馈时间将会更长。这是因为Java虚拟机可以调用的资源将会大大减少，而JVM(JAVA虚拟机)在运行时调用反射机制需要的资源将不能得到满足导致利用反射机制创建实例变得更慢。而在优化后的方案中由于不需要使用反射机制创建实例所以反馈消息的时间受服务器压力影响很少。

另外，时间的缩短也帮助基站节省下系统资源，如果网管平台能够早一刻将反馈消息发向基站不仅能减少基站重复发送版本上报消息的概率，而且还能使基站更早的结束发送线程，释放占用的资源，这些资源对于基站有限的系统资源来说是非常重要的。

下面对系统资源占用做比较。

下面通过Java虚拟机JVM中线程数量的多少来分析一下网管平台服务器端系统资源优化前后的情况，图5是在不同时刻统计的JVM中的线程数量。

图5中的第一线段数据501是通信层收到基站的版本上报信息时刻JVM中的线程数。第二线段数据502和第三线段数据503分别是原有流程和优化后反馈消息发向基站时刻JVM中的线程数。

从第二线段数据502与第一线段数据501的比较可以看出，为生成并发送反馈消息原有流程需要使用6条以上的线程，从第三线段数据503与第一线段数据501的比较可以看出，在优化后只需要1条线程。优化后的线程数量比原有流程平均减少了5条，可以推断当有大量基站同时上报时，节省的线程数量是很可观的。由于系统中的每条线程都会占用计算资源甚至是内存资源，所以线程数量的减少可以推断出系统计算和内存资源的节省。

设想如果有1000个基站同时上报版本那么优化后的系统就会比原有流程的系统中少开5000条左右的线程，节省的系统资源还是非常可观的。

参照图6所示，为本发明的对版本上报消息处理流程的性能优化装置，设置于网管平台，包括：

维护模块601，用于当网管平台运行时，在内存中维护基站的基本信息；

查询模块602，用于在网管平台通信层收到基站的版本上报消息后，提取其中的标识信息，并根据所述标识信息在内存中查询该基站的基本信息；

发送模块603，用于在成功查询到该基站的基本信息，则采用此基本信息构造一个阻止版本继续上报消息发向基站。

在本发明的一个优选实施例中，所述查询模块602提取的标识信息为地址信息。

在本发明的一个优选实施例中，所述装置还包括：转发模块604，用于在阻止版本继续上报消息发送成功后，再将版本上报消息转发到逻辑处理层进行后续操作。

其中，所述后续操作，包括：版本入库和版本下载。

在本发明的又一个优选实施例中，所述查询模块602，还用于当在内存中无法查询到该基站的基本信息，则结束流程，放弃处理所述基站的版本上报消息。

综上所述，优化后网管平台发送反馈消息的机制更加节省时间和系统资源，也更加适合在大规模基站的环境中运行。

需要指出的是，以上所述仅为本发明的优选实施例，并不用于限制本发明，对于本领域的技术人员来说，在不脱离本发明技术原理的前提下，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换等，均应包含在本发明的权利要求范围之内。

Claims (10)

1.一种对版本上报消息处理流程的性能优化方法，其特征在于，包括：

当网管平台运行时，在内存中维护基站的基本信息；

网管平台在通信层收到基站的版本上报消息后，提取其中的标识信息，并根据所述标识信息在内存中查询该基站的基本信息；

若成功查询到该基站的基本信息，则采用此基本信息构造一个阻止版本继续上报消息发向基站。

2.如权利要求1所述的方法，其特征在于，所述标识信息为地址信息。

3.如权利要求1所述的方法，其特征在于，所述方法还包括：

将版本上报消息转发到逻辑处理层进行后续操作。

4.如权利要求3所述的方法，其特征在于，

所述后续操作，包括：版本入库和版本下载。

5.如权利要求1所述的方法，其特征在于，所述方法还包括：

若在内存中无法查询到该基站的基本信息，则结束流程，放弃处理所述基站的版本上报消息。

6.一种对版本上报消息处理流程的性能优化装置，设置于网管平台，其特征在于，包括：

维护模块，用于当网管平台运行时，在内存中维护基站的基本信息；

查询模块，用于在网管平台通信层收到基站的版本上报消息后，提取其中的标识信息，并根据所述标识信息在内存中查询该基站的基本信息；

发送模块，用于在成功查询到该基站的基本信息，则采用此基本信息构造一个阻止版本继续上报消息发向基站。

7.如权利要求6所述的装置，其特征在于，所述查询模块提取的标识信息为地址信息。

8.如权利要求6所述的装置，其特征在于，所述装置还包括：

转发模块，用于将版本上报消息转发到逻辑处理层进行后续操作。

9.如权利要求8所述的装置，其特征在于，

所述后续操作，包括：版本入库和版本下载。

10.如权利要求6所述的装置，其特征在于，

所述查询模块，还用于当在内存中无法查询到该基站的基本信息，则结束流程，放弃处理所述基站的版本上报消息。

Images