CN101771578B

CN101771578B - 一种网络性能检测方法及设备

Info

Publication number: CN101771578B
Application number: CN200810247302A
Authority: CN
Inventors: 张志宏; 罗治国; 周文辉; 徐萌; 王旭
Original assignee: China Mobile Communications Group Co Ltd
Current assignee: China Mobile Communications Group Co Ltd
Priority date: 2008-12-29
Filing date: 2008-12-29
Publication date: 2012-10-03
Anticipated expiration: 2028-12-29
Also published as: CN101771578A

Abstract

本发明公开了一种网络性能检测方法，包括：将采集到的服务器运行通信业务时的通信事件划分为多个信息集合，并且同一信息集合内的通信事件对应相同的通信业务，其中，每个通信事件对应运行所述通信事件的时间点；确定属于同一信息集合的相邻两个时间点，将所述相邻两个时间点的时间间距作为该相邻两个时间点中，前一个时间点对应的待检测的通信事件的执行时间；比较所述待检测的通信事件的执行时间与设定时间，根据比较结果确定与所述待检测的通信事件相关的服务器性能。通过本发明，可以直观和有效的发现性能可能出现问题的服务器。本发明还公开了一种网络性能检测设备。

Description

一种网络性能检测方法及设备

技术领域

本发明涉及通信领域，尤其涉及一种网络性能检测方法及设备。

背景技术

目前，对于用户请求的网络服务大多采用三层结构实现：第一层是表示层，由web服务器向用户提供交互接口，接收用户请求的通信业务；中间层为应用层，提供应用处理逻辑；第三层为数据层，通过数据库或者文件系统提供数据的存储和访问。对于比较复杂的通信业务，应用层还可以进一步扩展为多层。网络服务的多层结构提供了处理流程的松散耦合，各层之间通过标准的网络协议进行通信，从而交互完成用户请求的通信业务，同时，该结构具有很好的可扩展性，可以根据需要增加每一层的服务，从而提高系统服务性能。

然而，这种多层结构的分布式并发网络服务系统的结构复杂，很难对请求的通信业务的处理流程进行检测，当系统出现性能问题时，无法确定性能瓶颈位于哪一层，更无法确定性能问题是由哪一个服务器引起的。

为了解决上述问题，现有技术提出了一种路径跟踪方案，其主要思想是：运行通信业务的服务器确定所述通信业务的执行路径，进而对确定的所述通信业务的执行路径进行分析，从而查找出性能出现问题的服务器。

具体地，路径跟踪方案的执行过程如图1所示，一个三层结构的并发网络服务系统正在对两个并发的通信业务（通信业务1和通信业务2）提供服务，确定出通信业务1和通信业务2的执行路径，然后根据执行路径依次判断每个服务器是否存在性能问题。

对于大规模并发服务系统，每秒钟需要处理成千上万条并发的通信业务，这些通信业务由并发的线程独立处理，很难确定每一个通信业务对应的执行路径，因此，利用路径跟踪方法确定系统性能瓶颈的方案实现困难。

发明内容

本发明实施例提供一种网络性能检测方法及设备，可以直观和有效的发现通信系统的性能瓶颈。

一种网络性能检测方法，所述方法包括以下步骤：按照时间点的先后顺序，判断采集的通信事件是否是通信业务的路径创建事件，若是，则为该通信事件对应的通信业务创建信息集合，并将该通信事件划分到创建的信息集合中；否则，确定为该通信事件对应的通信业务已创建的信息集合，并将该通信事件划分到所述已创建的信息集合中，其中，每个通信事件对应运行所述通信事件的时间点；

确定属于同一信息集合的相邻两个时间点，将所述相邻两个时间点的时间间距作为该相邻两个时间点中，前一个时间点对应的待检测的通信事件的执行时间；

比较所述待检测的通信事件的执行时间与设定时间，根据比较结果确定与所述待检测的通信事件相关的服务器性能，所述设定时间为：待检测的通信事件对应的通信业务中运行所述待检测的通信事件的预先设置的时间。

一种网络性能检测设备，所述设备包括集合划分模块、执行时间确定模块、时间比较模块和性能确定模块，其中：

集合划分模块，用于将采集到的服务器运行通信业务时的通信事件划分为多个信息集合，并且一个信息集合内的通信事件对应相同的通信业务，其中，每个通信事件对应运行所述通信事件的时间点；时间比较模块，用于比较所述待检测的通信事件的执行时间与设定时间，所述设定时间为：待检测的通信事件对应的通信业务中运行所述待检测的通信事件的预先设置的时间；

性能确定模块，用于根据比较结果确定与所述待检测的通信事件相关的服务器性能；

所述集合划分模块包括：

事件类型判断子模块，用于按照时间点的先后顺序，判断采集的通信事件是否是通信业务的路径创建事件；

执行子模块，用于在判断结果为通信事件是路径创建事件时，为该通信事件对应的通信业务创建信息集合，并将该通信事件划分到创建的信息集合中；在判断结果为通信事件不是路径创建事件时，确定为该通信事件对应的通信业务已创建的信息集合，并将该通信事件划分到所述已创建的信息集合中。

本发明实施例通过采集服务器运行的通信事件，并按照对应的业务将通信事件划分为多个信息集合，然后将属于同一集合中相邻两个时间点的时间间距作为该相邻两个时间点中，前一个时间点对应的待检测的通信事件的执行时间，通过比较执行时间与设定时间，确定与通信事件相关的服务器性能，因此，在不需要确定通信业务的执行路径的情况下，方便地检测出可能出现问题的服务器，进行可以检测出在通信系统的哪一层出现性能瓶颈。

附图说明

图1为背景技术中路径跟踪方案示意图；

图2为本发明实施例一中网络性能检测方法示意图；

图3为本发明实施例二中网络性能检测设备结构示意图。

具体实施方式

为实现本发明目的，本发明实时侦测通信网络中运行通信业务的服务器中发送消息或接收消息的通信事件，然后将对应同一通信业务的通信事件集合在一起，获得通信业务执行过程的通信事件及各通信事件的执行时间，从而可以根据通信事件的执行时间直观和有效的发现性能可能出现问题的服务器，进而确定通信系统的性能瓶颈位于多层结构的哪一层。

下面结合具体实施例对本发明方案进行详细描述。

如图2所示，为本发明实施例一中网络性能检测方法示意图，该方法包括以下步骤：

步骤101：采集服务器运行通信业务时产生的通信事件，以及每个通信事件对应的运行所述通信事件的时间点。

服务器运行的通信事件包括：通信业务的消息接收事件、通信业务的消息发送事件；如果服务器是通信业务入口服务器，运行的通信事件还可以包括通信业务的路径创建事件；如果服务器是通信业务出口服务器，运行的通信事件还可以包括通信业务的路径断开事件。路径创建事件是指通信业务开始时，服务器为响应用户发送的业务请求而执行的创建一条执行路径的事件，此时代表一条执行路径的开始；路径断开事件是指通信业务结束时，服务器执行的结束执行路径的事件，代表一条执行路径的结束。在本发明实施例中涉及的执行路径是指通信业务从开始至结束，数据在各服务器中的流向。

出口服务器和入口服务器可以是表示层中的Web服务器。

步骤102：将采集的通信事件划分为多个信息集合，并且同一信息集合内的通信事件对应相同的通信业务。

本步骤的具体执行方式为：

按照通信事件运行的时间点的先后顺序，判断采集的通信事件是否是通信业务的路径创建事件。

若是通信业务的路径创建事件，则为该通信事件对应的通信业务创建一个信息集合，并将该通信事件划分到新创建的信息集合中；

否则，确定为该通信事件对应的通信业务已创建的信息集合，并将该通信事件划分到所述已创建的信息集合中。

具体包括：将采集的通信事件按照运行的时间点的先后顺序排列，然后依次选择一个通信事件，对选择的通信事件的类型是否为路径创建事件进行判断。如果选择的通信事件是路径创建事件，表示入口服务器针对用户发起的通信业务建立了通信连接，开始运行该通信业务，因此，需要为该通信业务新创建一个信息集合。如果选择的通信事件不是路径创建事件，表示之前已经为选择的通信事件对应的通信业务创建了信息集合，因此，可以将该选择的通信事件直接划分至已创建的信息集合中。

本发明中的信息集合划分方式是以“划分后的一个信息集合中的通信事件对应一个通信业务”为原则，上述方式只是本发明涉及的划分信息集合的一种方式，本发明实施例并不限于其他划分信息集合的方式。

步骤103：确定属于同一信息集合的相邻两个时间点，将所述相邻两个时间点的时间间距作为该相邻两个时间点中，前一个时间点对应的待检测的通信事件的执行时间。

为了检测网络性能，需要检测各服务器运行通信业务中通信事件的执行时间，如果通信事件的运行时间较短，表明服务器有足够的能力处理通信业务中的通信事件，因此，与通信事件相关的服务器性能能够满足业务需要，网络性能较好；如果通信事件的执行时间较长，表明服务器当前业务负荷较大，可能很难正常处理通信业务中的通信事件，因此，与通信事件相关的服务器性能不能满足业务需要，网络性能较差。

步骤104：比较所述待检测的通信事件的执行时间与设定时间，根据比较结果确定与所述待检测的通信事件相关的服务器性能。

所述设定时间为：待检测的通信事件对应的通信业务中运行所述待检测的通信事件的预先设置的时间。

在步骤102中划分的信息集合不仅可以对应一个通信业务，进一步地，在一个信息集合内的通信事件还可以由同一服务器运行。在此情况下，若比较结果是待检测的通信事件的执行时间大于设定时间，则确定运行所述待检测的通信事件的服务器性能不能满足通信业务的要求；否则，确定运行所述待检测的通信事件的服务器性能能够满足通信业务的要求。

另外，如果确定的所述相邻两个时间点分别对应的两个通信事件由同一服务器运行，且比较结果是待检测的通信事件的执行时间大于设定时间，则运行待检测的通信事件的服务器性能不能满足通信业务的要求；否则，运行待检测的通信事件相关的服务器性能能够满足通信业务的要求。

如果确定的所述相邻两个时间点分别对应的两个通信事件分别由两个服务器运行，且比较结果是待检测的通信事件的执行时间大于设定时间，则只能确定运行上述两个通信事件的两个服务器中的一个或两个的性能不能满足通信业务的要求；否则，运行上述两个通信事件的两个服务器的性能都能够满足通信业务的要求。

针对一个信息集合，可以多次执行步骤103和步骤104，直至确定一个信息集合内的全部通信事件相关服务器的性能。

步骤105：将待检测的通信事件所在的信息集合删除。

如果一个信息集合中所有的通信事件都已检测完毕，可以删除该信息集合。此时可以重新返回步骤103，对还未处理的其他信息集合中的通信事件进行处理。

通过本发明实施例一的方法，可以在不确定通信业务执行路径的情况下，方便地检测出性能不满足通信业务要求的服务器，查找出系统性能瓶颈；进一步地，如果将一个信息集合中通信事件按照时间点的先后顺序排列，并且确定执行各通信事件的服务器，则可以快速地确定出通信业务从开始至结束的数据流向，得到通信业务的执行路径。在得到与通信业务的执行路径后，可以通过聚类分析算法对执行路径进行分类，并对同类执行路径进行均值分析，从而获得具代表性的路径模型，并自动分析该路径上消耗时间最长的通路，从而发现潜在的性能瓶颈。

下面对本发明实施例一的各步骤进行详细说明。

以TCP通信业务为例，在步骤101中，以分布式系统为例，可以对分布式系统的通信行为进行动态侦测，并记录相应的通信事件。其具体操作方法可以为：在Linux操作系统编写内核模块，并且在与TCP通信相关的核心函数的关键路径上插入断点，当应用层进行与TCP相关的通信操作调用并且执行到断点处，则会触发并纪录一个与该通信业务相关的通信事件。

与TCP通信业务相关的通信事件主要有：路径创建事件（Sys_accept）、路径断开事件（Sys_shutdown）、消息接收事件（Tcp_recvmsg）和消息发送事件（Tcp_sendmsg）。Sys_accept函数用于在接收到用户请求的通信业务时，创建一个TCP连接，即创建一个TCP通信业务的执行路径；Sys_shutdown函数用于在通信业务运行完成后关闭TCP连接，即结束TCP通信业务的执行路径；Tcp_recvmsg函数用于在内核TCP协议栈中接收消息；Tcp_sendmsg函数用于在内核TCP协议栈中发送消息。

采集的多个通信事件可以按照表1的格式记录原始日志消息。

表1

其中：timestamp是指通信事件运行的时间点，它是一个物理时间，单位为毫秒；cpu表示产生通信事件的cpu号；pid和tid表示通信事件发生的进程描述符和线程描述符；prog是指通信事件的进程的可执行程序名；action表示通信事件的类型，如消息接收事件、消息发送事件、路径创建事件或路径断开事件；如果通信事件的类型是消息接收事件或消息发送事件，则size表示消息的大小，如果通信事件的类型是路径创建事件或路径断开事件，则size表示一个文件描述符；Message_id表示产生通信事件的端到端通信通道的信息，其格式为“发送端IP地址：端口号-接收端IP地址：端口号”，其中，IP地址以32位整数的形式表示。

为了减少对现有通信系统的修改，可以将表1所示的原始日志消息转换为标准的ULF格式（Unified Log Format），如表2所示，以便于通信系统中现有的设备能够直接读取相关的信息。

表2

ULF格式的日志为{TIMESTAMP，TYPE，CONTEXT，MESSAGE，SIZE}格式的的五元组，其中：TIMESTAMP表示通信事件执行的时间点；TYPE表示通信事件的类型；CONTEXT表示事件发生的上下文信息，具有“hostname：cpu：execname：pid：tid”的标准格式，表示产生通信事件的cpu号和通信事件发生的进程描述符和线程描述符；MESSAGE与原始日志中message_id所表示的意义相同，只是ip地址被转化为可读的点分十进制表示形式；SIZE与原始日志中的size所表示的格式和内容相同。

根据通信事件发生的上下文信息可以确定该通信事件对应的通信业务。

ULF格式对表1中的通信事件类型进行了修改，以ULF格式的标准语言表示4种基本的通信事件类型，这4种标准语言为：BEGIN，END，SEND和RECEIVE。BEGIN等同于路径创建事件，代表一条因果路径的开始，END等同于路径断开事件，代表一条因果路径的结束，SEND等同于消息发送事件，代表一个发送消息的事件，RECEIVE等同于消息接收事件，代表一个接收消息的事件。

对于SEND和RECEIVE通信事件类型，可以通过tcp_sendmsg和tcp_recvmsg函数中的断点触发直接转化，即tcp_sendmsg或tcp_recvmsg函数的断点被触发急认为执行了消息发送事件或消息接收事件；而ULF格式的BEGIN和END通信事件类型，需要通过与应用通信协议相关的分析函数进行转化。例如，对于基于HTTP协议的通信业务，Web服务器通过80端口接收到客户端发来的请求事件可以转化为相应的BEGIN类型的通信事件，而通过该连接向客户端返回请求的响应结果的通信事件则可以转化为相应的END类型的通信事件。

在步骤102中，一个信息集合的具体表现形式可以是二叉树状结构，通过二叉树状结构中节点与子节点的关系，可以进一步表示通信业务的执行路径。将采集的通信事件划分为多个信息集合可以看作：对采集的ULF格式的日志消息进行处理，建立多个二叉树状结构，。

执行路径可以通过HBT（happen-before）关联算法对采集的通信事件进行关联产生。HBT关联算法的核心思想是利用分布式经典理论中的happen-before关系，将与某一通信事件进行关联。Happen-before关系的简单定义为：在一个分布式系统中发生的两个通信事件a和b，如果满足以下两个条件之一，则称这两个事件具有happen-before的因果关系：

（1）、a和b是发生在同一个线程上下文p中的两个事件；

如果a发生在b之前，a、b之间的关系表示为a-^c>b，称a和b之间具有上下文因果顺序。

（2）、a代表一个发送消息m的消息发送事件，b代表接收这个消息m的消息接收事件，a、b之间的关系表示为a-m>b，称a和b之间具有消息因果顺序。

具体地，二叉树状结构的创建过程如下：

第一步、从表2的日志消息中按时间顺序获取一个ULF格式的通信事件C；

第二步、判断通信事件C的类型，根据事件类型的不同以以下四种方式分别进行处理：

（1）、如果C是一个BEGIN类型的事件，则创建一个表示执行路径的二叉树结构，将C作为该二叉树的根节点；

（2）、如果C是一个SEND类型的事件，则按照happen-before关系的条件1，在已经存在的二叉树中搜索与C具有同一线程上下文且与执行的时间点最接近的事件P，将事件C作为事件P的子节点加入到P所在的二叉树中；

（3）、如果C是一个RECEIVE类型的事件，则按照happen-before关系的条件2，在已经存在的二叉树中搜索对其发送消息的事件P，将事件C作为事件P的子节点加入到P所在的二叉树中；

（4）、如果C是一个END类型的事件，则按照happen-before关系的条件1，在已经存在的二叉树中搜索与C具有同一线程上下文的根节点P。将根节点P所在的二叉树输出，即得到与通信业务相关联的执行路径。

第三步：判断表2中的通信事件是否全部执行完毕，若是，则信息集合划分完毕；否则，重复执行步骤1和2，直到表2中的通信事件全部执行完毕。

与本发明实施例属于同一发明构思下的，本发明实施例二还提供一种网络性能检测设备，如图3所示，所述设备包括：集合划分模块11、执行时间确定模块12、时间比较模块13和性能确定模块14，其中：集合划分模块11用于将采集到的服务器运行通信业务时的通信事件划分为多个信息集合，并且一个信息集合内的通信事件对应相同的通信业务，其中，每个通信事件对应运行所述通信事件的时间点；执行时间确定模块12用于确定属于同一信息集合的相邻两个时间点，将所述相邻两个时间点的时间间距作为该相邻两个时间点中，前一个时间点对应的待检测的通信事件的执行时间；时间比较模块13用于比较所述待检测的通信事件的执行时间与设定时间，所述设定时间为：待检测的通信事件对应的通信业务中运行所述待检测的通信事件的预先设置的时间；性能确定模块14用于根据比较结果确定与所述待检测的通信事件相关的服务器性能。

所述性能确定模块14可能在以下三种情况下对服务器的性能进行检测：

第一种情况：所述性能确定模块14进一步用于在一个信息集合内的通信事件由同一服务器运行时，若比较结果是待检测的通信事件的执行时间大于设定时间，则确定运行所述待检测的通信事件的服务器性能不能满足通信业务的要求，否则，确定运行所述待检测的通信事件的服务器性能能够满足通信业务的要求。

第二种情况：所述性能确定模块14进一步用于在所述相邻两个时间点分别对应的两个通信事件由同一服务器运行时，若比较结果是待检测的通信事件的执行时间大于设定时间，则确定运行所述待检测的通信事件的服务器性能不能满足通信业务的要求；否则，确定运行所述待检测的通信事件的服务器性能能够满足通信业务的要求。

第三种情况：所述性能确定模块14进一步用于在所述相邻两个时间点分别对应的两个通信事件由两个服务器运行时，若比较结果是待检测的通信事件的执行时间大于设定时间，则确定所述两个服务器中的一个或两个的性能不能满足通信业务的要求；否则，确定所述两个服务器的性能都能够满足通信业务的要求。

进一步地，所述集合划分模块11包括事件类型判断子模块21和执行子模块22，其中：事件类型判断子模块21用于按照时间点的先后顺序，判断采集的通信事件是否是通信业务的路径创建事件；执行子模块22用于在判断结果为通信事件是路径创建事件时，为该通信事件对应的通信业务创建信息集合，并将该通信事件划分到创建的信息集合中；在判断结果为通信事件不是路径创建事件时，确定为该通信事件对应的通信业务已创建的信息集合，并将该通信事件划分到所述以创建的信息集合中。

通过本发明实施例提供的方法和设备，可以在不找寻执行路径的情况下，确定网络系统中可能出现性能瓶颈的服务器，进而确定网络系统的性能，由于本发明从操作系统内核中获取通信业务的通信事件，不需要对应用程序、中间设备和通信设备进行改动，具有简单、通用和实用性强的特点。本发明所采用的方法不需要对应用层的用户代码或者中间件进行任何修改，更加简单和实用；另外，本方法采用了基于HBT关联算法，满足应用透明性的要求，且能够达到与现有方法同样的路径关联准确率。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种网络性能检测方法，其特征在于，所述方法包括以下步骤：

按照时间点的先后顺序，判断采集的通信事件是否是通信业务的路径创建事件，若是，则为该通信事件对应的通信业务创建信息集合，并将该通信事件划分到创建的信息集合中；否则，确定为该通信事件对应的通信业务已创建的信息集合，并将该通信事件划分到所述已创建的信息集合中，其中，每个通信事件对应运行所述通信事件的时间点；

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

在一个信息集合内的通信事件由同一服务器运行时，根据比较结果确定与所述待检测的通信事件相关的服务器性能，包括：

若比较结果是待检测的通信事件的执行时间大于设定时间，则确定运行所述待检测的通信事件的服务器性能不能满足通信业务的要求；否则，确定运行所述待检测的通信事件的服务器性能能够满足通信业务的要求。

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

在所述相邻两个时间点分别对应的两个通信事件由同一服务器运行时，所述根据比较结果确定与所述待检测的通信事件相关的服务器性能，包括：

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

在所述相邻两个时间点分别对应的两个通信事件由两个服务器运行时，所述根据比较结果确定与所述待检测的通信事件相关的服务器性能，包括：

若比较结果是待检测的通信事件的执行时间大于设定时间，则确定所述两个服务器中的一个或两个的性能不能满足通信业务的要求；否则，确定所述两个服务器的性能都能够满足通信业务的要求。

5.一种网络性能检测设备，其特征在于，所述设备包括集合划分模块、执行时间确定模块、时间比较模块和性能确定模块，其中：

集合划分模块，用于将采集到的服务器运行通信业务时的通信事件划分为多个信息集合，并且一个信息集合内的通信事件对应相同的通信业务，其中，每个通信事件对应运行所述通信事件的时间点；

执行时间确定模块，用于确定属于同一信息集合的相邻两个时间点，将所述相邻两个时间点的时间间距作为该相邻两个时间点中，前一个时间点对应的待检测的通信事件的执行时间；

时间比较模块，用于比较所述待检测的通信事件的执行时间与设定时间，所述设定时间为：待检测的通信事件对应的通信业务中运行所述待检测的通信事件的预先设置的时间；

所述集合划分模块包括：

6.如权利要求5所述的设备，其特征在于，

所述性能确定模块，进一步用于在一个信息集合内的通信事件由同一服务器运行时，若比较结果是待检测的通信事件的执行时间大于设定时间，则确定运行所述待检测的通信事件的服务器性能不能满足通信业务的要求，否则，确定运行所述待检测的通信事件的服务器性能能够满足通信业务的要求。

7.如权利要求5所述的设备，其特征在于，

所述性能确定模块，进一步用于在所述相邻两个时间点分别对应的两个通信事件由同一服务器运行时，若比较结果是待检测的通信事件的执行时间大于设定时间，则确定运行所述待检测的通信事件的服务器性能不能满足通信业务的要求；否则，确定运行所述待检测的通信事件的服务器性能能够满足通信业务的要求。

8.如权利要求5或7所述的设备，其特征在于，

所述性能确定模块，进一步用于在所述相邻两个时间点分别对应的两个通信事件由两个服务器运行时，若比较结果是待检测的通信事件的执行时间大于设定时间，则确定所述两个服务器中的一个或两个的性能不能满足通信业务的要求；否则，确定所述两个服务器的性能都能够满足通信业务的要求。